If you’ve spent much time learning about computer performance, you’re probably at least vaguely familiar with the idea of caching. Caching means a lot of things in a lot of different contexts, but at the most basic level it is storing something in a more-ready and quicker-to-access state so that you can more quickly deliver the final result. In the simplest explanation, the WordPress Transients API is a tool for caching.
Why would you want to use a transient?
In the context of WordPress you most often hear caching in the sense of “full page” caching. The classic example of a plugin like WP Super Cache does this — it caches full pages just about to be sent out to a visitor and stores it so that the next visitor to ask for that specific page will get the same version as the previous visitor without your server having to build it. In some situations this is ideal, and can have a really significant impact on site speed.
You can get performance gains from storing things other than full pages that will make the whole of your site faster to deliver. Common examples are the results of long-running computations, slow results from remote servers (a pulling of data from Twitter, or Facebook, for example), or large database queries.
But there’s also the idea of “partial” or “object” caching. Rather than storing and getting performance gains from saving a full page response, you can get performance gains from storing things other than full pages that will make the whole of your site faster to deliver. Common examples are the results of long-running computations, slow results from remote servers (a pulling of data from Twitter or Facebook, for example), or large database queries which are likely to be slow and change infrequently. In WordPress, the way to store this type of data with the Transients API.
What is the WordPress Transients API?
Quite simply, the WordPress Transients API is an abstraction of the various means and methods of caching data in a server environment so that WordPress developers don’t have to worry too much about the specifics of each WordPress site’s operating environment.
Why this abstraction? At the most basic level, we just want to store a hunk of data that we give a name and be able to get it back quickly. This so-called “key value store” is exactly what in-memory caching systems — like Memcached — allow. If you’re not familiar, let’s just suffice to say that Memcached is a very simple and powerful way to store blobs of data and retrieve them later. It’s much faster than the MySQL database or the filesystem for data storage and retrieval, and skips the complexity of figuring out the specific mechanism. But, especially important in the world of WordPress, it’s not everywhere. In fact, for WordPress, it’s not even on most servers where WordPress runs.
So what the Transients API does is allow a WordPress programmer to think about the data they want to cache just like they would if Memcached or a similar key value storage system existed, but not have to worry or program around the fact that it’s not always there. It’s not essential that you know this, but when Memcached or other forms of caching aren’t available, WordPress uses its regular database, the options table to be precise, to provide the same functionality as you’d get with an in-memory cache. (Though unfortunately you don’t quite get the the same speed.)
The final thing to know is that these “caches” or “transients” aren’t meant to be permanent, the Options API — which we recently explained — is what we use for data we need to have on a WordPress site. (See Ryan McCue’s great post about that.) There’s a common saying among computer scientists:
There are only two hard things in Computer Science: cache invalidation and naming things. — Phil Karlton
We’ll leave off naming things for now, but the easiest way to deal with cache invalidation is to never do it. So when we cache, we just make our blob live for a certain period when we expect it will remain “fresh” enough that we still want to use it, and then silently let it disappear.
How to use the Transients API
The Transients API, just like the Options API, is pretty simple. What you need to understand is that you’ll have a pair — a name and a value — that you’re trying to store. Then you just use them to store and retrieve a transient. You’d not do these two actions side-by-side in your actual code, but if you did it looks like:
$bool_response = set_transient( 'our_awesome_value', $value, 86400);
$value = get_transient( 'our_awesome_value' );
Let’s talk through what’s happening here: we’re calling the function set_transient, and setting and existing $value we have to be stored as a transient named our_awesome_value. This storage is to last for a full day — 86400 is the length of a day in seconds. There are some nice constants available in WordPress if you’d rather have better named time intervals. As the garbage variable $bool_response is meant to demonstrate, set_transient tells you if it works or not.
You can always call
get_transient, even for values you’ve not set, but be careful because it simply returns a booleanfalsefor your variable on failure.
The second line is even simpler — we call get_transient() with the name of transient we want to get back. You can always call get_transient, even for values you’ve not set, but be careful because it simply returns a boolean false for your variable on failure.
That’s it. There are four other functions — a delete_transient, and then three alternatives you use in WordPress Multisite for transients that should be used outside of a single WordPress “site”. But I don’t really think any of them need a further explanation.
What we’ve learned about WordPress transients
I hope you feel like you’ve now got a pretty good sense of why you would use transients — to cache expensive data for quicker page load — what a transient is — a useful abstraction of the ability to store a key value pair for later use — and how you’d use it in WordPress. As always comments are open if we missed something or if you have a question.