Immediately I locked onto this, one of my hobby horses and something I like to rant about at any moment is page speed. For years there has been plenty of research supporting fast load times. Optimal target being 0.4 seconds, and a maximum of 4 seconds. Researchers at Amazon even found that for every 100 milliseconds your site slows down, you lose 1% in revenue. Along came Google, who just happened to mention that page load times influence their search calculations but only by 1% or less.
SwankyApple at the time was loading at between 6 and 10 seconds which is an incredibly poor performance. The first step was caching plugins. I prefer to use W3 Total Cache as it is easy to install and integrates well with MaxCDN, my content delivery network of choice. It is widely acknowledged that installing a cache plugin for WordPress is as essential as having a password for site administrators. The cache plugin brought the page load time down to 4 – 7 seconds which is more acceptable but still far from ideal.
Optimising WordPress serves two purposes; firstly it improves a visitor’s impression of your site. Secondly I don’t like angry phone calls and emails from clients at 1am. A spike in a website’s popularity could end up crashing the server. A lot of these optimisations will reduce server load which in turn will enable us to reduce our hosting costs and ensure resilience under heavy loads.
The following research took about 3 weeks, lots of late night reading and an example WordPress install to test on. We made the decision to move away from our hosting provider to a managed VPS, where we could have control of the configuration, server loads and number of sites hosted. Being on a shared hosting package is okay until someone on that server gets busy and then everyone suffers. Previously on the Swankyapple website there were parts of the day where load time was distinctly worse. On the current VPS (virtual private server) we have guaranteed dedicated resources with bursts of extra resources available if needed.
Serious WordPress optimisations fall into 7 steps and are basically different levels of caching:
- Set browser cache headers
- MySQL caching
- Installation optimisation (removing unwanted plugins)
- URL Structure Optimisation
- Use HTTP compression
- Reverse Proxy (nginx)
- PHP Caching
The W3 Total Cache plugin does a lot of heavy lifting for us. Immediately we can set it to combine and minify (reduce extra text in documents) which reduces the number of documents that browsers need to download. The plugin can also set the browser cache headers for any documents. As a result if someone revisits the site they get a much faster load time.
MySQL query cache
On the test server with a clean cPanel install there was no MySQL query cache setup which was a bit of an issue. After some fiddling around I arrived at a level that the server was happy with and didn’t cause the server to crash. MySQL optimisation is a whole industry in itself. It’s a complex task and I am by no means an expert. There are certainly still gains to be made here. For the small test server I set the ‘query-cache-size’ to 128M for a server with 1024Mb of RAM. Set a
key_buffer for 20M and finally the
table_cache to 128M. Simple options to set, but if they are set to high the server will crash under load, so be careful.
Remove unwanted plugins
Change Your URL structure
I found this very interesting article through the Forrst community about not using /%postname%/ in your URL structure. Using this tip it really helped me get my test site down from 0.8 seconds to 0.5 seconds a page. If you don’t fancy reading the article, it says to stop using words as the start of permalinks. Use
/%post_id%/ instead. For exactly why and who says so (WordPress developers) read the article. Good news here is that Wordpress is clever enough to redirect old URLs to the new URL so you won’t lose any SEO value. Happy Days!
Turning on HTTP compression from the web server means that less data is flowing down the pipes. It’s a quick way to increase the load times of a page. If you really care about IE6 then be careful as you’ll need to turn off compression for most of it. I’m using cPanel and this has the option built in. Apart from that it’s a well-documented bug so I am sure a web search will find a tutorial.
That’s it for optimising WordPress. The next two steps don’t really affect page load times except if you’re running in heavier traffic scenarios. The next steps are therefore more about getting the servers ready for high page loads. I want my site to perform reasonably well on the off chance that we get up to 100 concurrent users. Under those conditions the more hardware you can throw at it the better, but really you should be still expecting 4 seconds tops.
I’m using eAccelerator as it comes as a build option in cPanel but APC and XCache are two other options. eAccelerator et al improve the performance of PHP under load as objects are cached to disk or memory rather than being processed each time. As such they don’t have much effect on low traffic sites.