I’ve been learning a lot about caching in WordPress lately and thought I’d share a few things I’ve learned (and document them for myself).
Caching is a common technique used to speed up your experience on the Internet. The general idea is that instead of requesting resources (images, files, etc.) directly from the source, you instead request them from a cache, which is generally faster. In the case of WordPress, each time you request a page, the server has to process a bunch of PHP and come up with the HTML to render. Depending on your site, this processing can be pretty resource intensive, making you wait an extra second or two for the page to load.
Caching speeds up that PHP processing by caching the result(s) for future use. Let’s say you have a sidebar widget that displays the most recent posts. Without cache, each time a page was loaded, WordPress would have to query the database and find the three most recent posts. This is inefficient since this list likely doesn’t change between every page load. With cache, the first time this list is generated, it makes sense to put it in cache so that next time someone needs the list of most recent posts, it doesn’t have to query the database–instead, it just pulls it directly from cache.
When the list of recent posts changes (i.e. you publish a new post) you can “bust” the cache and delete the old list. The next time a page is requested, it’ll query the database, get the new list, and put in the cache for any future requests.
Now for the WordPress specific implementations of cache:
WP Object Cache
The object cache does just that–caches objects. It does this by using key/value pairs, with an optional group (for namespacing purposes) and expiration date. By default, however, this cache is not persisted–it lives for the duration of the request only. The WP documentation says that if you need to guarantee that something is cached, use the Transients API instead.
The Transients API
Transients are also cached objects using key/value pairs, like the Object Cache, but with two major differences:
- They are persisted in the wp_options table by default (Object Cache isn’t persisted by default), and
- They require an expiration date (which is optional for Object Cache)
Transients are better suited for information that you know will expire.
If you have a persistent cache plugin enabled and configured, then it changes the behavior of both the Transients API and the WP Object Cache. Most notably: with persistent caching enabled, the Transients API will use the WP Object Cache methods and store to persistent cache instead of saving to the wp_options table. These two caching methods are essentially combined into one and stored in persistent cache.
For example, calling this method:
set_transient( $key, $value, $expiration );
will actually do this:
wp_cache_set( $key, $value, 'transient', $expiration );
The object cache group is automatically set to ‘transient’ when using the Transients API with persistent cache.
How Persistent Cache Works
The way persistent cache works is pretty simple. When persistent cache is configured, each request that would normally go to the database will first check the cache. If nothing is found in cache, then the request continues on to the database. Once the request gets a response from the database, it puts that response in cache for future requests.
With persistent caching enabled, if the requested object is cached, the database is never touched.
Persistent Cache Plugins for WordPress
There are several WordPress plugins that offer persistent caching. You might be familiar with a few of the major players, like W3 Total Cache or WP Super Cache. I’m not going to go into detail on the pros and cons of the plugins here–there are plenty of blog posts out there that address this. Any plugin that deals with caching is going to take some configuration, so expect that upfront.