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.
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.
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.
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:
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.
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.
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.
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.