Object Caching in WordPress: What It Fixes and What It Doesn't

Someone tells you to install Redis. You do. The homepage is exactly as fast as before, and you conclude caching is snake oil.

It isn't — you just cached the wrong layer for the page you were testing.

Two caches doing two different jobs

They stack. Page caching handles the easy majority of traffic; object caching handles what page caching has to skip.

What object caching actually stores

Every WordPress page view runs dozens to hundreds of database queries — options, menus, user meta, term relationships, product attributes. Many are identical on every request.

Without a persistent object cache, WordPress remembers those results only for the duration of a single page load and throws them away. Next visitor, same questions, same work. Object caching keeps the answers in memory between requests, so the database is asked once rather than every time.

The effect shows up in server response time — TTFB — rather than in what the browser is doing. Which is precisely why testing it on a cached homepage shows nothing.

Which sites benefit — and which won't

• WooCommerce stores. Cart, checkout and account pages can't be page-cached because they're different for everyone. Object caching is the only cache those pages get.
• Membership sites and LMS platforms. Almost every meaningful page is logged-in. If you're running team accounts and progress tracking, permission checks alone generate a lot of repeat queries.
• Large catalogues and content libraries. Heavy taxonomy and meta queries are exactly what object caching is for.
• Sites with many admin users. The WordPress dashboard is uncached by nature and gets noticeably quicker.
• A brochure site with twelve pages. Little to gain. Page caching already serves everything. That's a fine outcome, not a failure.

Persistent versus non-persistent

WordPress has a built-in object cache that lasts exactly one page load. Useful, but it starts from zero every request.

A persistent object cache — Redis or Memcached with a drop-in plugin — survives between requests. That's the version worth installing. If you've "enabled object caching" but no Redis or Memcached service is running, you have the built-in one, which was already there.

Worth checking before buying anything: many managed hosts include Redis, and a fair number of sites are paying for a plugin to enable something their host already provides.

Common disappointments, explained

• "I installed Redis and nothing changed." You probably tested a page-cached page as a logged-out visitor. Test a cart, an account page or the dashboard.
• "It made the site unstable." Usually a plugin caching something it shouldn't, or memory limits set too low so the cache evicts constantly. Worth investigating rather than abandoning.
• "Stale data keeps appearing." Something isn't invalidating its cache on update. Real, fixable, and a reason to have someone who knows the stack configure it.

Object caching is plumbing. When it's right, nobody notices — which is a hard thing to sell and an easy thing to get wrong.

Our Speed & Performance service configures caching layers properly — including checking whether your host already gives you what you're about to buy. From $650.