Redis Object Cache for WordPress: The Complete Guide

by Francis Rozange | Oct 2, 2026 | Performance

A glass memory cube full of light particles crossed by fast streams

On every visit, WordPress queries its database, stores the results in an in-memory cache, then forgets everything at the end of the request. The next visit starts the same work again. That is the default behavior, and it is why Site Health recommends a persistent object cache on many sites.

Redis has become the most common answer to that recommendation. Configured well, it spares WordPress thousands of repeated queries on a store, a membership site or a forum. Configured badly, it fills the server’s memory, serves stale data, or takes several sites down at once.

This guide explains what the WordPress object cache is, what its persistent version changes, how to read the Site Health recommendation, how to choose between Redis, Memcached and other options, which plugins to use, how to configure the whole thing, and when none of it helps.

What the WordPress object cache is

The wp_cache functions and groups

Since version 2.0, WordPress has had an object cache interface: functions such as wp_cache_get(), wp_cache_set() or wp_cache_delete() store data under a key, in a group. Core uses it for options, posts, terms, users, and since WordPress 6.1 for content query results.

A plugin can use it the same way. The documentation recommends going through these functions, never directly through the class behind them.

$found = false;
$data  = wp_cache_get( 'top_products', 'my-plugin', false, $found );
if ( ! $found ) {
	$data = my_plugin_expensive_query();
	wp_cache_set( 'top_products', $data, 'my-plugin', HOUR_IN_SECONDS );
}

The $found parameter tells a cached false value apart from a missing one.

Why the default cache dies with the request

Without any special setup, this cache is not persistent: data lives in memory, in a plain PHP array, for the length of one request. The expiration passed to wp_cache_set() is not even used. The cache therefore avoids repeating a query within the same page load, but the next page starts from scratch.

What WordPress already caches

Autoloaded options are grouped under a single key, read on every request. Posts, terms and their metadata also go through the cache. Since WordPress 6.1, content query results are cached as well, an improvement announced at the time as a major one for the database, especially with a persistent cache in place.

Autoloaded options

These options, grouped under a single key, are read on every request: with a persistent cache, that whole block therefore travels through the cache server each time, hence the value of keeping it light. Since WordPress 6.6, an option larger than 150,000 bytes is no longer autoloaded by default. On Memcached, the one-megabyte limit per item applies to that block of options, which explains errors on some sites loaded with plugin settings.

What a persistent object cache changes

The object-cache.php file

A persistent cache is not turned on with a setting. It relies on a file, wp-content/object-cache.php, installed by a plugin. If that file exists, WordPress loads it automatically at startup and hands it every cache operation, which then goes to a cache server such as Redis or Memcached. The plugins screen lists it as an external object cache.

Do not confuse it with advanced-cache.php, which serves the page cache and only loads when the WP_CACHE constant is on. Two files, two different caches.

Transients leave the database

With a persistent cache, transients, the temporary data plugins store with an expiration date, are no longer saved in the options table but in the cache. The documentation also warns that a transient should never be assumed to be in the database, and that it may disappear before it expires.

Object cache and page cache

The page cache stores the full HTML page and serves it without running WordPress. The object cache comes into play when WordPress actually runs: logged-in visitors, the admin area, cart, checkout, customer account, search, API calls. An anonymous visitor served by the page cache never touches the object cache. Our selection of WordPress speed plugins covers the page cache side.

The Site Health recommendation, decoded

Since WordPress 6.1, Site Health can recommend a persistent object cache. It is not a critical alert but a recommendation, and it only appears on a production environment, the type WordPress assumes by default when no other is declared.

The test measures no performance: it compares data volume against thresholds. It always triggers on Multisite, and otherwise as soon as the site has more than 500 autoloaded options, more than 100,000 bytes of those options, or at least 1,000 rows in the comments, options, posts, terms or users tables. A filter lets hosts and developers adjust those thresholds.

The recommendation text points you to your host to find out whether a persistent cache can be enabled, and lists the cache extensions WordPress detects on the server. The official documentation sums up the benefit this way: fewer round trips to the database, so pages are generated faster.

