Optimizing Wordpress load speed - Robin Hallabro-Kokko

Having a quick loading website is crucial in order to retain visitors and to increase organic traffic. Google even owns a patent entitled "Using resource load times in ranking search results". However, according to their blog this does not affect more than 1% of the indexed websites and only when using Google in English as for now. While this alone may not sound very harsh at the moment this will most likely change in the future. The main problem with slow loading website is that users are not very patient.

When Google tested a new way of delivering search results (by 30 search hits instead of the default 10) it resulted in an increased load speed of 0.5 seconds and a 20% drop in traffic. While Wordpress can be slow I've set it up to serve a complete web page with images, scripts and css in just about a second - on a quite slow VPS.

To benchmark I am going to use Siege which can be found in most package managers. To quote the manual, "Siege is an http/https regression testing and benchmarking utility. It was designed to let web developers measure the performance of their code under duress, to see how it will stand up to load on the internet".

I will during this benchmark use the options -t60s -c10 which will hammer the web server for 60 seconds with 10 concurrent requests. I initially tried to benchmark with a higher number of concurrent requests but I quickly found that my somewhat slow VPS could not handle this very well.

Initial benchmarks

Running the initial test shows a transaction rate of around 10 transactions per seconds, where the longest one lasted 1.39 seconds and the fastest one lasted 0.12 seconds.

Transactions: 604 hits
Availability: 100.00 %
Elapsed time: 59.94 secs
Data transferred: 2.56 MB
Response time: 0.51 secs
Transaction rate: 10.08 trans/sec
Throughput: 0.04 MB/sec
Concurrency: 5.17
Successful transactions: 604
Failed transactions: 0
Longest transaction: 1.39
Shortest transaction: 0.12

Not too bad without using any sort of cache but it can definitely be improved. The theme I am using is however quite lightweight. Loading the front page with in Mozilla Firefox with an empty browser cache shows a time of 1.68 seconds to load the entire page.

This is with a complete page load including the rendering of layout, images, css and javascript as opposed to Siege which will simply hammer the web server and ignore the response content.

PageSpeed Module

Google's PageSpeed Module is an open source module for both Apache and NGINX which automatically optimizes Javascript and CSS by minifying them and merging multiple files, resulting in fewer requests sent to the server. It also has support to optimize images.

To build and enable this module for NGINX I went to the project's GitHub page and followed the build instructions for ngx_pagespeed which only takes a few minutes. It works quite well out of the box - but I still enabled a few extra options:

pagespeed EnableFilters collapse_whitespace,sprite_images,trim_urls,in_place_optimize_for_browser,remove_comments,extend_cache,rewrite_javascript,rewrite_images;
pagespeed UseExperimentalJsMinifier on;

With this module activated I get a loading time just under one second. The Javascript and CSS has been reduced in size by 67 kB from a total of 404 kB down to 337 kB (roughly 17%). The only image which was loaded has been optimized in advance which is why it is not reduced in size further.

W3 Total Cache

W3 Total Cache is a plugin for Wordpress which provides a database cache, object cache as well as a page cache. It also supports off-loading assets to a CDN. In short it's sole purpose is to speed up the website. After activating W3 Total Cache and its page cache, database cache and object cache the number of transactions are dramatically increased by roughly 40%.

The minification is not enabled as it already is provided by the PageSpeed Module. As installing plugins in Wordpress is so simple there is really no excuse not to install this plugin.

Transactions: 1053 hits
Availability: 100.00 %
Elapsed time: 59.71 secs
Data transferred: 4.51 MB
Response time: 0.05 secs
Transaction rate: 17.64 trans/sec
Throughput: 0.08 MB/sec
Concurrency: 0.83
Successful transactions: 1053
Failed transactions: 0
Longest transaction: 0.18

Varnish

Varnish is a reverse proxy which will store the pages generated by Wordpress in memory. When a user opens up a web page which is in the memory of Varnish, it will serve the user this stored copy of the web page instead of asking Wordpress and the web server to generate a new response.

I will use Nicolas Hennion's configuration inside of the file varnish4-wordpress. Sieging the server with Varnish running I get a slightly increased transaction rate although it's difficult to draw any conclusions using this benchmark alone.

Transactions: 1102 hits
Availability: 100.00 %
Elapsed time: 59.24 secs
Data transferred: 5.16 MB
Response time: 0.05 secs
Transaction rate: 18.60 trans/sec
Throughput: 0.09 MB/sec
Concurrency: 0.85
Successful transactions: 1102
Failed transactions: 0
Longest transaction: 0.07
Shortest transaction: 0.04

Conclusion

Looking at some key numbers from Siege I can tell that using these techniques the page speed has been greatly improved. Adding up the data from the performed benchmarks I get the following key numbers.

Response time: -0.46 secs
Transaction rate: -8.52 trans/sec
Longest transaction: -1.32

Each of the techniques used definitely serve a purpose. On their own they all improve the page speed. However it's possible that W3 Total Cache together with Varnish do not further reduce reduce the response time and transaction rate.

For smaller web sites I would say that using only one of these would be enough. W3 Total Cache does provide different caching mechanisms which help improve the page speed for pages not cached by Varnish but I think this is easily negligible.