Usually, we just  measure the performance of our customer’s applications and talk about it, but from time to time we have to set an example ourselves.

In the last couple of weeks, we increasingly felt that our blog isn’t loading fast enough to deliver a satisfying experience. You know that when you can feel it, it might be too late already. Additionally, SEO is about content and performance and our blog is an important marketing tool for us.

That’s why we went on a quest for improving the performance of our company’s WordPress-based blog. Our motto: “Don’t just complain about the lack of performance, do something about it!”

Step 0 – Measuring

Measuring is believing and so we started with this WebPageTest result. As you can see, the initial performance is bad, a lot of content is not properly cached, and rendering started after 2.6 sec. Time for some serious tuning.

Step 1 – Reading

Tuning requires you to know what to tune. Thus, we read the famous Best Practises for Speeding Up Your Web Site by Yahoo. A similar article by Google can be found here. If you deal with web site performance in any way, you should read this. We consider it mandatory for performance and web testers.

Step 2 – Wordfence

One of the first things we did was disabling Wordfence because we had the strange feeling that the performance degradation of the blog had started just recently – a couple of weeks ago, we’d installed Wordfence in response to the WordPress login probing attacks. Yes, the disabling made us faster: first byte time came down from 1.7 sec to 0.7 sec. This was awesome… but who wants to run WordPress without protection? So we tuned Wordfence and disabled the firewall and live traffic detection, basically just keeping the login security and scanning features.

Step 3 – JavaScript

So, what was next? We realized that Slimbox had an impact because of the MooTools library it used. Not really a huge impact, but the JavaScript held back the rendering and further loading. We picked wp-jquery-lightbox as a replacement which didn’t change that much but got a little faster; Jquery seems to be a little better optimized in terms of JavaScript performance and size.

We also updated the SyntaxHighlighter since we’d been using an older version that was no longer under active development. Yet no relevant change in performance here.

Step 4 – Thinking

That’s basically all you can do, provided that your content is okay (properly compressed images) and that you have a fairly small CSS file for your theme. Because changing the hoster, tuning the database, or even replacing the webserver is a little overkill for a low-traffic blog, we could only take the caching route next. You can go back to the Yahoo and Google article and check what is possible without starting to reinvent the wheel aka writing a new blog, changing the theme, rewriting all content…

Step 5a – WordPress Caching

When you look up tuning tips for WordPress, you immediately find W3 Total Cache and WP Super Cache. Based on our reading of reviews, Super Cache seemed to be a little easier to handle, so we tried that. Somehow we failed though: it didn’t do anything and the performance stayed the same. As it’s not that easy to use, we switched to W3 Total Cache.

Of course, Total Cache is overwhelming as well and it took a while for us to realize that it couldn’t save its settings due to the file system permission handling of our hoster. Thus, we updated the .htaccess files manually. Since we also pull content from our Piwik installation, we added some of the .htaccess settings there as well. These settings basically refer to  serving the content as cacheable to the browser, avoiding refetching as well as delivering the content compressed. CSS, JS, and HTML can be compressed quite well and so it’s recommended to run mod_deflate for reducing bandwidth consumption.

Step 5b – W3 Total Cache

We had to go through a lot of trial and error to get the performance where we wanted it. Total Cache offers so many options that we had to try over and over again. Don’t forget to measure the  settings several times since also the measurement tool can have a bad minute as well! Also, if you run on a shared hosting environment, you’re not alone and other traffic might influence your measurements.

Step 6 – Measuring Again

After all this was done, we measured the final performance. The first bytes now came in after 0.22 sec and rendering started after 0.7 sec. Wow! We’d begun with 1.7 and 2.6 sec!

Step 7 – Enjoying

This basically means that we improved the performance of our blog by factor 4 to 8! Google and Bing, feel invited to drop by and index our content! We hope that our visitors enjoy the improved performance as much as we do. If we wanted to further enhance it, we had to move to a better server that can be tuned by dealing with database and network settings on a lower level. However, this doesn’t make any sense right now, micro-tuning doesn’t do any good here.

Always keep in mind: you can only test what you know and understand. It is this knowledge that allows you to evaluate client performance the next time you have to test it, and it also provides useful feedback on how a problem can be solved or in which direction you have to look for a solution.

We’re looking forward to hearing about your client site performance tuning and measuring experiences. Please share your WordPress tuning and operational procedures as well. Happy performance blogging!

Update: How much could I improve the performance of one of my websites in 1 hour?. Very nice reading. Check it out!