With WordPress Hosting, there is no need for 3rd party caching plugins such as Super cache or W3TotalCache.Sign Up Now
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.
With WordPress Hosting there is no need for 3rd party caching plugins such as Super cache or W3TotalCache instead the WordPress Hosting has 4 distinct caching layers.
Each has been tested to provide maximum performance and flexibility with the goal of keeping your site fast if you have 10 or 1000 visitors.
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.
How this works:
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:
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 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.
How this works:
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.
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.
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.
In addition we assist with:
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.
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 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.
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.
Beyond dedicated caching there are some plugins which clients using our hosting find useful and we generally recommend alongside our own caching:
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.
Optimises images and automatically resizes them also brings support for WebP images.
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.