Redis, Memcached and the others

Redis

Redis is an in-memory data server. For WordPress, it brings numbered databases, sixteen by default, which let you isolate each site, and a scripting language that lets plugins flush a single cache group. Its license has been debated: moved to restrictive licenses in March 2024, it gave rise to the open source fork Valkey, then Redis 8 added an open source AGPL license in May 2025.

By default, Redis is not configured as a cache: no memory limit on a 64-bit system, and a policy that refuses writes rather than evicting data when memory is full. It has to be tuned, as we will see.

Memcached

Memcached is simpler: a multithreaded in-memory cache, without replication or numbered databases, with a historic one-megabyte limit per item. It is very much alive at large hosts: WordPress VIP gives each environment its own Memcached cluster. Without numbered databases, flushing one site’s cache risks flushing every site on the server, which good cache files work around.

Without a cache server

On shared hosting without Redis or Memcached, options exist. APCu keeps data in PHP’s memory, but only on one server, and the command line, where it is disabled by default, does not share that memory. SQLite Object Cache relies on an SQLite file and does not work correctly with several web servers. Docket Cache stores the cache as PHP files, while acknowledging itself that Redis or Memcached remain the best choices.

How to choose

If your host offers Redis, choose Redis: it is the option best supported by WordPress plugins, and its separate databases make it simple to isolate several sites. If your host provides and manages Memcached, use the cache file it recommends. Without a cache server, APCu or SQLite can help a site hosted on a single server, as long as you accept their limits. In every case, ask the host who monitors the service and what happens if it stops.

Relay

Relay, developed largely by Till Krüss, the author of Object Cache Pro, is a PHP extension that replaces the Redis client and keeps a partial copy of the data in PHP’s shared memory. Its free version is limited to 64 MB. The gains claimed by the vendor remain its own figures.

The plugins compared

Redis Object Cache

The reference free plugin, maintained by Till Krüss, has more than 500,000 installs and reached version 3.0 in September 2026. It supports several PHP clients, replication and clusters, offers WP-CLI commands and shows the cache hit ratio in the admin bar. Kinsta installs it with its Redis option.

Object Cache Pro

Its rewritten commercial version costs $95 per month or $950 per year at the time of writing, without the Redis server. It adds compression, prefetching, analytics and fine-grained flushing options. It stops working fourteen days after the license expires. Several hosts, such as Pantheon and Cloudways, include it in their plans.

LiteSpeed Cache and W3 Total Cache

LiteSpeed Cache, installed on more than seven million sites, contains an object cache module that is off by default and connects to Memcached, its LiteSpeed equivalent or Redis. W3 Total Cache also offers an object module, with a long list of methods, some of which rely on abandoned PHP extensions. These are convenient options if you already use those plugins for page caching.

The others

WP Redis, Pantheon’s historic plugin, is no longer the method its own vendor recommends. The Memcached Object Cache listing in the official directory has not been updated since 2022, even though its code is still maintained elsewhere. To compare these offerings with hosts’ own, our selection of WordPress hosting providers counts caching among its selection criteria.

A glass container overflowing with dim particles while new ones keep arriving

Configuring it properly

On the Redis side

The Redis documentation recommends, for cache use, setting a memory limit and an eviction policy. The allkeys-lru policy, which evicts the least recently used keys, is presented as a good default choice.

maxmemory 256mb
maxmemory-policy allkeys-lru

The memory value depends on your site: it is an example. Redis should also listen only locally or on a private network, and require a password whenever it is not strictly local.

On the WordPress side

With Redis Object Cache, settings go in wp-config.php, before the line telling you to stop editing. Each site must have its own Redis database and a readable prefix.

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 3 );     // one database per site
define( 'WP_REDIS_PREFIX', 'shop:' ); // readable, unique per site

Then enable the cache from the plugin screen or with wp redis enable, and flush it once. If something goes wrong, deleting the object-cache.php file or defining WP_REDIS_DISABLED turns everything off immediately.

