Cache a blog wrong and a reader sees yesterday’s headline. Cache a store wrong and a customer sees someone else’s cart, an out-of-stock item as buyable, or a price that changed an hour ago. WooCommerce sites need real caching to be fast, but they need it applied with more precision than a typical content site. Here’s how to get the speed without the broken checkout.
Why WooCommerce Breaks Normal Caching Rules
Full-page caching works by serving the same HTML to every visitor. That’s fine for a homepage or a blog post. It falls apart the moment a page is different for every visitor, which is most of what makes a store a store: what’s in the cart, whether you’re logged in, your shipping estimate, your order history.
WooCommerce also leans hard on the database for things a blog never touches: stock levels, cart sessions, coupon validation, tax and shipping calculations. A cache layer that doesn’t know the difference between a product page (mostly static) and a cart page (entirely personal) will either cache too much and break checkout, or cache too little and leave you no faster than an uncached site.
Pages That Must Never Be Fully Cached
Set these aside as always-dynamic, no matter which caching plugin or CDN you use:
- Cart (
/cart/): contents and totals are per-visitor. - Checkout (
/checkout/): order review, payment fields, nonces. - My Account (
/my-account/): order history, addresses, downloads. - Any page with the mini-cart or an add-to-cart form that shows live stock or price: these often live on otherwise cacheable pages, which is why fragment caching (below) matters more than page-level exclusions.
Product and category pages, by contrast, are usually safe to cache in full for guest visitors, since the content is the same for everyone until something in the catalog changes. The trick is telling your cache when that catalog change happens so it purges the right pages, not the whole site.
Object Caching: The Real Speed Lever for Stores
Page caching gets the headlines, but for a store, persistent object caching does more of the real work. WooCommerce runs a lot of repeated, expensive queries: product lookups, meta queries for variations, session and transient reads. A persistent object cache backed by Redis or Memcached keeps those results in memory across requests instead of hitting MySQL every time, which matters most on pages page caching can’t fully cover, like the cart and checkout.
To set it up with wp-cli, assuming Redis is available on the server:
wp plugin install redis-cache --activate
wp redis enable
wp redis status
Confirm the drop-in is active by checking that object-cache.php exists in wp-content/ and that wp redis status reports a working connection. Without persistent object caching, every dynamic page (cart, checkout, account) rebuilds its data from the database on every load, which is exactly where a store feels slow.
Configuring LiteSpeed Cache for WooCommerce
If you’re on LiteSpeed or OpenLiteSpeed, the LiteSpeed Cache plugin has WooCommerce-aware defaults that handle most of this automatically: it recognizes cart, checkout, and account pages and excludes them from full-page caching without you writing rules by hand. Still worth verifying in the plugin’s Cache settings that these exclusions are active, especially after a plugin update.
For the mini-cart or any cart indicator that appears on cached pages (like a “2 items in cart” icon in the header), use ESI (Edge Side Includes), which LiteSpeed Cache supports natively for WooCommerce. ESI lets you cache the surrounding page as static HTML while that one fragment is generated fresh per visitor. That’s the difference between caching a product page fully and caching it “almost fully except for the one part that has to be personal.”
Set your cache TTL for product and category pages to something reasonable (a few hours is common), and make sure automatic purge is wired to product and stock updates so a sold-out item doesn’t show as available from a stale cache.
Cloudflare Edge Rules for a Store
Cloudflare’s edge cache is powerful but blunt by default. If you’re running Cloudflare in front of WooCommerce, you need rules that keep it from caching pages it shouldn’t touch. Using Cloudflare’s Cache Rules (or Page Rules if that’s what your plan uses), set up a bypass for:
- Paths:
/cart/*,/checkout/*,/my-account/* - Requests carrying WooCommerce session cookies (commonly named around
woocommerce_session_andwp_woocommerce_session), so any logged-in or in-session visitor skips the edge cache entirely
Everything else, product pages, category archives, the blog, static assets, can be cached at the edge with a normal TTL. This combination (LiteSpeed handling origin-level page and object caching, Cloudflare handling edge caching and bypass rules for anything session-based) is what lets a store be fast for anonymous shoppers while staying accurate for anyone with something in their cart. A managed host that has this WooCommerce-aware LiteSpeed and Cloudflare pairing set up out of the box (this is part of what ServerBorn configures by default) saves you from hand-building these exclusion rules yourself.
Testing Before You Trust It
Never assume a caching config works. Verify it:
- Add an item to cart in a private browser window, then load the same product page in a second private window. Confirm the cart count doesn’t leak between them.
- Change a product’s price or stock status, then check the front-end page for that product within your cache’s TTL. If it doesn’t update after a purge, your purge hooks aren’t wired to product updates.
- Complete a full checkout as a test order, using a test payment method if your gateway supports one, to confirm no cached page interferes with nonces or order review.
Do this after any change to caching plugins, hosting migration, or WooCommerce major update. Caching bugs on a store are silent until a customer hits one, and by then it’s a support ticket, not a test.
Core Web Vitals on Product and Category Pages
Once caching is safe, look at Core Web Vitals for your commerce pages specifically, since they behave differently from your blog. Product pages often have large hero images, so LCP (target 2.5 seconds or under) usually comes down to image sizing and whether your theme lazy-loads the main product image incorrectly. Category grids commonly cause CLS (target under 0.1) when product images or “add to cart” buttons load without reserved dimensions and shift the layout. Check both lab data (PageSpeed Insights or Lighthouse) and real user field data, since a fast lab score on a product page doesn’t guarantee a fast experience for shoppers on slower connections.
Takeaway
A store isn’t a blog with a cart bolted on, and it shouldn’t be cached like one. Keep cart, checkout, and account pages dynamic, lean on persistent object caching (Redis or Memcached) to speed up the parts that can’t be page-cached, use ESI or fragment caching for cart indicators on otherwise static pages, and pair origin caching with edge rules that bypass anything session-based. Test it with a real add-to-cart and checkout flow, not just a page load, and you get the speed of a cached site without the risk of showing a customer the wrong cart.