WordPress Object Caching With Redis: Setup and Real Impact

Object caching gets confused with page caching constantly, and the confusion causes real, avoidable problems — I’ve seen sites where someone installed a Redis object-cache plugin expecting it to behave like a full-page cache, then got confused when logged-in and dynamic pages still felt slow.

What object caching actually does, mechanically

WordPress’s default object cache is non-persistent — it exists only for the duration of a single request and then disappears. Every new page load starts from zero, re-running the same database queries a previous visitor’s request already ran. Object caching with Redis or Memcached makes that cache persistent across requests, storing the results of expensive database queries and computations in RAM so they don’t have to be recalculated every time. This is fundamentally different from full-page caching, which stores and serves an entire pre-rendered HTML page, bypassing PHP and the database almost entirely for that request. Page caching is faster for anonymous, non-personalized traffic. Object caching is what actually helps when a page can’t be fully page-cached — logged-in users, WooCommerce carts, membership content, admin screens.

The setup, practically

The dominant plugin here is Redis Object Cache by Till Krüss, with 400,000+ active installs on wordpress.org. It supports multiple PHP Redis client libraries — Predis (pure PHP, works without a server extension) and PhpRedis (a compiled PECL extension, commonly cited as several times faster due to persistent connections and compiled code, though the exact multiplier varies by benchmark and isn’t tied to one single authoritative source). It also supports replication, clustering, and Redis Sentinel setups for larger environments.

Technically, it works through a object-cache.php drop-in file — a completely separate mechanism from the WP_CACHE constant and advanced-cache.php drop-in that page-caching plugins use. You can have persistent object caching running without WP_CACHE defined at all; they’re independent systems that happen to often get installed together.

Object caching and page caching aren’t competing solutions to the same problem. They’re solving two different problems, and a site that’s slow for logged-in users specifically almost always needs the object-caching half, not just a bigger page cache.

What the actual performance data shows

Cloudways published its own Loader.io benchmark testing Object Cache Pro: average response time dropped from 1056ms to 522ms, roughly a 50% reduction, with success rate improving from 99% to 100% under load. That’s a real, named test, though it’s vendor-published, so treat it as directionally credible rather than an independent audit. Kinsta’s own documentation confirms it offers a dedicated Redis add-on, colocated for low latency, without publishing specific percentage figures on its own pages.

I want to flag one number directly: a specific statistic circulating online — a UK e-commerce client seeing an 800ms-to-45ms TTFB drop and a 22% conversion increase — traces back to a third-party agency blog, not to Kinsta or any primary source I could verify. Don’t repeat that one as fact. What’s more broadly consistent across hosting-industry sources, without tracing to one single rigorous benchmark, is that a typical uncached WordPress request runs somewhere between 40 and 80 database queries, dropping to near-zero on a cache hit — treat that as industry consensus rather than a hard, citable statistic.

The pitfalls nobody mentions until you hit them

• Cache stampede after a restart. When Redis restarts, the cache is empty, and a sudden wave of simultaneous requests can all hit the database at once trying to rebuild it. TTL jitter and rebuilding caches one at a time rather than all at once both help.
• The default eviction policy can silently break caching. Redis defaults to noeviction — once memory is full, it simply refuses new writes rather than clearing old ones, which quietly stops your caching from working at all. allkeys-lru is the commonly recommended setting instead; watch your evicted_keys and memory usage metrics to catch this early.
• Multisite needs a unique cache key salt per site. Without it, sites sharing one Redis instance can end up reading each other’s cached data.
• Direct database changes bypass the cache entirely. A migration or manual SQL query run outside WordPress won’t trigger a cache flush, and you’ll see stale data until you clear it manually.

When it’s not worth the complexity

If your site already leans heavily on a full-page cache or CDN edge caching for the bulk of its traffic — mostly anonymous visitors reading content that doesn’t change per-user — object caching’s marginal benefit shrinks. It earns its keep specifically on dynamic, personalized, logged-in-heavy workloads: WooCommerce, membership sites, anything with a cart or an account dashboard doing real work on every load. Know which category your site actually falls into before adding the operational complexity of running and monitoring a Redis instance.