Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Optimizing WordPress Performance - 6 Seconds to 1

DZone's Guide to

Optimizing WordPress Performance - 6 Seconds to 1

· Performance Zone
Free Resource

Transform incident management with machine learning and analytics to help you maintain optimal performance and availability while keeping pace with the growing demands of digital business with this eBook, brought to you in partnership with BMC.

Since last week, this blog has a new name and a new look, but most importantly, it now loads faster.

Over time I couldn’t but notice that the overall behavior was getting painfully slower. Surely, this blog uses “WordPress Super Cache” plugin but apparently caching wasn’t enough in order to improve performance so I decided it’s time for something better.

Let me start with the final results. Initially, the main page load time was more than 5 terrible seconds. And now? We’re down to 1 second! Here you have it, one evening spent wisely made this blog more pleasant to browse and read.

Anyone who has ever dealt with web performance analysis knows that today’s browsers and extensions provide you with enough tools to make a good analysis of web performance and page load times. Yes, I’m talking about Firebug Net monitor, “Chrome Developer Tools” Network Panel, PageSpeed, YSlow, Speed Tracer and dynaTrace AJAX. Not only that, there are a number of online resources providing a similar kind of web profiling and monitoring, some of which I have listed below. In this specific case I have used GTmetrix, its “History” chart is shown above.

So what were those changes? Since I don’t develop WordPress plugins or themes I couldn’t do much about internal details, but there was still large enough room for improvements.

  • First of all, I cleaned up WordPress from unused plugins and themes. That was an easy thing to do.
  • I checked that “WordPress Super Cache” and “WP Smush.it” (which I had installed already in the past) are working properly and that the response is coming gzip-compressed.
  • “WordPress Super Cache” cache timeout was set to zero to disable its garbage collection – cache is now emptied when new pages are added, this is necessary for “Recent Posts” sidebar update. I also switched the plugin to “mod_rewrite” from PHP to serve cache files.

  • When Firebug Net monitor showed an extensive amount of external resources loaded, I aggressively cleaned up the sidebar from all additional widgets. Consequently, all my social, Twitter and Pinboard links are now gone (they can be found on evgeny-goldin.com, as before). Two “Twitter” buttons accompanying each post for easier retweeting were also removed for the same reason. The only external widgets I decided to keep were DZone buttons on some posts as they are an important part of the blog’s history.
  • The Gravatar plugin that used to display a picture of me on the right was replaced with a locally stored image and an HTML markup, see “Custom Dashboard Widget”.
  • I later attempted to combine, minify and compress the JS/CSS resources loaded. “JS & CSS Script Optimizer” plugin did just that. Two other plugins I have tried, “Better WordPress Minify” and “CSS-JS-Booster” didn’t perform equally well.
  • Trying to compress HTML by eliminating unnecessary white spaces and line breaks resulted in an negligible 5% improvement so I didn’t bother to keep this optimization. Anyway, “WP-HTML-Compression” and “WP-Compress-HTML” are at your service.
  • And then came the hardest part – theme update. I decided to switch to summary-only main page so that posts’ bodies are kept hidden: some of them contain embedded Flash videos which hurts the loading time severely. The new “Blue Modern” theme is simple, lightweight and, most importantly, it keeps the main page free from any embedded content.
  • At some point the performance went up to 2 seconds, according to GTmetrix reports. It happened right after I added the Gr8Conf banner linked to “http://gr8conf.org/uploads/eu2012/Image/banners/gr8conf%20125×125.png”. After uploading the image and serving the local copy of it the performance went back to normal.

So that was the process. I believe that most of the time was spent on choosing the new WordPress theme (though there are so many of them, there are still not enough really good ones) but it was a very nice journey into some of the details of web performance. To reflect on it I’d suggest the following 4-step process to boost your WordPress blog’s performance:

1. Cleanup caches.

Assuming you’re using the “WordPress Super Cache” plugin, there are two caches you’re dealing with: the WordPress cache and the browser cache. The WordPress cache saves PHP and database processing results on the server side so when a cached page is requested it serves it immediately without involving the PHP preprocessor. The browser cache saves all the retrieved resources locally so when an image or a script are requested it serves a local copy after verifying with a server that it hasn’t been updated recently. Now, depending on what you’re going to measure, clean and repopulate the corresponding cache. Generally, I perform my measurements with WordPress’ cache pre-populated and with an empty browser cache. Measuring performance when both caches are full also makes sense, as it allows you to see how quickly the page performs in an ideal situation and how long does it take for a browser to run an up-to-date check with a server.

2. Analyze the timeline (waterfall) report.

Load the page in a browser and analyze its ‘timeline’ report, also referred to as ‘waterfall’, produced by either Firebug Net monitor, “Chrome Developer Tools” Network Panel or GTmetrix whose ‘timeline’ chart is shown below.

Note that report numbers don’t carry much meaning as they will most definitely vary wildly depending on client-server geographic locations and connection speeds. What matters more is the overall loading behavior and the way your changes impact it: how many resources are loaded, what resources are loaded from external (potentially slower) domains, are they compressed, combined together or minified, which resources load most sluggishly and so on. In addition, note that while this report is useful for spotting the most obvious bottlenecks, it provides a network-only view of the page loading process. For detailed reports on page rendering and processing behavior consider using the Speed Tracer (Chrome) or dynaTrace AJAX (IE, Firefox) browser extensions.

3. Analyze PageSpeed and YSlow reports.

If the ‘timeline’ report hasn’t provided you with enough data to work on, run PageSpeed or YSlow to get a detailed list of suggested optimizations. GTmetrix conveniently provides both reports online:

4. Implement the changes and repeat.

Every time WordPress plugins are added or configured, clean up the caches and measure again. Do not take any optimization for granted. GTmetrix makes it easier with its “History” chart where you can easily spot performance anomalies as your blog evolves.

Can it be better? Yes, absolutely. Looking on the main page source I still see references to external resources that simply shouldn’t be there, probably leftovers from plugins removed. So better results can be achieved. Naturally, not being able to control and fine-tune the WordPress application, HTTP headers and the content added by the plugins makes the task less trivial but as you’ve just witnessed, it is more or less doable nevertheless.

What were the lessons learned? I think minimization of external content is the major takeout here. Taking out absolutely everything except the content proved to be the most high impact performance optimization. Content compression, resources unification and minification surely help but not as much as having all social buttons removed and external images served from the local domain. In addition, I figured out that adding more links not only makes the blog slower, it doesn’t make anyone’s life easier as I’m sure most of you have enough links to follow.

What’s next? I believe that the next step can be more dramatic: stepping away from WordPress and switching to Jekyll-generated static content. On top of being significantly faster, it brings control over everything back to your hands which is absolutely a must if you’re seeking decent Web performance. Two beautiful examples of static content blogs would be igvita.com by Ilya Grigorik and stevelosh.com by Steve Losh. Try them out and see what fast really means!

To sum up this topic, I listed performance-related WordPress plugins and browser extensions mentioned in this post plus a number of on-line services you can use to analyze and monitor your blog performance:

WordPress plugins:

Browser extensions:

On-line services:

You can also review my WordPress and web performance links. In particular, I’ve found the “Making the Web Faster at LinkedIn” video very useful.

What was your experience in optimizing WordPress? Which tools did you use? I’d love to hear!

Evolve your approach to Application Performance Monitoring by adopting five best practices that are outlined and explored in this e-book, brought to you in partnership with BMC.

Topics:

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}