In terms of performance, WordPress is great out of the box for smaller-scale websites. Pages load quickly on the front end, and data is retrieved from and saved to the database wicked fast on the back end. But once you try throwing thousands and thousands of posts into the database with lots of metadata for each of those posts, you’re likely to start seeing your website slow down dramatically. It’s a common problem and luckily there are a ton of great solutions out there to address it.
One of the most common tools available to combat this issue are caching plugins. Each of the many plugins available for WordPress have their own approach, but they generally work by placing the end result on a computationally-expensive action (loading a page, for example) in a temporary storage location. This data can be retrieved much faster the next time it’s needed by simply pulling this stored value, instead of having to build it again from scratch. Once this stored value reaches a predetermined age, it can be regenerated and cached again to ensure the user isn’t being sent old data.
There are many of these plugins being used all over the web to vastly improve the speed of WordPress sites, such as
Since each plugin has its own approach to caching WordPress data, there are pros and cons to using each of them. Generally speaking though, the most popular and proven options available have a common issue: Out of the box, they won’t cache data for logged-in users.
At first glance, this might seem like an oversight. What’s the point of caching data if your subscribers and editors aren’t going to see any benefit? But this functionality is very purposefully omitted, and for good reason. Imagine running a WordPress site with exclusive content for paid subscribers. If the data cached was intended for one of these subscribers, it could very easily be served up to a non-subscriber who visits the site, effectively allowing people to circumvent paying for your exclusive content.
This begs the question: Are membership-driven websites out of luck when it comes to caching?
Enter Fragment Caching & the WordPress Transients API
While it’s true that in our scenario we can’t safely cache the content of an entire page load, this doesn’t mean we can’t take advantage of caching. This is where fragment caching comes in. With fragment caching, instead of caching an entire page load, individual sections of code which take a lot of time and resources are identified and cached. Using this method, expensive queries or pieces of markup we know will be the same for all users can be computed once and stored for later reuse. The overall effect on response times will depend on how many code fragments can be identified and cached, but it’s easy to see how quickly the savings could start adding up on large and complex websites.
Implementing fragment caching in WordPress is dead simple, thanks to the Transients API. The Transients API is a method of storing temporary data in the WordPress database with an arbitrary expiration timeframe. Take the following example:
On line 2, we call the get_transient method, which attempts to pull a cached value for a transient named “foo_transient.” If the transient exists and hasn’t expired, the cached value will be returned and the code skips to line 7 to do something with that value. On the other hand, this method will return false if no cached value is found, or the value found has expired. In this case, lines 3 - 5 are executed and the new value of $foo is computed and saved as “foo_transient” with an expiration of 2 hours from the current time.
If you’re using the awesome Timber plugin to build custom themes like we are, you even get access to some syntactic sugar which makes using this API even easier. The following snippet does the same thing as the example above:
While fragment caching isn’t a silver bullet when it comes to speeding up WordPress sites, it can be an effective tool for shaving seconds off your load times. Combine it with other methods for optimizing WordPress, and you’re guaranteed to see faster load times across the board.