Object Cache on WordPress: Why Redis/Memcached Triple Your Site Speed

Object cache stores DB queries in memory across requests. On WooCommerce this is a 5x throughput improvement at peak traffic.

WordPress ships with a built-in WP_Object_Cache - but it is non-persistent: it lives only inside the current PHP request and dies when the response ships. Without a drop-in plugin that wires it to Redis or Memcached, every request repeats the same DB queries that the previous request answered 200ms earlier. Massive waste of time and server resources.

Why this matters

A typical WordPress page issues 50-150 DB queries. Many repeat: wp_options, taxonomy lookups, user meta. With Redis Object Cache the first query hits MySQL, the result lives in Redis (extremely fast in-memory store), and subsequent requests pull from Redis at 1-3ms instead of 20-100ms from MySQL.

On a 200-product WooCommerce store, queries that take 800ms uncached drop to 150ms cached. At peak traffic (Black Friday, viral deal), an uncached server collapses around 50 req/s; with Redis it sails past 200 req/s. Core Web Vitals: TTFB drops 100-400ms, LCP and INP follow.

Important: object cache is not page cache. Page cache (WP Rocket, LiteSpeed Cache) stores rendered HTML for anonymous visitors. Object cache stores granular pieces inside WordPress - benefiting logged-in users, admin, AJAX, and REST. The two are complementary, not alternatives.

How to detect

Tools > Site Health. Under "Persistent object cache", "Should be present" means it is missing; "Site is using a persistent object cache" means it is active.

Manual check in PHP:

echo wp_cache_get('test', 'group') === false ? 'No cache' : 'Cache active';

Via WP-CLI:

wp cli info | grep -i cache

If Redis is present:

redis-cli ping  # should return PONG

How to fix

Step 1: confirm the host has Redis or Memcached available. Managed hosts (Kinsta, Cloudways, SiteGround GoGeek+, Hostinger Premium+) include it. Cheap shared hosting usually does not. Ask support if uncertain.

Step 2: install Till Krüss's free "Redis Object Cache" plugin (clean, popular, well maintained). For Memcached use "W3 Total Cache" (object cache is built in).

Step 3: connection settings. In wp-config.php:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_PASSWORD', 'YOUR_PASSWORD'); // if set
define('WP_REDIS_DATABASE', 0);
define('WP_CACHE_KEY_SALT', 'YOUR_SITE_DOMAIN_'); // prevents cross-site collisions

Step 4: in the plugin page click "Enable Object Cache" and confirm status "Connected".

Step 5: browse the site - admin in particular should feel snappier. Site Health's "Persistent object cache" should now be green.

Common mistakes

Mistake one: enabling Redis without setting WP_CACHE_KEY_SALT. Multiple sites sharing one Redis instance share cache keys and receive each other's data. Use the domain as a prefix. Mistake two: trusting the cache 100%. Some bugs live mid-cache (a query that never lands in cache, or a stale entry). Always write code that still works without cache. Mistake three: forgetting to flush after a plugin or theme deploy - wp cache flush or the plugin's button.

Verifying the fix

PageSpeed Insights TTFB should drop 100-400ms. Query Monitor on a cache-hit page shows the total query count collapse from ~150 to 30-50. From Redis CLI: redis-cli info stats | grep keyspace_hits - the number should grow. If hits = 0 the cache is not actually serving.

wp-admin should also feel faster. Navigating Dashboard > Posts > Settings should feel instant rather than waiting half a second per click.

Tip: On shared hosting without Redis but with APCu (part of PHP), use APCu as a local object cache. Less efficient than Redis (per-process, not shared) but still 30-50% faster than no cache. Object Cache Pro supports APCu too.