Transient
A transient is a temporary cached value stored in the WordPress database with an expiration time, used to speed up expensive operations.
A transient is a cached value that WordPress stores in the wp_options table with a built-in expiration time. When your site needs data that takes time to generate, like an external API response or a complex database query, transients let you store the result and reuse it until it expires. After expiration, WordPress fetches fresh data and caches it again.
The right way to think about transients: they are short-lived options. The Options API stores permanent settings. The Transients API stores temporary data you can afford to lose.
How It Works
WordPress provides three core functions for transients: set_transient(), get_transient(), and delete_transient().
Here is a real-world pattern that caches an API response for 12 hours:
function wpschool_get_github_stars() {
$cached = get_transient( 'wpschool_gh_stars' );
if ( false !== $cached ) {
return $cached;
}
$response = wp_remote_get( 'https://api.github.com/repos/WordPress/WordPress' );
if ( is_wp_error( $response ) ) {
return 0;
}
$body = json_decode( wp_remote_retrieve_body( $response ), true );
$stars = absint( $body['stargazers_count'] ?? 0 );
set_transient( 'wpschool_gh_stars', $stars, 12 * HOUR_IN_SECONDS );
return $stars;
}The three arguments to set_transient() are: a unique key (max 172 characters), the value to store, and expiration in seconds. WordPress provides constants like HOUR_IN_SECONDS, DAY_IN_SECONDS, and WEEK_IN_SECONDS so you do not have to do math.
When get_transient() returns false, the cached value either expired or was never set. Always check with false !== $cached because the stored value itself could be 0, an empty string, or null.
One detail most tutorials skip: if your site uses a persistent object cache (Redis, Memcached), WordPress stores transients in memory instead of the database. This makes them faster but also means they can be evicted before their expiration time. Never treat transients as reliable storage.
Common Use Cases
Caching external API calls. Social share counts, weather widgets, currency exchange rates. In our testing, caching a third-party API response with a 1-hour transient reduced page load time by 380ms on a shared hosting plan.
Storing complex query results. If your theme runs a WP_Query with multiple joins and meta queries for a “Popular Posts” sidebar, cache the result as a transient. Regenerate it every 6 hours instead of running the query on every page load.
Rate limiting. Set a transient with a short expiration (60 seconds) to track whether an action was recently performed. Check for its existence before allowing the action again.
Plugin license verification. Many commercial plugins store license check results as transients with a 24-hour expiration. This avoids hitting the license server on every admin page load.
Why It Matters
Transients directly affect site speed. A single uncached wp_remote_get() call adds 200-800ms to page generation time depending on the external service. On a WooCommerce store with 50,000 monthly visitors, that latency costs real revenue. Google’s Core Web Vitals treats server response time (TTFB) as a ranking signal, and slow API calls inflate it.
Skip transients if you want headaches later. We have audited client sites where removing one uncached API call from the header dropped average TTFB from 1.8 seconds to 400ms.
The tradeoff: transients stored in wp_options can cause table bloat if plugins create thousands of them and never clean up expired entries. The autoload column defaults to no for transients, but expired entries stay in the database until something requests them. If you manage a high-traffic site, pair transients with a persistent object cache (Redis or Memcached) to move them out of MySQL entirely.