The real case: when query caches piled up in Redis

The story of WordPress query caches, from 2022 to 2025, shows what happens when a persistent cache has neither a memory limit nor an eviction policy. It is fully documented in core developer notes, public commits and the Object Cache Pro changelog.

A promise in 2022

In September 2022, ahead of WordPress 6.1, Jonny Harris, a performance team contributor, announced a massive improvement to database performance: content query results would now be cached. With a persistent cache, the same query would no longer run until the cache was invalidated.

In the comments on the developer note, Till Krüss, author of Redis Object Cache, expected slightly more load on Redis, negligible in his view compared with waiting on MySQL. WordPress 6.1 shipped on November 1, 2022.

A key that changes on every edit

The invalidation mechanism is simple: each cached query’s key contains the date of the last content change. As soon as a post is saved, that date changes, and every query already in cache becomes unreachable, without being deleted. They stay in Redis until they expire or are evicted.

Yet WordPress sets no expiration by default, and Redis, by default, has neither a memory limit nor an eviction policy. On a site that publishes or updates often, orphaned entries pile up.

Isolate, then fix

A first fix, included in WordPress 6.3 in August 2023, moves these results into dedicated groups, named for example post-queries. Developers can then give them an expiration or keep them out of the persistent cache. In March 2025, Till Krüss proposed on GitHub to unify the format of these keys, which he called un-parseable: two timestamps were joined with no consistent rule.

In June 2025, Object Cache Pro added a default 24-hour lifetime for those groups, and a command to prune old queries. The underlying fix reached core on August 31, 2025: the date is no longer in the key but in the value, which is updated in place. The commit says it plainly: the old approach relied on the cache server evicting stale keys, with varying efficiency.

WordPress 6.9 and after

WordPress 6.9, released on December 2, 2025, brings new cache functions, including wp_cache_get_salted(), without plugins’ cache files needing changes. The developer note warns of a temporary rise in cache misses after the update, and suggests evicting the old keys so they do not trigger needless evictions.

What to take away

A persistent cache is only as healthy as its memory policy: set a limit and an eviction policy, because Redis defaults assume a database, not a cache. Invalidating by changing the key is cheap for the application and expensive for the cache server. Watch used memory and evicted keys, not just the hit ratio. The sources consulted do not publish the memory actually consumed on affected sites: remember the mechanism, not a number.

The pitfalls

Memory and eviction

When a memory limit is set but the default policy is kept, a full Redis refuses new writes, and the plugin shows out-of-memory errors. Redis Object Cache offers a maximum lifetime, WP_REDIS_MAXTTL, to get out of it, but the real fix remains a memory limit and an eviction policy on the server side.

A shared Redis

A prefix prevents key collisions between sites, not flushes: flushing a Redis database wipes everything in it. Cloudways found this out in 2023: its applications shared the same Redis database, and flushing one application’s cache flushed all the others on the server. The host gave each application its own database. Object Cache Pro’s documentation strongly discourages sharing one database between several sites.

Flushing

Flush the cache once after activation, and after an update that changes cache keys, such as the move to WordPress 6.9. On Multisite, a flush can affect all sites or only one depending on the plugin and command. Check what your tool does before flushing in production.

After a deployment or a copy

A code deployment does not flush the object cache: WordPress VIP says so in its documentation. After shipping a change that alters the structure of cached data, flush it explicitly. Likewise, copying a site to a test or production environment should come with a flush, and the test environment must never share the production Redis database.

When Redis goes down

The behavior depends on the plugin. Redis Object Cache stops the site with an error, by design: for Till Krüss, the object cache must be available at all times, like the database. In June 2025, an administrator saw about fifteen sites go down this way after a server update broke Redis, while his LiteSpeed sites kept running. A silent fallback to the database, on the other hand, risks stale data when Redis comes back. Monitor Redis like your database.

Stale data

A plugin that writes directly in SQL, bypassing WordPress functions, leaves the cache showing old values. The documentation recommends calling clean_post_cache() for the affected post after a direct write. It is often the cause of a “bug” that disappears when the cache is flushed.

