One of the most important things that gets forgotten about when running a WP site is that performance is important. We see many sites with page load times way in excess of 2,000ms per page. Often the site just gets progressively slower over time and the change isn’t really noticed. That had happened with mine, though I’d made tweaks in the past to help, I still wasn’t happy.
So I knew that the increasingly sluggish performance of my site was an issue. The crud had built up, and in rebooting I hoped to dramatically improve responsiveness.
And I did:
It’ll be interesting to see the impact of this over time, but I’m pleased with the results so far.
An interesting graph of site performance over the past few years:
As you can see – the performance early last year got particularly bad.
It’s worth noting that I don’t run any caching or CDN on this site – it’s never that busy to be worth the work.
I’m hoping that I can now keep responsiveness down to <700ms average.
One lesson I hope you do take away from this is the importance of continuously monitoring your site’s responsiveness by using a service such as Pingdom.com.
I’d started to notice that my site could often be slow to load – other sites on the same server weren’t suffering the same way, so I wanted to document a simple way in which one can identify performance issues on the site. This is one of them.
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.
I noticed on my pingdom stats recently that this site has been slowing down recently. But why? Is it WordPress? Some plugins? Time for research!
I don’t really look at server response times too much, because generally it’s a bit dull, really. If our server is really sick then the automatic alerts and text messages from Pingdom tell me to get fixing.
Anyway, tonight I just thought I’d have a look at some graphs. And hey, there’s a bit of a shock… my own site, this one here, is getting slower. Here’s the graph:
Now, what you’ll notice is that generally everything looked nice and brisk until early August 2009 when there was a marked deterioration in performance. Then it plodded along just fine until December 2009 when it got worse again.
Is It WordPress Bloat?
I wondered what had happened to cause this – I’m especially shocked that a page load is now so slow. I haven’t changed the theme in use for at least a year, and the plugins are generally ones I use elsewhere. So I did a bit of thinking, and then it dawned on me when I found this list of release dates at WordPress.org:
The dates correlate exactly with the worsening performance of this site.
Now, correlation absolutely does not relate to causality. At upgrade time I usually take a moment to review plugins, upgrade the theme, etc. It could be that an upgrade or change to one of the many plugins in use here that has caused the slowdown. I know it’s not traffic to my site – that’s been flat for ages, with only the occasional blip. The server is a dedicated machine running about fourty sites that we manage, but the load is generally quite consistent and impact on different websites is fairly well managed.
But I’m a speed freak. I like it when a website zings into view. I love fast cars. I love computers that don’t dither. I love telephones that respond instantly. So I hate that response times are now below 1s. That’s not on!
So I’m going to try to find the cause of this slowdown – I’ll be running some experiments on this site, profiling queries, checking the database over and so on. And I’ll document it all as a way of showing you how we at Interconnect IT do our performance tuning. Whether I document it here or there I haven’t decided yet – I think it would make a good case study for the site. We’ll see! Watch both sites…
