WooCommerce 10.5 introduces an experimental Product Object Caching feature that improves performance by caching product instances during each request, preventing duplicate product loads from the database redundant object instantiation overhead when the same product is loaded multiple times within a single request
Update (January 26, 2026) and clarification: An earlier version of this post incorrectly stated that this feature "prevents duplicate product loads from the database." Product data is already cached by WordPress. This feature prevents redundant object instantiation overhead. The post has been updated to clarify this distinction.
Product data itself (post data, meta, taxonomy terms) is already cached by WordPress's object cache and standard post caching mechanisms - used by the underlying Product Datastore. However, every call towc_get_product()creates a fresh product instance from that cached data - a process that involves object creation, property setting, and meta loading. This hydration overhead often takes 0.5-0.9ms per product (or longer with heavy meta data).
How It Works
When enabled:
wc_get_product()/WC_Product_Factory::get_product()checks an in-memory cache before loading from the datastore- Products loaded from the datastore are cached for subsequent calls within the same request
- Cache is automatically invalidated when products are updated via standard WooCommerce/WordPress APIs
- The cache is non-persistent (in-memory only, clears between requests)
Enabling the Feature
- Navigate to WooCommerce → Settings → Advanced → Features
- Enable “Cache Product Objects”
Performance Impact
Performance improvements will vary significantly based on:
- The extensions active on your site
- How those extensions interact with products (how many times they load the same product)
- The types of products being loaded (simple, variable, bundles, subscriptions)
Example benchmarks (with WooCommerce All Products for Subscriptions active):
| Product Type | Operation | Improvement |
|---|---|---|
| Variable Product | View Product Page | -160ms to -227ms (~9-12%) |
| Variable Product | Add to Cart | -235ms to -250ms (~12-13%) |
| Bundle Product | Place Order | -165ms to -234ms (~6-12%) |
| Simple Product | Place Order | -22ms to -56ms (~2-6%) |
Note: These benchmarks were captured with WooCommerce All Products for Subscriptions enabled, which triggers additional product loading operations. Sites with different extension combinations will see different results – some more, some less.
How can developers tell if they are affected?
The caching implementation uses standard WordPress and WooCommerce hooks for cache invalidation. In most cases, extensions should work without modification. However, there are edge cases to be aware of:
Cache invalidation is triggered by:
clean_post_cacheaction (WordPress post updates/deletions)updated_post_meta,added_post_meta,deleted_post_metaactionswoocommerce_updated_product_stockandwoocommerce_updated_product_salesactions- WooCommerce product datastore
save()operations
Potential compatibility considerations:
- Direct SQL updates: If your extension updates product data using direct database queries without triggering WordPress meta hooks or calling
clean_post_cache(), the cached product will become stale for the remainder of the request. - Repeated product loading: If your extension calls
wc_get_product()multiple times for the same product ID within a request, all calls will return clones of the same cached instance. This is the intended behavior and should be transparent to most code.
What action do developers need to take if affected?
This feature is disabled by default, but can be enabled by store owners. Third party developers should test for compatibility.
If you encounter unexpected behavior with this feature enabled, please open an issue with details about which extensions are active.
Leave a Reply