WordPress platform performance updates

While our WordPress Hosting performs very well for most users, every site is not built the same; as such we’re always working hard to improve performance for every use case, whatever it might be. When we do see performance issues on the platform it’s nearly always due to poorly coded plugins or themes. In these cases, we can often help clients by recommending alternatives or working with their plugin and theme developers to help them better understand the issues and provide fixes.

Sometimes this just isn’t possible, so we’re also always tinkering away in the background to improve the platform for more and more use cases – even when some plugins don’t behave as we would want. With that in mind, in the past week we completed the latest updates to the WordPress Hosting platform with an upgrade to Nginx 1.13 and PHP 7.2.  This is the just the latest of many performance and security changes we have made during the past couple of months which have seen load times drop for the vast majority of clients on WordPress Hosting. Dramatically so in some cases!

Following the completion of these updates, the platform now runs the following:

• Nginx 1.13 with full ALPN support allowing HTTP/2 support for all browsers
• PHP 7.2 with the most common modules you would expect
• MariaDB 10 as our database engine which is a drop in replacement for MySQL
• Redis as the object cache storage system

These items represent quite broad changes under the hood but there are numerous smaller moving parts.  The biggest of these is our caching layer, which has been at the heart of the recent changes.

• Right at the front, we use Nginx Fast-CGI cache and where possible cache full pages. This is not always possible and sometimes not even wanted. For example you wouldn’t want to fully cache a shop’s checkout page.
• After that, WordPress has a built in object cache which we store in Redis. This is also where transients are located. The object cache works very effectively to speed up retrieval of objects, but we identified a small group of plugins and themes having specific issues here.  We recently provided a way to disable this cache if needed (via the 34SP tools section in your WordPress dashboard).
• The next layer is PHP OpCache which is a built-in caching layer storing the output of regularly used PHP function results. This rarely shows up in performance of the front end of the site, but changes here means the wp-admin area load times have improved considerably for most users.
• Finally MariaDB has a caching layer for regularly used database queries.

With all these enhanced layers of caching, even with no full page caching taking place we can still cut load times and boost performance in most scenarios. Moreover, during the last two months our test sites have been used to tweak the configurations of the cache systems, ensuring that they rarely return stale or incorrect information.

Testing

The current cycle of updates began in autumn 2017 when we selected a number of candidate sites on the platform (with client permission of course).  Replica test sites were created that we ran through a gauntlet of tools and tests, simulating various traffic loads. Every tweak made was retested until we were reliably seeing performance gains for the majority of these test sites.

For these tests we relied on a range of tools, including a private instance of webpagetest.org hosted on a VM inside our network to eliminate networking issues. This provided an overall view of a site’s loading experience from the perspective of a normal user. It also allowed us to make some decisions regarding some of the automated front end optimisations we do for clients’ sites.

Next, each site had the xdebug profiler enabled and the results of tests were put through cachegrind. This allowed us not only to see bottlenecks in code, but also where caching had been effective and for what type of code.

Because all of our WordPress Hosting is containerised, we could enable monitoring on the containers to look at memory and CPU usage.  This allowed us to look at increasing the number of PHP worker processes and tune individual cache sizes, ensuring sites could still operate well within their containers.

The results

For some sites, these improvements resulted in millisecond load improvements, but when pages are loading in under 300ms that’s still a notable proportion! For some of our least optimised sites we saw larger gains; one site reduced loading time from 12 seconds down to 5.  This is particularly impressive as the site’s previous hosting was averaging around the 20 seconds to load each page .  The client was already happy with the earlier performance improvements, so this is the icing on the cake!

For most of our clients, the speed improvements will really show in the admin area.  Since Christmas 2017 this should already feel snappier and more responsive. Also notably, sites running WooCommerce should feel much quicker when using variable products.

Other changes

Earlier this month we disabled mod_pagespeed.  This module provides some out of the box front end performance improvements, but due to some compatibility issues we were only enabling a small number of its options. Indeed when we turned it off site load times actually improved with no noticeable changes to clients’ webpagetest scores. This is not to say mod_pagespeed is not a great module for nginx (it is!), but it is best used where you can tailor it to an individual site.

We have also added a plethora of image optimisation tools to containers, specifically jpegoptim, optipng, pngquant, and gifsicle.  These tools can be used to optimise various image types and are used from the CLI or through plugins.

Moving forward

Of course, this is far from the end of our work to improve performance. Our team will continue to push small changes and eke out more performance over the coming weeks and months. If you see us at a WordCamp or usergroup, do come and have a chat about what we are doing to improve cron performance or our work to provide some more tailored front end optimisations.