Page caching gets all the attention, but it does nothing for uncached visits, logged-in users, or the admin panel. Object caching does — it stores database query results in memory so repeated queries stop hitting MySQL. On our B2B demo, enabling Redis cut uncached product-page generation from 480ms to 190ms of server time. Here is how to set it up and — more importantly — how to verify it is actually working.
Which plugin
| Plugin | Scope | Notes |
|---|---|---|
| Redis Object Cache ( Till Krüss ) | Redis/Memcached, drop-in | The standard; minimal, reliable |
| LiteSpeed Cache object cache | Redis/Memcached, built in | Use if already running LiteSpeed Cache |
| W3 Total Cache | Multiple backends | Works; more config surface than value |
We use the Redis Object Cache plugin — one drop-in file, an activate button, done. If your stack already runs LiteSpeed Cache, use its built-in object cache instead; do not run both.
Setup in five steps
- Confirm Redis exists on your server:
redis-cli ping→PONG. On shared hosting without Redis, this step ends the project — ask your host. - Install the plugin, then
wp redis enable --allow-root(or click Enable). It writesobject-cache.phpinto wp-content — the drop-in mechanism. - If Redis runs on a socket or non-default port, set
WP_REDIS_HOST/WP_REDIS_PORTin wp-config before enabling. - Verify:
wp redis status --allow-rootmust say “Connected”. Thenredis-cli info stats | grep keys— keyspace should grow as pages load. - Watch hit ratio after a day:
redis-cli info stats | grep keyspace_hits— divide by total. Above 80% is healthy; below means cache flushing constantly (usually plugin conflicts).
The failure modes
- Drop-in present but Redis down — every request tries Redis, fails, falls back to DB. Status shows “Not connected” only if you look. Check weekly or alert on it.
- Evictions eating your cache —
redis-cli info memory | grep evicted: non-zero evictions mean maxmemory is too small; raise it. - Persistent-object-cache plugins stacking — two drop-ins = one wins silently. The conflict diagnostic applies: one object-cache layer only.
- Multisite/network cache collisions — set a unique
WP_CACHE_KEY_SALTper site when sharing one Redis instance.
What it will and will not fix
Object caching helps uncached page generation, admin screens, WooCommerce lookups, and logged-in traffic. It does nothing for front-end weight — scripts, CSS, images — which is the domain of script management and theme diet. Both layers together are what actually moves the Core Web Vitals needle for logged-in-heavy B2B sites.
Yes for server-side work: our uncached product pages dropped from 480ms to 190ms generation time, and admin screens got noticeably snappier. It does not reduce front-end page weight. Both work through the same plugin. Redis's persistence and richer data types make it the usual choice today; Memcached suits simple, multi-server setups. Run wp redis status (must show Connected), then redis-cli info stats — keys should grow as traffic arrives and the hit ratio should exceed 80% after a day. Usually maxmemory evictions or a plugin flushing the cache constantly. Check evicted_keys in redis-cli info memory and raise maxmemory before blaming WordPress.Does Redis object caching speed up WordPress?
Redis vs Memcached for WordPress?
How do I check if object caching is working?
Why is my Redis hit ratio low?
