WordPress Caching

Caching improves performance by allowing quick access to things that would normally take time to create. Caching can be complex and easy to make mistakes with so we have taken a lot of time with our WordPress Hosting to getting the balance right.

Full Page Caching

Full page caching is what most people think of when you talk about caching in WordPress this takes the rendered output of pages and stores it completely as a flat file which is stored in Memory.

When the browser makes a request for a page from the web server, the webserver in our case powered by Nginx looks in the cache, if it sees the page is cached, it retrieves the page directly from the cache. If it doesn’t see it in the cache then it carries on generating the page by contacting PHP-FPM which in turn makes requests to the database. Once it’s finished it passes the rendered page back to the browser and also puts it in the cache. The next person to request the page, is given the cached result.

Caching full pages is the most effective forms of caching as it eliminates most of the work done and delivers the page as quickly as possible.

Because the returned results are identical, if a visitor should see a personalised result they will not and in some extreme cases may see data they are not meant to. Full page caching is only suitable for pages that do not have personalised content.

For our Full page cache on the Managed WordPress Hosting we actually cache two versions of every page, a desktop and mobile version. This allows sites that render very different pages to mobile devices to not accidentally show the full desktop version and vice versa.

By default our Full page caching is on, but it automatically bypassed in the following situations:

  • If a user is logged in
  • Has a cookie wordpress_*
  • The URL has been marked as not to be cached within your Hosting Tools Plugin

This normally covers most normal situations where you would want to bust the cache, it’s important to note if you are editing your site and are logged in, you are NOT seeing the cached version of the site.

Our full page caching can be turned off but we wouldn’t recommend it, it is automatically cleared after actions such as editing a post, or modifying settings in the options/appearance section. There is also the option to clear the cache within your WordPress admin area and our Client Control Panel.


Object Caching

Object caching refers to an API written inside WordPress to provide the ability to cache results it is used by Plugins and Themes by default. One of the features of the object cache is the option to instead of storing this temporary data in your database move it to a key storage value system. For the WordPress Hosting we use Redis as our object cache service.

The object cache works by a plugin or theme asking the cache, if it has the item its trying to retrieve that could be a database query an RSS feed or just about anything. If the cache doesn’t have the results then its up to the plugin/theme to regenerate them and put them in the cache.

The object cache is also used for transients which are temporary bits of data stored in WordPress via the transients API.

The object cache should just exist and for most people they won’t know it exists, it simply speeds up your site. There are some odd cases where the object cache causes issues, this normally comes where a plugin/theme looks up to the cache, but writes to the backend without also updating the cache and then is unsure what has happened to the data.

These cases are rare but do occasionally happen, in such cases our usual suggestion is to contact the plugin developer as this will be an issue for multiple people. The object cache can in some cases be turned off by adding a define into your my-config.php file.

The object cache provides performance but also stability improvements, by moving data away from the traditional mySQL database meaning its not having to work do hard.


Database Caching

Our WordPress Hosting uses MariaDB for providing a MySQL like database solution and as part of its setup we implement query caching on select SQL results. This allows results which are constantly being returned but are the same to be delivered from the database cache rather than being forced to rerun the same query. Off all the caching we do, this is the lightest and most conservative keeping caches for only very short time and siding normally on rebuilding a query rather then using the cache. It kicks in primarily when a site hits high concurrency with lots of visitors on the site at any given point. Because of the nature of the caching on the WordPress Hosting there is nothing to configure or setup and it kicks in automatically, it can’t be disabled by clients however any issues and our support team can look at.


Function Caching with OpCache

Our final layer of caching is within PHP itself and we use OpCache which provides caching common functions results being triggered. PHP compiles each time the script is triggered, while OpCache provides a precompiled version of functions commonly used. This caching similar to database caching is designed to provide some performance benefits but really aimed at improving concurrent connections.

Opcache cache size and what it caches automatically updated, depending on the total number of PHP files within sites. This process is handled around midnight on the WordPress Hosting, so if you radically change the amount of files it may take up to 24 hours for the full performance benefits to kick in. small amount of file changes, does not affect performance.


Other caching and performance bits

Browser caching

Browsers cache static assets, so rather then re-asking the server for the assets it simply takes them from the browser cache. It’s the reason people ask you to refresh your browser, or look in private browsing. Your browser’s cache can normally be “hard refreshed”. The browser knows what to cache, because servers send an expiry header, this is not always obeyed. By default on the WordPress Hosting images, css, fonts and css files are sent with an expiry header of 30 days.

 

Gzip compression

By default, where its supported, all files sent from the WordPress Hosting are sent over compressed by gzip, this reduces file sizes. Certain fietypes where compression has already occured are not gzipped such as images and videos. Gzip compression is pretty standard but the browser or client has to request it. The server simply offers it as an option. We do not currently support Brolti compression.

 

HTTP/2

HTTP/2 provides a faster way for sites to send data between browsers and servers and brings significant speed performance. The WordPress Hosting is enabled with HTTP/2 out of the box to get it working, you just need a SSL certificate (which you can get for free via the client control panel) once the SSL is enable, so is HTTP/2.


Using other caching plugins

We do not recommend using other caching plugins with the WordPress Hosting, most require modifying the object and advanced cache droppins which will cause our own caching to become unstable. One of the big advantages of being able to run caching on the server rather then through a plugin is the performance benefits this brings and using caching plugins instead of our inbuilt caching will almost always lower performance and add complication.

While we don’t explicitly stop people using their own plugins we do advise people to disable them and when we handle inbound free migrations we will automatically turn off caching plugins if we find them.

 

Performance plugins generally

Beyond dedicated caching there are some plugins which clients using our hosting find useful and we generally recommend alongside our own caching:

 

Remove query strings from static resources

Does what it says, it removes the ?version=4.6.1 strings located on css and js URLs added by WordPress. This means those files will be cached both by our full page cache and can leverage browser caching.

 

EWWWW Image Optimizer

Optimises images and automatically resizes them also brings support for WebP images.

 

Lazy Load

Uses javascript to load images as they are needed on the page, avoiding having to wait for the image before the page is rendered.

 

JetPack

Provides Image and Video CDN as well as Lazy loading options, to load images after the rest of the page assets have been loaded. It is also one of the most popular WordPress plugins.

 

MinQueue/Autoptimize

Two plugins with similar functionality to provide concatenation and minification of assets such as CSS and Javascript while using HTTPS and HTTP/2 which comes with the WordPress Hosting out of the box the need to concatenate files is reduced it is still helpful to minimise image file sizes.