Transients API: How to Cache the Slow Parts of WordPress

If your WordPress runs a slow query on every page or calls an external API (say a currency rate or a follower count), you pay that cost again for every visitor. The Transients API is a built-in WordPress mechanism that stores that result for a set time, so the heavy work runs once and later visits get the ready-made answer from cache. No plugin required — it is all part of WordPress core.

What a transient is

A transient is a "key → value" pair with an expiry. Unlike a regular option (update_option) that lasts forever, a transient has a built-in expiration date. Once it passes, WordPress treats it as if it does not exist, so your code recomputes and saves it again. Ideal for data that is "fresh enough" even a few minutes or hours later.

Three functions to know

• set_transient( 'key', $value, $duration ) — store a value for a given time in seconds.
• get_transient( 'key' ) — return the value, or false if it has expired or does not exist.
• delete_transient( 'key' ) — remove it manually when you know the data is stale.

For durations use WordPress constants for readability: HOUR_IN_SECONDS, DAY_IN_SECONDS, WEEK_IN_SECONDS.

The typical code pattern

Almost every transient follows the same shape: try the cache, and if nothing is there, compute and store.

$data = get_transient( 'latest_rates' );
if ( false === $data ) {
  $data = call_the_api(); // the slow part
  set_transient( 'latest_rates', $data, 6 * HOUR_IN_SECONDS );
}
return $data;

The first visitor pays for the API call; everyone else for the next 6 hours gets the result instantly. If the API goes down, you have the last good result in cache instead of a blank page.

Where transients are stored

By default, transients live in the wp_options table. That is convenient but has a downside: expired transients are not deleted immediately and over time clutter the table, which slows the loading of autoload options. So clean the database periodically. If you have a Redis or Memcached object cache (many quality hosts offer one), WordPress automatically stores transients in memory instead of the database — reads are then even faster and do not burden wp_options.

When to delete a transient manually

A transient expires on its own by time, but sometimes data goes stale earlier. For example, you cache a product list for an hour, but an admin adds a new product after 10 minutes. In the hook that fires when a product is saved, add delete_transient( 'product_list' ), so the cache refreshes on the next visit. This is called cache invalidation and is key to accuracy.

Common mistakes

First: caching user-specific data under the same key — everyone then sees someone else''s data. For such cases add the user ID to the key. Second: an overly long key; the limit is 172 characters. Third: relying on a transient for something critical with no fallback logic — if the value is false, the code must know to recompute rather than break.

Frequently asked questions

Are transients different from page cache? Yes. Page cache stores the entire HTML output; transients cache one small piece of data inside PHP. They are useful precisely when you cannot cache the whole page (e.g. partly dynamic content).

Do I need a plugin? Not to use it — the Transients API is part of WordPress. A plugin (or an object cache on your host) only improves where transients are stored.

Our WordPress hosting plans ship with server-side caching and NVMe drives, and an object cache keeps transients in memory for maximum speed. See our plans and pricing.