Persistent Object Cache in WordPress: Worth It?

A persistent object cache keeps the results of WordPress database queries in Redis or Memcached so the next request can reuse them instead of asking MySQL again. It is worth adding when you have requests that cannot be page-cached — admin screens, logged-in users, a cart, REST calls, cron — and it is close to worthless on a brochure site where every visitor gets a cached HTML file from disk. Site Health will recommend one long before you need it, and that recommendation is the reason most people end up here.

The mechanism is simple enough to reason about. WordPress already caches query results in memory during a request through WP_Object_Cache; without a drop-in, that memory is thrown away when PHP finishes. A persistent backend gives the same API somewhere to write that survives the request. Nothing about your code changes. What changes is how many of the hundred-odd queries a page runs have to touch the database a second time.

What a persistent object cache actually does

WordPress looks for a single file: wp-content/object-cache.php. If it exists, wp_start_object_cache() requires it instead of loading core’s own cache.php, and from then on every wp_cache_get() and wp_cache_set() call in core, your plugins and your theme is served by that backend. That is the entire integration surface. It is a drop-in, not a plugin, which is why a Redis plugin can keep working after you deactivate it — and why a stale drop-in left behind by a deleted plugin is a classic white-screen cause.

Two details in core’s setup matter when you start measuring results. First, some groups are deliberately never persisted — core registers counts, plugins and theme_json as non-persistent, so those stay per-request no matter what you install. Second, a long list of groups is registered as global, including users, user_meta, site-transient, rss and theme_files; on multisite these are shared across the network rather than scoped per site.

The change you will notice first is to transients. Without a persistent backend, set_transient() writes a row to wp_options; with one, it goes to memory and never touches the table. On a site where a dozen plugins each cache an API response for an hour, that is a meaningful amount of write traffic and table churn removed. It also means the expiry you set is a ceiling, not a floor — core’s own documentation is explicit that a transient can vanish early, so any code that cannot regenerate its value is already broken and you are about to find out.

Why Site Health recommends one, and when it is wrong

The check is not measuring your site’s speed. It reads a handful of counts and compares them to fixed thresholds, and it only runs when the environment type is production. WordPress suggests a persistent object cache if any one of these is true:

Look at that last row again. A thousand posts, or a thousand comments, or simply a thousand rows in wp_options — which plenty of sites reach from plugin settings alone — is enough to trigger the recommendation. That is why a small site with no performance problem gets told it should install Redis. The check is a reasonable default for a hosting platform that cannot inspect your traffic. It is not a diagnosis of your site.

If one of those counts is what tripped it, deal with the count first. An oversized alloptions payload is loaded on every single request, cache or no cache, and auditing and trimming WordPress autoloaded options is both faster to do and more useful than adding a Redis dependency on top of the bloat. The rest of what Site Health flags is worth working through in the same spirit — finding and fixing common Site Health problems covers the screen as a whole.

Core gives you filters if the recommendation is noise on a site you manage. site_status_persistent_object_cache_thresholds adjusts the numbers, and site_status_should_suggest_persistent_object_cache short-circuits the whole decision with a boolean. Hosts also have site_status_persistent_object_cache_url and site_status_persistent_object_cache_notes to point the recommendation at their own documentation.

<?php
// Raise the thresholds rather than silencing the test outright.
add_filter( 'site_status_persistent_object_cache_thresholds', function ( $thresholds ) {
	$thresholds['posts_count']    = 20000;
	$thresholds['comments_count'] = 20000;
	$thresholds['options_count']  = 5000;

	return $thresholds;
} );

Use that on a site you understand, not as a way to make a red panel go green on a site you have inherited.

What it speeds up, and what it does not

This is the part worth being blunt about, because the gap between the two columns is where most disappointment comes from.

Two consequences follow. If your complaint is that the dashboard crawls, an object cache may help but it is not the first thing to check — diagnosing a slow WordPress admin dashboard works through the causes in order of likelihood, and object caching sits well below autoloaded options and a jammed cron queue on that list. And if your complaint is a failing field score, diagnosing and fixing a failing WordPress INP score is the right page; INP is a main-thread problem and Redis cannot touch it.

How I would choose a backend

My criteria, stated before the table so you can disagree with them rather than with my conclusion:

For most sites the honest answer is the free Redis Object Cache plugin against a Redis instance the host already runs, or nothing at all. The paid tier is a real product solving real problems at scale; it is not where a 20,000-visit-a-month site should start.

Enable it and verify a persistent object cache is live

1. Check what you have now

# Which object cache implementation is active?
wp cache type

# Does the current implementation support flushing a single group?
wp cache supports flush_group

wp cache type reports Default on a site with no drop-in. If it already names something else, a host or a previous developer has set this up and your job is to find out what, not to install a second one.

2. Install the drop-in

# Install the plugin, then copy its object-cache.php into wp-content/
wp plugin install redis-cache --activate
wp redis enable

# Full diagnostics: client, status, prefix, hit ratio, memory
wp redis status

wp redis enable is the step that writes the drop-in. Activating the plugin alone does not start caching, which trips up plenty of people who then report no change. Run wp help redis for the rest of the subcommands on your installed version.

3. Set the constants that stop the common failures

<?php
// wp-config.php, above the "stop editing" line.

