I’ve been neglecting this blog a little bit recently. So far in 2014 really. But it hadn’t escaped my notice that it was running veeerrryyyyyy sssllloooooowwwwwlllllyyyy!
Initially I tried just popping CloudFlare in front of it but this site was running so slowly that configuration would fail / timeout each time.
In case it should be of any use, here’s what I did to speed it up a little.
Step 1: Make a Backup!
It’s a fundamental tenet of IT that you backup before you make a change that has the potential to break things and these changes could break things. Make sure that you have backups and you know how to use them.
I use a plugin called BackWPup to make daily backups of the database and files to a Dropbox share. One of the slow site symptoms that I’ve observed recently was that backups were failing more often than not and seemed to be taking a long time to complete. A quick look at MySQLAdmin told me that the database had grown in size to about 78MB. For a bunch of text that seemed a bit high – more on that later though.
I use 3 backup jobs to backup the site:
- A daily database backup – this takes a complete backup of the WordPress database and uploads it to Dropbox.
- A weekly file backup – this captures all of the files for the site except for: Plugins, unused themes, cache and older media / upload files (e.g. anything from 2008 – 2013)
- A monthly archive backup – this captures the plugin files and older media items excluded above. (If this ends up running too long then I’ll create another job at a different time and split the files up.
(The reason that I separate out the file backups is that older media items don’t change and the plugins can be downloaded fairly easily and I only tend to update them once a month anyway. This just makes the weekly file backup go more quickly.)
Step 2: Look At Plugins
I looked at the list of plugins in use. Each plugin will slow down a WordPress site by a fraction (or more) of a second. Add it all up and the execution of plugin scripts can amount to quite a lot of time. I adopted some very simple rules and applied them to the list of installed plugins:
- If they were active, did I use them? No, then I removed them.
- If they were deactivated, I asked myself if I would need them anytime soon? No, then I removed them.
All good so far but I hadn’t moved the needle any noticeable amount. A bit maybe, but not so much that I noticed.
Step 3: Install New Plugins
Hang on? Why am I installing new plugins if they’re only going to slow things down?
Good question. These are diagnostic plugins however. The two in question were WP-Optimize and P3-Profiler. My intention was to do some housekeeping and analysis with these to determine if there was an issue with the whole WordPress installation or any of the plugins in use.
Step 4: Optimise
First up, I looked at WP-Optimize. When you click on WP-Optimize in the admin menu, you’re given a fairly length page detailing any database optimisations that the plugin thinks can be made.
First of all, there’s a summary of potential remedial actions for your database:
The items in red are potentially dangerous and are exactly why you’ve made a backup already, right?
What showed up the first time that I saw this screen was over 20000 items listed under “transient options”. WordPress creates these automatically when required but they can apparently be safely removed. “Optimize database tables” will run MySQL optimisation on your database’s tables. Some web hosts don’t allow this – luckily mine does.
Below the remedial actions, is displayed a list of the tables themselves along with their size, an assessment of their optimisation and the potential saving available. As you can see from the screenshot, the 341 transient options that have accrued since I first cleaned up the database are using about 2MB of space. The plugin also believes that the table needs optimisation.
After running this through for the first time, the database size dropped from 78MB to about 7MB (which improved the backup time considerably). Sadly, the overall performance of the site was still not great.
Step 5: Measure Plugin Performance
Enter P3-Profiler. This plugin is developed by GoDaddy (yes, the webhosting people). It measures the load and execution time of a few of your site’s pages and breaks it down by plugin. You execute the scan from the “Plugins” menu.
The scan takes a few moments to run but then displays some useful information about the various plugins that you still have installed and active.
6.5 seconds?!? Wow, allegedly that’s how long the numerous plugins that I had installed were adding to my page load time.
Step 6: Get Rid of the Slow Plugins
I won’t go into all of the analysis that can be done with P3-Profiler, but I did use the information to refine the list of plugins in use:
- I disabled NextGEN Gallery as it seemed to take the longest of all.
- I disabled any of the JetPack options that I wasn’t using / relying on.
- I removed the CloudFlare plugin (as I couldn’t get cloudflare working anyway)
The result (according to the profiler) was about an 80% reduction in the plugin load time. JetPack still takes the longest but it’s better.
The qualitative benefit to load times was impressive. The site felt pretty quick now.
Step 7: CloudFlare
For the final step, I was now able to configure CloudFlare to provide a bit of a boost and a degree of protection. What do you think, is the site quick enough?
Hope any of this helps…