Accelerating WordPress sites with Redis, LiteSpeed Cache & CloudFlare Railgun

Written by Jo Stonehouse 0 Comments
WordPress is the most popular content management systems on the internet today, powering some 25% of all websites. From a personal blogging site to a full WooCommerce powered shop, WordPress is a smart choice due to its extensive choice of themes, ease of use and powerful features available thanks to the thousands of plugins that have been written for it.

Over 70% of the sites that we host which use a CMS, are powered by WordPress. It's popularity is staggering, and as such every day we handle a wide number of queries relating to WordPress, from basic how to's, through to more advanced debugging.

One issue that comes up from time to time is speed.

We've invested heavily in developing a WordPress hosting infrastructure that's as fast as can be - with PHP7, OpCode Caching, HTTP/2, super-fast SSD based disks and more. Compared to most hosts, our platform for WordPress already is super-fast. But nonetheless, there were still cases where some of our customers ran into speed issues, usually the result of there being too many plugins, poorly written plugins, or unoptimised themes.

Historically, to get faster speeds out of these sites might have involved an upgrade to a virtual or dedicated server, where we can use specialist caching solutions and also leverage more server power. However, thanks to the introduction of server side page caching and backend database caching on our business hosting plans, these technologies are now also available without going to the expense of running your own server!

If WordPress was fast before, these technologies turbo charge it.

Let's investigate each tool. As we do so, we'll implement this on a real customer website and show you the effects by doing a Pingdom speed test report before and after.

To begin, here is the initial, unoptimised speed test result:

As you can see, the load time of this site is actually pretty decent in 1.33 seconds. There are a few highlighted issues for resolution in the Performance insights.

Further down in the report, in the 'Waterflow' section, we can analyse the time that PHP takes to generate the page. This is known as the Time to First Byte, or as Pingdom term it, the 'Wait' time.

The unoptimised wait time here is 336ms.

So, lets move onto our first optimisation.

Database Caching: Redis

We go into detail on exactly what database caching is in an earlier post, which you can find here. In summary, with database caching enabled, many of the redundant and time consuming database queries used to render WordPress will be stored in the server's RAM, rather than fetched from MySQL.

We provide support for both Redis and Memcached, and whilst WordPress supports both, as highlighted in the aforementioned post, we'd always advocate using Redis if both options are available.

We are going to be enabling Redis as the database and backend cache, following this guide.

With that enabled, we'll run another Pingdom speed test to see what impact this has had on load times.

The load time in this test has now reduced by around 1/3 of a second. This is due to the fact that many of those database queries that needed to be made previously to render the page, no longer come from the database - but instead come from the server's RAM, which is much faster

We can see that the wait time, or the time for PHP to generate the page, has now reduced to 251ms:


On the server side, we'll now be seeing significantly reduced MySQL processing, which on a busy site can dramatically decrease your server resource usage and help keep your hosting costs low as you need fewer resources to process each visitor, allowing you to scale without needing tons of computing power.

Server Side Page Caching

On our business hosting plans, our server side page caching is powered by LiteSpeed Cache, which comes complete with a WordPress plugin so setup is easy and simple. We've already taken a dive into what server side page caching is in a previous post. If you're not familiar with the concept of 'server side' page caching and how this differs to standard caching plugins for WordPress, it might be worth a read.

In brief, though there is a plugin that you install into WordPress to leverage LiteSpeed Cache, the plugin itself is not doing any of the caching - that's handled by the web server. What the plugin does, more simply, is handle the cache clearing - meaning that if you update content in your WordPress admin area, the relevant pages are automatically cleared from the server side cache.

So let's install the plugin in our example WordPress site and see what happens. Initially, we'll do no configuration of the plugin and just measure what the impact is on its default config.

As you can see from the above, the load time has dropped significantly and we're now down to 721ms. What's more, many of those 'Performance insights' errors that will have been affecting the sites Pagespeed score, so important for Google rankings, have switched to grade A.

The 'wait time' has also shot down to 31ms. This is because PHP isn't loaded at all to render the page, the page contents can now come straight from the web server itself.

Application Level Optimisations

However, the story doesn't end there. The LiteSpeed Cache plugin does so much more than just turn on the server side caching, and clear the cache when you change content. It has been kitted out with a vast range, and I mean a really vast range, of optimisation and performance turning configurations, and is a true all in one acceleration and optimisation tool for WordPress. It is by some margin the best tool we've ever seen for WordPress optimisation, and it's slick integration with web server level technologies really makes it a no brainer.

You can take a look over the all of the configuration options that are available in the plugin here, including screenshots. We've also created a guide which runs through how we'd advise setting it up, which you can find here.

After applying the application level tweaks, the speed test is as follows:

Here we've seen a significant reduction in the number of requests required to generate the page, thanks mostly to merging/minifying. We've also seen a slight reduction in page size, thanks to the automated image optimisation.

The speed has dropped slightly, but most significantly, the overall performance grade has now increased to A and the site has an extremely high PageSpeed Score, which will have knock on benefits for the sites Google Ranking.

Pretty cool huh?

Now lets add the cherry on the cake - CloudFlare, and their Railgun optimisation technology.

We've touted the benefits of CloudFlare's network many times before. CloudFlare will add your static content, such as images, javascript and CSS files to their superfast CDN network. This will bring those files closer to your visitors, wherever they are in the world, speeding up your site worldwide.

As a Kualo customer, you also get access to their Railgun technology. This means that not only your static content can be edge cached on the CloudFlare network, but also your website pages too. CloudFlare is unaware of when content changes on your site, so what Railgun does is to analyse the changed data between our server and what it has stored in its cached. If any data has changed, it will only transfer the necessary bytes to make that change. That data is transferred across a permanently fast connection, and is highly compressed.

The end result is incredibly fast sites worldwide.

Let's take another look at the Pingdom speed test now:

We've shaved off yet another few precious milliseconds and now have a supercharged site, more than twice as fast as it was previously.

The results can be even more impressive on more complex sites too.

Do you have a WordPress site?

Are you interested in seeing how our performance acceleration technology can help turbo charge it?

Please get in touch to discuss your requirements!

You might also like...

About the Author

Jo Stonehouse is the Founder and Managing Director at Kualo. He loves helping businesses succeed online, and is based in London were he lives with his wife, Sali, daughter Seren, son Griff and dog, Milo.