WordPress rebuilds every page from the database each time somebody asks for it. The same queries run again and again, and on a busy site that repetition is where the time goes. An object cache holds the results of those queries in memory on the server, so the work is done once and then reused.
What is available
We offer object caching as a service on the hosting itself, sold as WordPress Speed Acceleration. It uses Redis, runs inside your own account, and is switched on per site by us. There is no plugin to install or configure and nothing for you to keep updated.
This is a change from how things used to be. Redis was not previously available on our shared servers and earlier versions of this article said so. It is available now, one isolated instance per account, and it is what we recommend.
£20 a year per site. Open a ticket and we will enable it. There is more detail in WordPress Speed Acceleration explained.
What about memcached?
Memcached is still installed and still works, and a handful of sites use it through W3 Total Cache. Two things are worth knowing before you choose it. It is a single service shared by every site on the server rather than something isolated to your account, and the cache it is given is deliberately small. The Redis service above is isolated to you and sized for your site, so if you are setting up object caching for the first time, start there.
Only one object cache at a time
A site can have exactly one object cache. If yours already has object caching switched on through W3 Total Cache, a Redis plugin or anything similar, that has to come off before we enable ours. Two caches competing for the same job is worse than having none.
The leftover file that keeps causing trouble
This is the part that catches people out, so it is worth reading even if none of the above applies to you.
Any object cache leaves a file called object-cache.php in your wp-content folder. WordPress loads that file directly, whether or not the plugin that put it there is still installed. So you can deactivate a caching plugin, delete it, see a clean plugins screen, and still have cache code running on every request.
When that leftover file points at something no longer present, it fails on every single page load. WordPress falls back to its own internal cache so the site keeps working and nothing looks wrong on screen, but an error is written to your log every time. We have seen an account build a multi-megabyte error log this way without anyone noticing.
If you have moved to us from another host, or you have removed a caching plugin recently, check whether wp-content/object-cache.php is still there. If it is, and you are not deliberately using it, remove it.
Object caching is not page caching
These solve different problems and a busy site usually wants both. A page cache stores the finished HTML and hands an identical copy to the next visitor, which is ideal for pages everybody sees the same way. An object cache works underneath, on the queries themselves, so it also speeds up the pages a page cache must never store: a basket, a checkout, My Account, a logged-in member area, a set of search results.
If you run a shop, read Caching WooCommerce correctly, and what must never be cached before switching any page cache on. Getting the exclusions wrong can show one customer another customer's basket.
