Most WordPress sites hit the database dozens of times per page load. Every menu, every widget, every post query — they all fire separate requests. For a low-traffic blog, that’s fine. For a content business serving thousands of readers a day, it becomes a bottleneck.
Object caching stores the results of those database queries in memory so WordPress can reuse them instead of re-running the same query ten times per page. It’s not page caching (which saves entire HTML pages). It’s not browser caching (which stores assets locally). It’s an in-between layer that speeds up the dynamic parts of your site — the bits that change based on who’s logged in, what’s in the cart, or which posts are being displayed.
If you’re running a membership site, a high-traffic blog, or a WooCommerce store, object caching can cut server load by 40–60%. But it adds complexity, and it doesn’t help every site equally.
How object caching works in WordPress
WordPress has a built-in object cache — but by default, it only lasts for a single page load. Every time someone visits a page, the cache resets.
Persistent object caching extends that lifespan. Instead of storing query results in PHP memory (which disappears after each request), it stores them in Redis or Memcached — key-value stores that sit in RAM and persist across requests.
When a query runs, WordPress checks the object cache first. If the result is there, it skips the database entirely. If not, it runs the query, stores the result, and serves it from cache next time.
Common queries that benefit: navigation menus, widget output, post metadata, taxonomy terms, user data, WooCommerce product attributes. Anything that gets called repeatedly and doesn’t change on every page load.
When to turn it on
Not every site needs object caching. A static blog with 500 visitors a month won’t see a meaningful difference. But you’ll notice a real impact if:
- You’re serving more than 10,000 page views per month
- Your site uses complex queries (custom post types, taxonomies, meta queries)
- You’re running WooCommerce, BuddyPress, or another plugin-heavy setup
- Your database queries are taking longer than 50ms (check this in Query Monitor)
- You’re hitting CPU or memory limits during traffic spikes
The easiest way to tell: install Query Monitor, load a few pages, and look at the query count and total query time. If you’re running 100+ queries per page or spending more than 200ms on database calls, object caching will help.
Most managed WordPress hosts (Kinsta, WP Engine, Cloudways) offer Redis as a one-click add-on. If you’re on a VPS with BigScoots or similar, you’ll need to install Redis yourself (or ask support to do it) and add a plugin like Redis Object Cache or Object Cache Pro.
The non-obvious gotcha
Object caching breaks badly written plugins.
If a plugin assumes every query hits the database — or if it doesn’t properly invalidate (clear) cached data when something changes — you’ll see stale content. A post updates, but the old version keeps showing. A product goes out of stock, but the cache still says it’s available.
Good plugins handle this automatically by calling wp_cache_delete() or wp_cache_flush() when data changes. Bad plugins don’t.
Before you enable object caching site-wide, test it on a staging environment. Update a post, change a menu, edit a product. If those changes appear immediately on the front end, you’re fine. If they don’t, you’ve got a plugin conflict.
One more thing: object caching doesn’t replace page caching. It speeds up dynamic queries, but you still want a layer (like WP Rocket, Cloudflare, or your host’s built-in cache) saving full HTML pages for logged-out users. The two work together — page caching handles static content, object caching handles the bits that can’t be fully static.
What to do next
If you’re not sure whether your site needs object caching, start here: install Query Monitor (it’s free), load your most-trafficked pages, and check the database panel. If you’re seeing 80+ queries or 150ms+ query time, object caching will make a measurable difference.
If you’re already on a managed host, check whether Redis is included or available as an add-on. If you’re on a VPS, ask your host whether they support Redis, or spin up a staging site and test it yourself.
And if you do turn it on: keep Query Monitor installed for a week and watch for stale content. Most modern plugins handle caching well, but the ones that don’t will show themselves quickly.
Got a question about WordPress performance, caching, or infrastructure? Hit reply — this is the sort of thing we dig into every week.