
How to double the speed of your WordPress site in 3 easy steps
This content was originally published more than ten years ago and is archived here for preservation.
More up-to-date content is available on this blog.
With the investment of a few hours’ effort, I doubled the speed of this WordPress blog and no coding was needed. This is great news if you’re a little intimidated by performance tuning. In this article I’m going to walk you through the steps I took.
I’ve always been a bit of a ‘learn by doing’ kind of person. I was inspired to have a play after reading about some of the techniques used by Jason Cohen‘s (@asmartbear) latest venture, WP Engine, a premium WordPress hosting company. I also wanted to see how much more complicated web performance tuning has become. The good news is that, while there are a few more tricks to learn, there’s also a great deal more help out there to speed up your WordPress blog more easily.
When I worked at Zeus Technology (now part of Riverbed), I used to fine-tune the performance of their corporate and support websites. This was back when the web was small and primitive, and broadband was only just taking over from phone modems. Back then, every extra image meant longer download times.
Things haven’t fundamentally changed that much. While connectivity has become more widely available and faster, the content being delivered has become richer (or arguably more bloated) and we’ve become more impatient, so overall the user experience remains broadly the same. If you’ve ever been sat with your smartphone waiting for a site to load, you’ll know what I mean. That frustrating wait turns people away from your site and, whether it’s your blog, sign-up form or corporate site, you don’t want to be giving them any more reasons to drop out.
Step 1 – Figure out what state your site’s in before you start #
It may sound obvious, but in your excitement to play with things you may accidentally skip this step. So let’s take a look at the rather helpful tools we’re going to be using to benchmark your site before we start tinkering.
- WebPagetest – allows you to run a free website speed test from multiple locations around the globe using real browsers (IE and Chrome) and at real consumer connection speeds
- Google PageSpeed Insights – analyses the content of a web page, then generates suggestions to make that page faster
I used WebPagetest to test my blog front page (https://imanageproducts.com/). Just for fun, I decided to test as if it as it was IE8 from San Jose over a DSL connection.

Document Complete | Fully Loaded | |||||||||
---|---|---|---|---|---|---|---|---|---|---|
Load Time | First Byte | Start Render | DOM Elements | Time | Requests | Bytes In | Time | Requests | Bytes In | |
First View | 7.658s | 4.515s | 6.234s | 396 | 7.658s | 20 | 171 KB | 7.658s | 20 | 171 KB |
Repeat View | 2.850s | 0.988s | 2.033s | 396 | 2.850s | 14 | 11 KB | 2.850s | 14 | 11 KB |
Full results before optimisation: http://www.webpagetest.org/result/120729_J7_QDJ/
So over a DSL connection from the US to the UK, it takes nearly eight seconds for my front page to load. Possibly of concern is the 4.5 seconds it was taking for the first byte to be retrieved. What could be taking so long? A reload, which tests how effectively the site uses caching, takes nearly three seconds.
Okay, what can I do to improve the loading times? An excellent tool is Google’s PageSpeed Insights. Running this tool over the same front page brought back a list of recommendations.
Step 2 – Identify where you need to make changes #
PageSpeed Insights will prioritise its recommendations. As a rule of thumb, you should address all the high priority items and most if not all of the medium priority ones. Low priority items will have a lesser impact but are worth considering particularly if your site is often under high load.
Here are the main changes you’ll typically need to make:
Compress content. This is controlled in your web server, usually something like Apache, nginx or Microsoft IIS. You should aim to compress as much of your content as possible, though some content such as images will already be compressed. Read how to do this in Apache, nginx and Microsoft IIS. As it happens, I’m using Zeus Web Server, but as this is increasingly obscure I’ve not detailed the configuration changes I made. If you’re interested in what I did, drop me a note in the comments at the end of this article.
Use Content Delivery Networks (CDNs). A good example of this is to use Google’s copy of jQuery.js instead of your local copy because it is used all over the place in WordPress. It may seem a little counter-intuitive at first to push requests away from your local copy to Google’s, but this will have a positive impact on your WordPress site’s performance. Dave Ward provides a good explanation of why this is on Encosia. On WordPress, the easiest way to do this is to install the ‘Use Google Libraries’ plugin. You can in fact host any of your static content in the cloud so that it is closer to the people downloading it, reducing download times. For more general guidance on using CDNs, take a look at this quick tutorial by Riyaz Sayyad.
Minify content. This compacts and combines HTML, CSS and JS content to make retrieval and content compression more efficient. W3 Total Cache is great plugin that does this as well as many other optimisation techniques, though if you just want a plugin which just minifies, try WP Minify with a little tutorial.
Cache content. The goal here is for people’s web browsers to keep hold of content that doesn’t change very often so that they don’t need to download it again each time. Again, see W3 Total Cache, though if you don’t use this plugin, you may need to tinker with the HTTP response headers returned by your web server. If you want to understand the background a bit more, this quick tutorial on BetterExplained will help a great deal, with more detail available in Mark Nottingham’s more in-depth article.
Make sprites for common images – this is a subtle one, but useful when images such as your Facebook, Twitter and LinkedIn icons are used repeatedly. Essentially what you’re doing here is combining many smaller images into a single one, then using CSS to view the right bit of the combined image in the right context. This reduces the overhead of downloading each image separately and again will take advantage of caching. A detailed explanation is provided by Google. SpriteMe is a really easy tool for identifying the images and creating the sprites and CSS.
Step 3 – Re-test to see how you’ve improved things #
After each set of changes, re-run WebPagetest (there’s a handy button on the Summary to do this) and refresh PageSpeed Insights (again a handy refresh button is provided). You should see incremental improvements with each change you make.
Document Complete | Fully Loaded | |||||||||
---|---|---|---|---|---|---|---|---|---|---|
Load Time | First Byte | Start Render | DOM Elements | Time | Requests | Bytes In | Time | Requests | Bytes In | |
First View | 3.403s | 0.913s | 2.305s | 395 | 3.403s | 19 | 168 KB | 3.403s | 19 | 168 KB |
Repeat View | 1.939s | 0.907s | 1.551s | 395 | 1.939s | 8 | 10 KB | 1.939s | 8 | 10 KB |
Full results after optimisation: http://www.webpagetest.org/result/120729_PE_RW2/
Things are looking much more promising now. Full download time is now 3.4 seconds uncached, and with the benefit of caching, just under 2 seconds. More than double the speed for that crucial first view and lopping about a third off the time to reload.
Not bad for a few hours work, eh?
If you’ve got any questions about the WordPress optimisation techniques I’ve been using, drop me a note in the comments.
just want to what you did on zeus server to make wordpress fast… on apache my website has a great score but as I shifted to zeus server it dropped a lot… any solution will be appreciated… plz help
Hi Amber,
Do you run Zeus Web Server yourself, or does your web host run it for you? Try the following:
1. Make sure you’re running PHP under FastCGI. Depending on the version of Zeus Web Server (v4.1+), this will probably already be done.
2. Make sure the compiled PHP binary only includes necessary libraries and is on a recent version – the original version shipped with ZWS will be very out of date, but can be replaced easily providing you’re happy with compiling things. If not, speak to your web host support desk. I can provide the compile options I use for this WordPress site if you need them.
3. Enable gzip compression in ZWS, and add MIME types for additional content to compress. Can supply config list if needed.
4. Enable content caching in ZWS, though how long you can cache things will depend on how frequently your content changes.
Those were the main things, let me know if I can help further.
Cheers,
Jock