define( 'WP_REDIS_PREFIX', 'siteA_prod_' );  // Never share a prefix between sites
define( 'WP_REDIS_MAXTTL', 86400 );          // Cap how long any key can live
define( 'WP_REDIS_GRACEFUL', true );         // Serve the site if Redis is down
// define( 'WP_REDIS_DISABLED', true );      // Kill switch while debugging

WP_REDIS_PREFIX is the one you must not skip when more than one install shares a Redis database — staging and production on the same server is the usual way this bites. Without distinct prefixes, one site reads the other’s cached user and option data, and a flush on either wipes both. WP_REDIS_MAXTTL matters because WordPress sets plenty of cache entries with no expiry at all; a ceiling means a bad value eventually ages out instead of living until the next manual flush.

4. Confirm it is actually being used

# Should now report the drop-in's implementation, not "Default"
wp cache type

# Round-trip a value through the backend
wp cache set wpfairs_probe ok wpfairs 60
wp cache get wpfairs_probe wpfairs

# Flush one group rather than everything
wp cache flush-group wpfairs

If wp cache get returns your value in a second, separate CLI invocation, the cache is genuinely persistent — each WP-CLI run is its own PHP process, so a value surviving between them cannot be per-request memory. That two-command check is more trustworthy than any admin panel. Re-run Site Health afterwards and the recommendation should be gone.

Measure the gain instead of assuming it

Install Query Monitor on staging and record three numbers before you enable anything: total queries, total query time, and peak memory. Do it on the three pages that actually matter, which are almost never the homepage.

• A logged-in front-end page — an account page, a member-only post, a cart with two items in it.
• The heaviest admin list table — Orders, Posts filtered by a taxonomy, Users on a site with real user counts.
• One warm repeat of each, because the first request after enabling the cache populates it and will look no faster at all.

Then enable the drop-in, load each page twice, and compare the second load. A result worth keeping looks like a clear drop in query count and query time on the warm request. A result that is not worth keeping looks like a handful of queries saved and the same wall-clock time — which means your bottleneck was never the database, and you have just added a service to monitor for nothing.

Check hit ratio in wp redis status after a day of real traffic, not after five minutes of your own clicking. A low ratio alongside high eviction counts usually means Redis has less memory than your working set needs, and the fix is a bigger maxmemory value, not a different plugin. If the box is already short on RAM, that is a hosting conversation — WooCommerce hosting requirements: PHP workers and RAM covers how to size this honestly for a store.

What goes wrong after you enable it

Redis restarts and the site dies. The drop-in’s behaviour when the backend is unreachable decides whether this is an outage or a slowdown. Set the graceful option, then prove it by stopping Redis on staging and loading the site. Test this before you need it.

Eviction under memory pressure. A Redis instance with maxmemory-policy noeviction starts refusing writes when it fills up, and the drop-in starts throwing errors. allkeys-lru drops old keys instead, which is almost always what a WordPress object cache wants, since every entry is regenerable by definition.

Stale data that looks like a plugin bug. If a change in the admin does not appear on the front end, flush the object cache before you start bisecting plugins. Conversely, if flushing fixes it every time, you have a plugin caching something without invalidating it, and that is worth reporting upstream rather than papering over with a scheduled flush.

An orphaned drop-in. Delete the plugin without running its disable command and wp-content/object-cache.php stays behind, pointing at code that no longer exists. That is a fatal error on every request. If you are mid-incident and the site is blank, deleting that one file is the first thing to try — how to fix the WordPress white screen of death covers working through it when the dashboard is gone too.

Staging and production sharing one database. Covered above, and worth repeating because it is silent. Distinct prefixes, or distinct Redis databases, every time.

So should you add one?

• Brochure or blog site, mostly anonymous traffic, page cache in place: no. Silence the Site Health notice with the threshold filter if it bothers you, and spend the effort on images and asset delivery instead.
• Site Health flagged autoloaded options: trim the options first. If the warning was the only reason you are here, you may find you no longer need the cache.
• WooCommerce store taking real orders: yes, with managed Redis if the host offers it. Cart, checkout and My Account cannot be page-cached, and those are the pages that cost you money when they are slow.
• Membership site, forum, LMS — anything where most visitors are logged in: yes. This is the clearest case on the page, because page caching barely applies to your traffic at all.
• Multisite network: yes, and set per-site key prefixes before you go anywhere near production.
• Shared hosting with no Redis and no way to monitor one: no. A cache you cannot observe or restart is a liability, and a pure-PHP client on an overloaded box can be slower than the queries it replaces.
• You are not sure which of these you are: measure on staging with Query Monitor. Twenty minutes of before-and-after numbers settles it better than any article, including this one.

Whatever you decide, write down that the drop-in exists and which plugin owns it. The most common object-cache incident I see is not a cache failure — it is a developer two years later deleting a plugin they do not recognise and taking the site down with an orphaned object-cache.php nobody documented.

Frequently asked questions

Sources

• wp_start_object_cache() — drop-in path, loading behaviour, and the default global and non-persistent cache groups
• WP_Site_Health::should_suggest_persistent_object_cache() — the exact conditions and thresholds quoted above
• New cache Site Health checks in WordPress 6.1 — the four filters and the production-environment restriction
• wp cache — the type, supports, flush-group and get/set subcommands used here
• Transients API — where transients are stored with and without a persistent cache, and why expiry is a maximum
• Redis Object Cache and WP Redis on WordPress.org — versions, install counts, supported clients and constants
• Object Cache Pro pricing — the paid tier figures quoted in the comparison table