How to Set Up Object Caching in WordPress for Faster Performance

If your WordPress site still feels sluggish after you’ve set up a caching plugin, minified your scripts, and added a CDN, the bottleneck might be happening lower down — at the database. Every time WordPress needs a list of posts, a menu, or a set of options, it normally has to query the database again. Object caching stores the results of those queries in memory so WordPress can skip the database entirely for repeat requests.

In most sites I build that get real traffic, page caching alone eventually stops being enough — dynamic pages, logged-in users, and WooCommerce carts can’t be served from a static cache. Object caching is what picks up the slack. Here’s how to set it up properly, how WordPress itself now flags whether you’re missing it, and how to tell if your host even supports it.

Quick Answer

Object caching in WordPress means installing a persistent cache backend — usually Redis or Memcached — on your server, then activating a plugin that connects WordPress to it. Once connected, WordPress stores database query results in memory instead of re-querying MySQL on every page load. Most managed WordPress hosts (Kinsta, WP Engine, Cloudways) have Redis available as a one-click toggle; on shared hosting you’ll usually need to check with support first. WordPress’s own Site Health tool (Tools → Site Health) will tell you directly whether a persistent object cache is currently active — it’s been a built-in check since the Performance Lab work merged into core.

Why This Matters

Page caching plugins store a finished HTML copy of a page and serve that to visitors. That works well for a logged-out visitor reading a blog post, but it does nothing for logged-in users, cart pages, search results, or any page WordPress has to build fresh each time. Object caching works underneath that layer — it doesn’t care whether the page itself is cacheable, only whether the same database query has run before.

This matters most for server response time. If you’ve already worked through reducing TTFB in WordPress and you’re still seeing slow first-byte times on dynamic pages, uncached database queries are usually the reason. Object caching also reduces load on the database server itself, which matters if you’re running WooCommerce or a membership site with a lot of logged-in traffic hitting uncacheable pages simultaneously — and this got a direct, current boost: WooCommerce 11.0 (released June 2026) turned on product object caching by default for new installations, meaning a persistent backend now pays off on more of the store’s own queries automatically than it did a year earlier, with no extra configuration on the WooCommerce side.

It’s also worth understanding the difference between object caching and the transients API, since both store data in a similar way. Transients guarantee that a value persists across page loads even without a persistent backend — WordPress falls back to storing them in the database if no object cache is active. Regular object cache values, by contrast, are non-persistent by default and simply vanish at the end of each request unless a plugin like Redis Object Cache is running to keep them in memory between requests. That distinction is why installing a persistent object cache plugin changes so much: it turns every transient and cached query across the entire site into something that survives between visitors, rather than just within a single page load.

Step-by-Step Instructions

Step 1: Check What Your Host Supports (and What Site Health Already Told You)

Before installing anything, check Tools → Site Health → Status in your own dashboard — if a persistent object cache isn’t active, WordPress core itself will flag it as a recommended improvement, which is a faster starting point than guessing. Then confirm your hosting environment actually has a persistent object cache backend available: log into your hosting control panel or check your host’s documentation for Redis or Memcached. Managed WordPress hosts typically expose this as a toggle in the dashboard. On shared or reseller hosting, it’s often unavailable — contact support and ask directly rather than guessing, since installing a plugin without a backend running behind it does nothing (and Site Health will simply keep flagging the same gap).

If your host confirms Redis is available but doesn’t manage it for you, you’ll usually need the connection host, port, and any password from your hosting dashboard before moving to the next step. Keep these details handy — you’ll enter them into the plugin once it’s installed.

Step 2: Install a Persistent Object Cache Plugin

Once you’ve confirmed Redis or Memcached is running on the server, install a matching plugin — Redis Object Cache is the dominant free option for Redis backends, with 400,000+ active installs as of mid-2026, built by Till Krüss and supporting Predis, PhpRedis, Relay, replication, sentinels, and clustering. From your WordPress dashboard, go to Plugins → Add New, search for it, and install and activate it as you would any plugin.

Step 3: Connect and Enable the Cache

After activation, go to Settings → Redis (the exact menu location depends on the plugin) and click Enable Object Cache. This copies the plugin’s drop-in file into your wp-content directory as object-cache.php, which is what actually intercepts WordPress’s caching calls. If the plugin reports a connection error at this stage, double check the host, port, and any authentication details your host gave you — these are usually pre-filled correctly on managed hosting but may need entering manually elsewhere.

