Product Caching in WooCommerce: The 3 Layers, and What 11.0 Changes

When a client tells me “I already installed a cache, the site should be fast,” they’re almost always talking about just one of the three caching layers that coexist on a WooCommerce store. And it’s rarely the one causing the problem. The word “cache” covers very different mechanisms, acting in different places and solving different problems.

WooCommerce 11.0 (scheduled for July 28, 2026) has just enabled a new form of product caching by default — but only on new stores. It’s a good opportunity to clear up these three layers, and to understand what this change means for you in practice.

Layer 1: the page cache

This is the one everyone knows, provided by WP Rocket, LiteSpeed Cache, WP Super Cache, or directly by your host.

The principle: the first time a visitor loads a page, WordPress runs all the PHP, queries the database, and generates the final HTML. The cache plugin stores that HTML and serves it as-is to subsequent visitors, without running PHP again. The result: a near-instant page.

It’s very effective… for static pages. The problem is that WooCommerce’s most critical pages are not cacheable: the cart, checkout, customer account, and every AJAX request (cart fragments, product search, shipping calculation) change for each visitor. That’s exactly why a cache plugin is never enough on its own for a store. The page cache does nothing for PHP execution speed on dynamic pages.

Layer 2: the persistent object cache (Redis, Memcached)

This is the most misunderstood layer, and the most useful on a high-traffic store.

WordPress has an internal object cache, but by default it is non-persistent: it only lives for the duration of a single request, then disappears. Every new request starts from scratch and re-queries the database.

By installing a persistent backend like Redis or Memcached (plus a plugin such as Redis Object Cache), this cache survives between requests and is shared across all visitors. The results of expensive queries — options, product metadata, taxonomy terms — are kept in memory instead of being recomputed. On a store with many products and traffic, this is often the most dramatic gain, precisely because it speeds up the dynamic pages the page cache can’t touch.

Note: this persistent cache must be properly flushed during bulk operations, otherwise it grows without bound. I cover this point in the article on WooCommerce migrations with WP-CLI. And keeping a database healthy isn’t only about caching: the growth of Action Scheduler’s tables and the weight of autoloaded options weigh just as much on performance.

Layer 3: the in-memory product cache (the 11.0 feature)

Here is the third layer, the finest-grained, and the one WooCommerce 11.0 enables.

On a single product page, WooCommerce can call wc_get_product() dozens of times for the same product: once for the title, once for the price, once for the stock, once per variation, once per related product… On each call, the product object is rebuilt. That’s redundant work, within one and the same request.

Product object caching intercepts these calls and serves the object from a request-scoped in-memory cache. Official characteristics:

• The cache is non-persistent: it is cleared at the end of each request. Nothing like Redis, which survives between requests.
• Repeated calls for the same product return clones, not references — so two pieces of code can’t accidentally share mutable state.
• No manual cache management is required.

The gains announced by WooCommerce (measured during the experimental phase in 10.5): variable products load ~9-12% faster on product pages, and bundle products are processed 6-12% faster during checkout (source: developer.woocommerce.com).

This layer is complementary to the other two: it replaces neither the page cache nor Redis. It simply eliminates waste within a single request.

What WooCommerce 11.0 changes exactly

The feature followed a classic path: introduced as experimental in 10.5, changed from “incompatible” to “compatible” by default in 10.6 (no issues found across the extension ecosystem), and now enabled automatically in 11.0 — but only when a new store is installed. It’s the same pattern HPOS followed.

The key point: existing stores are not touched by the update.

In other words: if your store has been running for a while and you simply update to 11.0, you don’t automatically benefit from this free optimization. To enable it: WooCommerce → Settings → Advanced → Features, then tick “Cache Product Objects”.

The trap: when NOT to enable it without testing

For the vast majority of stores, enabling this cache is risk-free and all upside. But there is one case to watch.

Extensions that run direct SQL queries against product data, without going through WordPress’s standard meta hooks, may return stale data: their queries bypass the hooks that trigger cache invalidation. Extensions that retrieve products exclusively through wc_get_product() and standard WooCommerce APIs are not affected.

The typical case: a dynamic pricing plugin (prices indexed on a commodity rate, recalculated in real time, B2B with per-customer pricing…). If the price must be re-evaluated on every call but ends up frozen in cache for the duration of the request, you display the wrong price. On this kind of store, test on staging before enabling — and keep the ability to turn the feature off.

Eventually, WooCommerce plans to enable this feature on all stores, including existing ones, based on adoption data. No timeline announced, but it’s worth getting ahead of it: checking now whether your site is compatible will save you a surprise the day enablement becomes automatic for everyone.

Bonus: which caches are actually active on your store?

Many store owners believe they have “the cache” without knowing which of the three layers are really running. Here’s how to check in two WP-CLI commands.

Is the persistent object cache (layer 2) active?

wp eval 'echo wp_using_ext_object_cache()
  ? "Persistent object cache: ACTIVE\n"
  : "Persistent object cache: INACTIVE (no Redis/Memcached)\n";'

If the answer is INACTIVE and your store has traffic, this is often the most cost-effective performance lever to put in place.

Is WooCommerce’s product cache (layer 3) enabled?

wp option get woocommerce_feature_product_instance_caching_enabled

A value of yes means it’s active, no (or a missing option) means it’s not. Without WP-CLI, the information is under WooCommerce → Settings → Advanced → Features. And to check the persistent cache without the command line, look at Tools → Site Health: WordPress flags there whether a persistent object cache is in place.

Not sure which cache layers are running on your store, or whether an extension risks serving stale prices? Request a free audit — cache architecture is one of the first things I analyze in a WooCommerce optimization.