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:
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.
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:
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.
Posted: 19 May, 2010 at 5:11 PM
Hm… You seem to use cache here so why plugins are making a difference in average response time?.. They should not impact much with cache.
Also try “enhanced” page cache mode in W3. Difference is that regular mode will still go through PHP, but enhanced mode will try to serve static file first with .htaccess directive.
At my blog most response time issues recently boiled down to server performance.
Posted: 19 May, 2010 at 5:56 PM
Thanks for the comment Rarst,
I plan to implement some changes of settings with W3 to see what gets better… let’s see how far it’ll go. I’ll report on the impact of some settings in the next report.
Posted: 19 May, 2010 at 5:57 PM
Worth noting – I’ve decided to set a target for 500ms average response times. We’ll see how close I can get!
Posted: 19 May, 2010 at 6:07 PM
Pingdom doesn’t measure total page load time, response time is only how fast server replies after initial request. Page loading with JS and stuff comes later.
That it why plugins shouldn’t make much difference here in my opinion. They can kill performance when page is being generated, by they don’t matter much at WP core loading stage.
Overall response times seem to be less about WordPress and more about server software. That’s why sites that need high performance start to migrate off Apache to other web servers and use proxies like Varnish.
For the record my blog currently averages 1.3s response time, which I consider fine for a shared server. Ah, I wish I had need and buck for own server to play with all shiny server-side toys. :)
Posted: 19 May, 2010 at 6:46 PM
Ah yes, a good point – although I thought it measured the whole of the page (including all elements?) – but from what you’re saying the plugins were killing me at page generation point.
Either way, suddenly everything got a lot faster!
I’ve just enabled full opcode caching (I was taking a step-by-step approach) to see what comes next. In a couple of hours I’ll know.
Interesting YSlow reports little difference, but then it’s only one part of the overall toolset.
In terms of servers – we have two, one that’s not terribly brisk and rather expensive but is reliable and fully managed for us and on which all our high-availability clients live on, and another which is a VPS on a much faster box and which, curiously, can handle a far higher traffic load in spite of being just €30 a month. You should look into the options out there – I’ve been amazed what you can find if you get into the geekier end of hosting.
Posted: 19 May, 2010 at 6:55 PM
YSlow is not real time. It analyzes elements on page but not how they load.
My blog’s traffic and income are relatively small so it doesn’t really justify VPS. :) At least managed one and I am not too good with Linux to go for unmanaged.
Posted: 23 December, 2010 at 2:14 AM
Patrick Moran says:
We’d love your feedback on our new wordpress monitoring and management tool – see inside your app and see what’s slow, 2 minutes after installing our agent. If you have WordPress performance problems, you should try out New Relic — http://www.newrelic.com – we just released an agent that let’s you see inside your wordpress/php app and see what’s slow. We’d love your feedback. Check out how we do it: http://blog.newrelic.com/2010/12/16/measuring-wordpress-performance-with-new-relic-rpm/
It is super easy to setup. Let me know if you think this might be valuable!
Posted: 16 April, 2012 at 2:45 AM
brilliant, there is a technical side to training and I have been struggling to get my content delivered faster – I carry a lot of info on membership databases and video files
Have your say