WooCommerce Cart Caching lets your visitors keep getting cached pages from Edge Cache after they add something to their cart. The page arrives from our edge network instead of waiting on the origin server to build it, so it loads faster and feels more responsive.
Cart Caching is in beta. It is off by default, and our support team enables it per site on request. It also requires Edge Cache to be enabled on the site.
Edge Cache comes with every plan and is on by default, but you should confirm it’s currently toggled on.
A site with Edge Cache switched off cannot use Cart Caching.
How WooCommerce Cart Caching Works
Normally, the moment a shopping cart cookie appears, every request after that bypasses the cache. That keeps cart contents accurate and private to the shopper, at the cost of a full origin request for every page view, including product and category pages that have not changed in weeks.
WooCommerce Cart Caching splits the page in two. The body of the page comes from our Edge Cache network. The cart elements (cart count, mini cart, subtotal) get filled in afterward by WooCommerce’s own JavaScript.
Three cookies mark a visitor as having a cart, and WooCommerce Cart Caching allows all three to keep receiving cached pages: wp_woocommerce_session_*, woocommerce_items_in_cart, and woocommerce_cart_hash.
Cart, Checkout, and My Account Pages Are Unchanged
WooCommerce Cart Caching never touches /cart, /checkout, or /my-account. Those stay uncached and fully dynamic, the same as today. What changes is how the rest of your site gets served to someone who has a cart.
Cart Data Stays Private to Each Visitor
Only the cart-free body of the page is cached and shared. Each visitor’s cart data is fetched separately for their own session and never written into Edge Cache, so there is no path by which one shopper sees another shopper’s cart.
What WooCommerce Cart Caching Does Not Do
WooCommerce Cart Caching serves pages from the cache. It does not add pages to it. A page requested by a visitor who has a cart is never written into the cache.
Cart-specific HTML cannot end up in the cache, so turning the feature on and off again leaves nothing behind to clean up.
One caveat: a shopper with a cart who lands on a page that is not already cached still triggers an origin request. If you have a large catalog with a long tail of rarely visited products, the benefit lands mostly on your popular pages.
When WooCommerce Cart Caching Is Not a Good Fit
WooCommerce Cart Caching only works if your theme and plugins support WooCommerce’s cart refresh system. If your theme or plugins don’t support this native WooCommerce function, the WooCommerce Cart Caching feature will not be compatible with your site.
Whether the WooCommerce Cart Caching feature suits your store is something only testing on your own site will tell you.
Check for the Cloudflare Proxy Before You Test
If your site sits behind Cloudflare’s proxy (the orange cloud), your test results will likely be skewed by the additional cache layer. Cloudflare adds its own caching layer in front of us, which conflicts with our built-in CDN. Switch the relevant DNS records to DNS Only for the duration of the test, or test on a staging clone that is not proxied. For background, see Understanding Pressable’s Security and Cloudflare’s Proxy.
Test Cart Caching on Your Own Session
You can turn WooCommerce Cart Caching on for your own browser session without having it enabled for the site. You should perform these tests before requesting cart caching is enabled.
- Open a Private Browsing or Incognito window. Logged-in users always bypass the cache, so an authenticated session shows you neither the benefit nor the problems.
- Set the
a8c_edge_enable_woocommerce_cart_cachingcookie from your browser’s developer console:
javascript
document.cookie='a8c_edge_enable_woocommerce_cart_caching=1; path=/;'- Add products to your cart and browse the store.
Closing the private window when you are finished ends the test, since the cookie goes with the session. You can also expire it manually, though the path has to match exactly or the cookie survives and you carry on testing without knowing it:
javascript
document.cookie='a8c_edge_enable_woocommerce_cart_caching=; path=/; expires=Thu, 01 Jan 1970 00:00:00 GMT;'Confirm That WooCommerce Cart Caching Engaged
With products in your cart, check the x-ac response header on a page request in your browser’s developer tools. That is where Edge Cache reports itself, with a value of HIT, STALE, EXPIRED, UPDATING, MISS, or BYPASS.
A request carrying a cart cookie returns BYPASS when WooCommerce Cart Caching is not active. Any other value means it engaged. MISS means it engaged but that page was not cached yet on the edge server you reached, which is the limitation covered above, not a failure.
Do not go looking for a Batcache marker. WooCommerce Cart Caching works at the Edge Cache layer, and Batcache staying quiet tells you nothing about whether it worked. We have seen store owners check for Batcache, find nothing, and write their site off as incompatible when both cache layers were fine.
What to Check During Your Test
With products in your cart, browse the store and confirm each of these behaves correctly:
- Several different product types, especially products with custom fields.
- Subscription products, if your store sells them.
- Any complex or conditional cart logic your store depends on.
- The full cart and checkout flow. Multi-stage and non-standard checkouts need particular attention.
- Cart count, subtotal, and mini cart in the header and sidebar, on pages other than the cart.
These are worth a look too, because they are the kind of thing that tends to break:
- Sticky or floating cart widgets.
- Already in your cart messaging on product pages.
- Free shipping threshold notices, cart-based upsells, and dynamic discount messaging.
Treat that as a starting point. Anything on your store that changes based on cart contents deserves a check.
Cart Fragments and WooCommerce Cart Caching
Cart fragments are how WooCommerce refreshes cart elements after a page has loaded without reloading the page itself. Every fragment request goes to your origin, which makes fragments a frequent target for performance work. Our guidance on that is in Maximizing WooCommerce Performance With Proper Use of Cart Fragments.
Read it carefully if you are running WooCommerce Cart Caching, because the two interact. Cart Caching applies only to visitors who have a cart, and those visitors are exactly the ones who need fragments, since fragments are what populate the cart UI on a cached page. Any optimization that stops fragments loading for a visitor with a cart will break WooCommerce Cart Caching and leave the cart UI empty for good. Trimming fragments for visitors with no cart is safe, and still worth doing.
Request WooCommerce Cart Caching for Your Site
Once you have tested and you are happy with what you see, contact our support team to have the feature enabled. Email help@pressable.com or open a chat from the MyPressable Control Panel. You can ask us to turn it off again at any point.
Installing, configuring, and maintaining your plugins and themes stays your responsibility, and problems inside third-party code have to go to that code’s developer. We can help you read what you are seeing during a test, and we can enable or disable WooCommerce Cart Caching for you.
Send Feedback
The feature is still changing while it is in beta, and what we hear from stores actually running it is what decides the fix order. Send anything you run into to support through the channels above. Screenshots of the broken cart display, plus the theme and plugin involved, are particularly useful info to share.