When a visitor comes to your site they are generally seeking one thing: information!
One of the goals of web applications like WordPress (and those systems that run on top of it, such as our own plugins) is to deliver this information as quickly as possible.
Often, though, interaction with the sources of this information - be that the site's own database or even a third-party service that is accessed over the web - just isn't fast enough, particularly if a site is fielding lots of traffic or answering a request for which many individual pieces of content need to be retrieved (think Month View: it isn't uncommon for this to contain upwards of 100 different events!).
Caching is one way we can work around and alleviate such bottlenecks. In this post, we will look at just a few forms of caching, how and when we use them, and what you need to be aware of.
When it takes a long time to retrieve a piece of information - or even if it is fast, but taxes the server more than normal - a common solution in the WordPress environment is to make use of the object cache.
For instance, when the database is queried to create the main upcoming events list, all those events are then immediately stored in the object cache (right in the server's memory) so that they can quickly be retrieved in the future: pulling data like this out of the object cache is far, far faster than querying the database afresh.
Suppose that in the sidebar for List View you have a widget that highlights one of the listed events (and provides more in-depth information - the complete description, perhaps, rather than just the excerpt). Since the event is already stored in the object cache it can be retrieved speedily and with very little overhead.
The problem with what we just described is that as soon as the web page has been put together and delivered to the visitor, the object cache is cleared.
The next time someone visits, it all begins again. That may make it seem like a waste of effort, yet it isn't entirely a waste - just think of the previous example involving a sidebar widget: caching saves time and effort even if it is cleared after each request.
However, it would often be preferable if it wasn't cleared at all. In the context of caching, this is what we mean when we talk of persistence and there are several plugins you can install to help with this.
Indeed, some web hosts, particularly those specializing in WordPress hosting, actually set this up for you - so you don't need to install and configure anything at all (however, if you are in doubt it is always best to ask if this is something they facilitate).
Once persistent caching is in place there is generally a tremendous improvement in relation to the site's performance.
Thinking back to our List View example - the range of events shown here is identical to what we show in photo view, only the presentation changes. With persistent caching, both views benefit because they can both use the stored list of event objects without hitting the database. As a result, your users will see a faster load time as they click around your calendar.
So far we've covered caching of the raw data we need to build up views and pages. Though this can offer a huge speed boost, the work of taking that data and transforming it into nice, presentable web pages still needs to be done for each individual request.
Page caching is a process where we take the generated web page and store it in a cache, eliminating even the final step of generating HTML. There are many different ways of implementing this and there are plenty of plugins that can add this capability to your site.
As a point of note, The Events Calendar comes equipped with some highly specific caching facilities not unlike page caching but that apply only to month view. To learn more about this specifically, please read this article which covers month view caching in more depth.
However, this can have some drawbacks - which takes us neatly on to the last aspect of caching we're going to explore here.
How long should we cache data for?
Clearly, it shouldn't be forever. Event details may be changed and updated, for example, and we want visitors to see that new information, not the outdated stuff! So we need a process for clearing and refreshing the cache - and this is what we mean when we talk of invalidation.
In practice, this is less of a problem with object caching. Many tried and tested systems baked right into the heart of WordPress do an admirable job of dealing with this and, wherever our own plugins interact with the object cache, we've also worked hard to ensure the cached data is invalidated and refreshed at appropriate points.
When page caching is used, though, it is often implemented by a third party plugin with no knowledge of events or how they work. This can result in some unusual side effects that you may notice when you use such a solution:
- If you update an event's description or start time, you may find the change is not immediately reflected on the front end
- Normally events that have expired are no longer listed in the upcoming events list - but with page caching, it's possible they will linger longer than you might desire
- When you visit month view you typically expect to see the current month first of all - again, here, it's not impossible that you will see the last cached month instead
These problems are far from insurmountable - most caching plugins will let you clear the cache with the click of a button and can usually be configured so that cached pages are automatically refreshed after a short interval - but they can trip people up even so which is why we wanted to highlight it.
Our plugins make use of caching right now, without you having to do anything. To truly take this to the next level though and reap even more benefits it is at least worth adding a persistent object caching layer.
Whether you use an existing plugin for this or lean on your web host (as above, some provide their own caching systems as part of the service) is up to you - but it can make a significant difference to the performance of your site.
Page caching is definitely also worth consideration, just beware some of the common gotchas!