David Coveney

WordPress Performance, Make it 3x Quicker!

A little while ago I reported that my site, since some WordPress upgrades, had started to slow down. I’d wondered whether it was WP becoming increasingly bloated, or some other problem.

Well, it took me a while to get back to the issue (babies and a booming business don’t help!) it’s continued to get worse and worse, until a recent change has improved things… but only marginally, as shown by the Pingdom chart below:

Not looking good…

This is dreadful, really – daily average of 4,000ms responses just aren’t acceptable where, two years ago, I was getting 800ms.

So, now the process starts.  The recent small improvement came after installing our Spectacu.la Advanced Search Plugin, which runs a regular database optimisation to help keep things nippy, but it was still dreadful.

Is it Pluginitis?

My first suspicion is always that of plugins (and sometimes themes, if they’re complex).  In our office we have a term called ‘pluginitis’ which refers to the problem of a site having too many plugins installed, many of which are poorly written.  I hate to say it, but when clients call to ask for a plugin to be installed that we’ve never tested we go through it and, 90% of the time, discover serious performance or security flaws that will cause long-term issues.

And this site here is old – I’ve been running a WP install for four and a half years with nothing more than upgrades and, like an old PC that’s been upgraded too many times, that causes issues with old drivers and code.  Same can apply to WordPress.  So let’s see what we can do to improve things.

First stage is to disable as many plugins as possible so as to isolate the issue.  I’m using a division based approach – ie, I’m going to disable half of my plugins to see what happens.  If I get full performance back, then the problem lies in that half.  I can then reactivate half the plugins and see what happens.  If the performance is still good, the problem is in the other half.  I think you can see where I’m going here.

I’m also going to go for plugins that aren’t written by us. Not because I’m biased (ok, maybe a little) but because I know all of ours are carefully tested for performance – many are run on major sites such as the Telegraphs blogs site.  Speed is of the essence.

I’m also going to skip plugins like Akismet, because anything that’s essentially ‘core’ is usually going to be reasonably performant – at least on a small site like this one.

It’s worth noting that I could easily delve into SQL statements and code efficiency – but that’s only interesting to developers – if you’re simply a WordPress user, performance is interesting but what you can do to find problems is somewhat more limiting.

Plugins being disabled:

Add to feed – a simple plugin, but sometimes simple plugins miss simple tricks.

Headspace2 – I have my suspicions about this plugin as it’s massive. Could be fine, may not be.  Only way definite way to know – measure it.

Search Meter – a nice plugin to see what people are searching for, but is it adding load somewhere?

Social Bookmarks – it shouldn’t cause issues, but you can never be sure.

wp-typography – I love what it does for the typography on the site, but it’s also running a lot of javascript.

First results:

I do use YSlow to test the site, but one of the problems is that it’s hard to get a large enough series of data to be statistically relevant.  It’s good for seeing the extra load (and why I knew the amount of javascript was an issue) but for longer term analysis it’s flawed.

So, we go back to Pingdom and look at the one day chart.  As I type this it’s now an hour since disabling the plugins above – so let’s see what’s happened:

A dramatic improvement!

As you can see, in this afternoon alone there’s been a dramatic improvement – from around 2500ms per visit to 1230ms per visit.  In one single step I’ve halved the load time of the page.

What we don’t know so far is whether that’s because the page got smaller to load or whether it’s down to a reduction in database load – but that’s really for another article.  What this is all about is trying to document how I’m improving the responsiveness of the site in a way which relatively non-technical folk can follow.

What I’ll do in the next feature is to turn off some more plugins to measure the impact they had.  I’ll also be interested to see if the spikeyness of the response times has varied much – are they caused by simple server load, or is there something else at play?

I will then start to switch plugins on again in a structured way in order to measure which was causing the heaviest loads on the site.

Keep watching!