Security

Redis is designed to be used by trusted clients in a trusted environment. A single command is enough for an attacker to wipe all the data in an exposed Redis. In October 2025, CVE-2025-49844, scored 10 out of 10, forced Redis updates: it is fixed in versions 8.2.2, 8.0.4, 7.4.6 and 7.2.11, and can only be exploited by an authenticated client. Keep Redis off the internet, password-protected and up to date.

Measuring the gain

Measure on the pages the page cache does not serve: admin, customer account, cart, search. On the same address, compare before and after with Query Monitor, which shows the number of queries, their duration and the cache hit ratio, and with Redis statistics. The commands in our selection of essential WP-CLI commands, such as wp cache type, help check which cache is actually in use.

On the server side, the redis-cli info stats command gives the number of cache hits and misses, from which you get the hit ratio, along with the number of evicted and expired keys. A steadily climbing count of evicted keys signals memory that is too tight; a low hit ratio, a cache that is poorly used or flushed too often.

Measure under load as well. In a guide updated in December 2024, the host Wetopi measured on a sample page a drop in queries from 132 to 31, with a 99.3% hit ratio, but generation time barely improved, from 0.29 to 0.27 seconds. Its conclusion: in this case, the object cache only really helps when many users hit the site at the same time, by taking load off the database.

When an object cache does not help

Kinsta puts it clearly: Redis generally does not help the load time of static blogs, brochure sites and news sites, which are almost entirely served by the page cache. It can help stores, membership sites, forums and sites with very active comments.

An object cache can even slow a site down if plugins make too many calls: the WP Redis plugin warns that a page triggering 2,000 Redis calls can lose two seconds in cache transactions. If the site is slower with the cache, something is broken: the connection, latency or Redis server resources. A poorly maintained database also remains a problem that the cache only hides.

Summary table

Solution	What you need	Best for	Main limit
Redis Object Cache	A Redis server	Most dynamic sites	Site stops if Redis goes down
Object Cache Pro	Redis and a license	Stores and high-traffic sites	$95 per month, Redis not included
LiteSpeed Cache	Memcached, LSMCD or Redis	Sites already on LiteSpeed	Module off by default
Memcached	A Memcached server	Large platforms	No separate databases
APCu, SQLite, files	PHP extensions or disk	Shared hosting, single server	Not shared across servers

Frequently asked questions

Do I need Redis if I already have a page cache?

For a brochure site or a blog, rarely. The page cache serves most visitors. For a store, a membership site or any site with many logged-in visitors, yes, because those pages bypass the page cache.

Redis or Memcached for WordPress?

Redis, in most cases: its separate databases and scripts make it easier to isolate sites and flush selectively, and the most widely used WordPress plugins target it. Memcached remains a good choice when the host provides and manages it.

Is Object Cache Pro worth $95 a month?

For a store or a high-traffic platform, its analytics, compression and flushing options can justify it. For most sites, the free plugin is enough.

Is an object cache safe on shared hosting?

Only if each account has its own Redis instance, protected by a password: a numbered database separates keys, not access, and an instance’s password is shared by all its clients. Autoloaded options, API keys included, are copied into the cache.

What happens if Redis crashes?

With Redis Object Cache, the site stops with an error until Redis comes back. The WP_REDIS_DISABLED constant or deleting the object-cache.php file brings it back online without the cache.

Conclusion

A persistent object cache saves time where WordPress really works: admin, store, accounts, search. It replaces neither the page cache, nor a healthy database, nor decent hosting.

Before turning it on, set three things: one Redis database per site, a memory limit with an eviction policy, and monitoring for Redis on par with the database. Then measure on the pages concerned. The story of WordPress query caches is a reminder: a poorly maintained cache does not break anything right away; it piles up.

Sources

LaFactory designs, builds and maintains WordPress and WooCommerce sites, and develops its own plugins. Talk to us about your WordPress project.

Francis Rozange

Former section editor at Libération, he runs LaFactory, an international web agency since 1996.