Implementing Redis Object Caching on WordPress

Why object caching matters even with page caching already on

Page caching serves an entire rendered HTML page to anonymous visitors, which is why it delivers such a large speed win for most WordPress sites. It does nothing for logged-in users, admin-area requests, or any dynamic content page caching deliberately excludes, because those requests still have to execute PHP and hit the database every single time. Redis object caching WordPress installs address exactly this gap: WordPress’s internal object cache API, which normally only persists for the length of a single page request, gets backed by Redis instead, so the same database query result can be reused across many separate requests rather than re-run from scratch on each one.

Setting up Redis object caching on WordPress

The standard path is installing a persistent object cache drop-in, most commonly the Redis Object Cache plugin, which places a `object-cache.php` file directly in `wp-content` rather than loading as a normal plugin — this is what allows it to intercept WordPress’s object cache calls before most other plugins run. Redis itself needs to be running as a separate service, either on the same server or a dedicated cache instance, with the plugin configured to point at its host and port. Once active, a quick check of the WordPress admin bar or a dedicated diagnostics page confirms the connection is live and cache hits are actually being served from Redis rather than silently falling back to WordPress’s default non-persistent cache.

Choosing TTLs by how often data actually changes

Not all cached data deserves the same expiration window. Static or rarely changing data — site options, menu structures, taxonomy term lists — can carry a long TTL safely, since the underlying data changes infrequently enough that staleness is not a real risk. Fast-changing data, such as WooCommerce stock counts or comment counts on an active post, needs a shorter TTL that roughly matches how quickly the underlying database actually changes, because setting a long TTL on volatile data is how a Redis object caching WordPress setup starts serving visibly wrong information to users without anyone noticing until a complaint arrives days later.

The cache stampede problem and how to avoid it

A cache stampede happens when a large number of cached keys expire at the same moment, sending every one of those requests to the database simultaneously instead of the trickle a well-staggered cache produces. This is a particular risk on a Redis object caching WordPress setup where many keys were all written at roughly the same time, for example right after a cache flush or a deployment. The standard mitigation is adding random jitter to TTLs — a base 300-second expiration randomized to somewhere between 300 and 360 seconds — so expirations spread out over time instead of all landing in the same instant and hammering the database at once with a burst of identical queries.

Write-through invalidation versus letting TTL expire naturally

Two invalidation strategies cover most Redis object caching WordPress needs. Cache-aside, where a key simply expires via TTL and the next request repopulates it from the database, is the default and works well for most content. Write-through invalidation, where an explicit cache-clear call fires the moment underlying data changes — a post is updated, an order status changes — is worth adding specifically for data where even a brief staleness window is unacceptable, such as inventory counts during a flash sale. Relying on TTL alone for that kind of data trades a small performance gain for a correctness risk that is rarely worth taking on a store with real inventory constraints.

Multisite and shared-hosting caveats

A WordPress Multisite network adds one more wrinkle to a Redis object caching WordPress rollout: cache keys need to be correctly namespaced per site within the network, or one subsite’s cached data can leak into another’s, producing confusing bugs that look like a plugin conflict but are actually a cache-key collision. On shared hosting, Redis is frequently unavailable at all, or metered tightly enough that a busy site can exhaust its allotted memory quickly, which is worth checking with the host before planning an object-cache-dependent architecture around a shared environment that was never provisioned for it.

What to monitor once it is running

After deployment, the two numbers worth watching are cache hit ratio and Redis memory usage. A hit ratio that stays low despite Redis being correctly connected usually means TTLs are too short or a plugin is bypassing the object cache entirely for certain query types. Memory usage climbing steadily without leveling off typically means keys are not expiring as expected, which is worth investigating before Redis runs out of memory and starts evicting cached data under pressure, silently undoing the entire performance benefit the setup was built to deliver in the first place.