Step 4: Verify It’s Actually Working

Most object cache plugins show a status panel with hit/miss ratios and cache size once enabled — check this after browsing your own site for a few minutes so real queries populate it. A healthy setup shows a hit ratio climbing well above 80% during normal traffic. If it stays at zero, the drop-in isn’t connecting, and you’re back to querying the database on every request as before. Re-checking Site Health at this point should also flip its persistent-object-cache status to green, which is a useful independent confirmation beyond the plugin’s own dashboard.

Step 5: Flush the Cache After Major Changes

Object caching plugins usually handle cache invalidation automatically when content changes, but after bulk edits, plugin updates, or theme changes, it’s worth manually flushing the object cache from its settings page. This forces WordPress to rebuild the cached data from scratch rather than serving anything stale left over from before the change.

A Worked Example: A WooCommerce Store’s Hit Ratio

A mid-sized WooCommerce store I set up on managed hosting was already running a solid page-caching plugin and a CDN, but checkout and account pages — which can never be served from a static cache — were still measurably the slowest pages on the site. Enabling Redis Object Cache with the store’s existing Redis instance (already provisioned by the host but unused) took under ten minutes. The hit ratio started at 0% immediately after activation, climbed to around 60% within the first hour of real browsing traffic, and settled above 90% by the next day once the cache had warmed up across the catalogue’s most-viewed products. TTFB on the cart page dropped from roughly 480ms to under 150ms over that same period — the actual database queries behind cart totals, shipping calculations, and product data were now being served from memory instead of hitting MySQL on every single request.

Practical Tips

• Redis generally outperforms Memcached for WordPress because it supports more of the caching plugin’s advanced features, including cache groups and non-blocking flushes.
• If you’re already running a WordPress caching plugin for page-level caching, keep it — object caching complements page caching rather than replacing it. They solve different problems.
• On WooCommerce sites, object caching typically delivers the biggest visible improvement, since cart and checkout pages can never be served from a static page cache — and as of WooCommerce 11.0, product-level object caching is on by default, so a persistent backend now has more to actually cache out of the box.
• Give the cache a day of real traffic before judging the hit ratio — a freshly enabled cache starts cold, as the worked example above shows.

Common Mistakes

• Installing an object cache plugin without confirming Redis or Memcached is actually running on the server — the plugin will either error out or silently do nothing, and Site Health will keep showing the same warning.
• Running two object cache plugins at once, which causes conflicting object-cache.php drop-in files and unpredictable behaviour.
• Forgetting to flush the object cache after a major content migration, leaving old data cached alongside new.
• Assuming object caching will fix a slow page that’s actually bottlenecked by unoptimised images or render-blocking scripts — it only affects database query performance, not asset delivery.

When to Use This vs Alternatives

If your site is a simple brochure or blog with mostly logged-out visitors, a good page caching plugin and a CDN will usually cover you without needing object caching at all. Object caching earns its place once you have WooCommerce, membership content, a busy admin area, or any situation where a meaningful share of traffic can’t be served from a static page cache.

For stores that outgrow the free tier, Object Cache Pro is the established paid alternative to Redis Object Cache — a one-time $95 licence that adds intelligent cache invalidation (clearing only what actually changed rather than flushing broadly), object compression to reduce memory footprint, and optimisations specifically aimed at cutting Redis round-trip time under heavy concurrent load. It’s genuinely aimed at high-traffic WooCommerce stores rather than a general blog, and several managed hosts (Cloudways among them) now partner with it directly rather than treating it as a third-party add-on. For most sites, the free Redis Object Cache plugin covers the need completely; Object Cache Pro is worth the cost specifically once cache invalidation overhead itself becomes a measurable bottleneck.

It’s also worth pairing this with the broader work in improving Core Web Vitals, since faster server response time feeds directly into your Largest Contentful Paint score. For the full picture of the WordPress fundamentals object caching builds on, the step-by-step guide to building a WordPress website is a good starting reference.

Conclusion

Object caching won’t fix every performance problem, but on a database-heavy WordPress site it closes a gap that page caching and CDNs can’t reach. Check Site Health first to confirm whether you’re missing it, confirm your host supports Redis or Memcached, install the matching plugin, and check the hit ratio after a day of real traffic to make sure it’s actually doing its job.