Making WordPress Fast

I joined SwankyApple almost a month ago and as usual was given a large list of things to do while I got my feet under the desk.

Make the site fast was one item on the list.

Written By
Guest Blogger

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

Caching Plugin

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

Uninstall any unwanted plugins and then uninstall any wanted plugins that are not absolutely necessary. Finally check through the head of your page, I found some plugins adding in additional copies of Javascript libraries. Not cool plugin, not cool. In any places like that remove the additional library calls, or seriously think about using another plugin that achieves similar results.

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!

HTTP Compression

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.

Reverse Proxy

Everyone loves Apache, THE web server, well yes and no! Increasingly the world’s busiest sites are looking to smaller lighter more efficient web servers to perform under high loads. nginx does the trick; it’s well respected, well supported and super-efficient at serving up static files like images, pain html, css javascript etc. I still run apache to deal with the PHP and have noticed a significant number of concurrent connections that the test server could handle when running nginx.

PHP Cache

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.

What Else

So I’ve not talked about image Sprites for CSS images that can improve page loads. I’ve also not talked about using tools like Memcache as we are not trying to cope with hundreds of thousands of hits a day. Under the right circumstances I’d look at trying to move some assets onto a CDN (content delivery network) but that has to be under the right circumstances as the additional DNS lookup can have a negative effect as I found out on the test site. All in all I’m fairly pleased with the current setup, the test server delivers at between 0.4 and 0.7 seconds and Swankyapple page loads somewhere in the 1.5. We are however using a visitor chat plugin that, at times, adds another 2 -3 seconds to load time. As it is pulled in via Javascript and pops up when ready it doesn’t have a bad impact on usability

Talk ecommerce with us

Ready to grow your ecommerce business? Let’s talk.


Join the Swanky Community

Want to receive regular updates and inspiration to help your business stay ahead of the game? Subscribe to our newsletter and join the community of ecommerce leaders successfully navigating the world of online retail.

What are the Benefits
  • Be at the forefront of industry trends

    We develop and implement ecommerce tactics for industry-leading brands on a daily basis. Be the first to hear exclusive insights and learnings.

  • Get a monthly dose of inspiration

    Receive our newsletter straight to your inbox, packed full of useful marketing tips and growth strategies for your online store.

  • Join a community of fellow leaders

    Get to know like-minded entrepreneurs in the digital transformation space. Share experiences and learnings from your ecommerce journey.