WooCommerce Caching Plugins: What Breaks and What Works

Every WooCommerce caching plugin on this page will make your category pages faster, and any of them will break your store if you point it at the cart. The decision is not which plugin is quickest on a homepage benchmark — it is which one gives you control over the three pages and five cookies that have to stay dynamic, and what it costs to get that control.

Below are the criteria I judged each one on, a table with prices I checked on 21 September 2026, and the weakness of every option including the free ones. Two of these are not page caches at all, which matters more than their feature lists, so I have said so rather than letting them sit in a list as if they were interchangeable.

Three pages and five cookies decide whether caching breaks your store

WooCommerce’s own developer documentation is unusually specific here, and it is the shortest route to a working configuration. Exclude Cart, Checkout and My Account from full-page caching. Those pages render per-customer state, and a cached copy served to the next visitor shows them someone else’s basket.

The cookie list matters just as much, because a request carrying any of these should bypass the cache wherever it lands — including on a product page:

Cookie	Lifetime	What it carries
woocommerce_cart_hash	Session	Changes whenever the cart contents change
woocommerce_items_in_cart	Session	Flags that the cart is not empty
wp_woocommerce_session_	2 days	Points at the customer’s session row in the database
woocommerce_recently_viewed	Session	Feeds the Recently Viewed Products widget
store_notice[notice id]	Session	Remembers that the shopper dismissed the store notice

There is a fourth rule that people skip: exclude _wc_session_ from database or object caching. Cache a session row and you will serve one customer another customer’s cart, which is the failure mode that produces a support ticket you cannot reproduce.

The five criteria I judged each WooCommerce caching plugin on

Stated up front, so you can weigh them differently if your store is shaped differently from the one I assumed — a US store with a few hundred products, a handful of concurrent shoppers, and paid traffic arriving on tagged URLs.

1. Does it actually do page caching, and on what server? Two well-known names in this space are optimization tools, not page caches. One of them only caches on a specific web server. If you install the wrong one expecting full-page caching, you get a slower site and a bill.
2. Cookie-level bypass, not just URL exclusions. Excluding /cart/ protects the cart page. It does nothing for the mini-cart in your header on every other page. A plugin that can bypass the cache on the presence of a cookie solves the whole class of problem.
3. What it does with cart fragments. WooCommerce fires an uncached AJAX request on page load to refresh the mini-cart. It is the slowest request on most stores, and how a plugin handles it is a real differentiator rather than a marketing line.
4. Query-string handling. Ad traffic arrives with utm_source and gclid attached. If each variant is cached as its own entry, your cache fills with duplicates of one page; if query strings are ignored entirely, anything that legitimately depends on them breaks.
5. Total annual cost, renewals included. The advertised figure is the first-year figure on several of these. I have noted where a discount was running on the day I checked, because a dated price is worth something and an undated one is not.

WooCommerce caching plugins compared

Prices come from each vendor’s own pricing page on 21 September 2026. WP Rocket was running a 25% discount that day with a stated end date of 23 September, so its regular figures are the ones to plan around. Install counts are the figures shown on WordPress.org the same day.

Plugin	Page cache?	Price (checked 21 Sep 2026)	Strength for a store	Where it falls short
WP Rocket	Yes, on any server	$59.95/yr for 1 site, $119.95 for 3, $299.95 for 50. Not on WordPress.org. 25% off until 23 Sep 2026	Caches the empty-cart fragment response in a transient, so the slowest request on the page stops hitting PHP for browsing visitors	No free tier at all, so you cannot test it on your own store before paying. Renews annually at the full rate
FlyingPress	Yes, on any server	$59/yr for 1 site, $109 for 3, $229 for 25, $279 unlimited. 14-day free trial	Same price band as WP Rocket with a trial, so you can measure it against your own store before committing	A much smaller product with a much smaller support community. When something specific to your theme breaks, there are fewer people who have hit it before you
LiteSpeed Cache	Only on LiteSpeed Enterprise or OpenLiteSpeed	Free. 7+ million active installs, version 7.9.1	Free full-page caching that is genuinely competitive, plus ESI to punch a live mini-cart hole through a cached page	ESI is not available on OpenLiteSpeed, only on LiteSpeed Enterprise. On Apache or nginx you get the optimization features and no page cache at all
W3 Total Cache	Yes, on any server	Free; Pro $99/yr for 1 site, $350 for 5, $500 for 10. 900,000+ installs, version 2.10.6	The most granular controls here — page, object, database and fragment caching each configured separately	That granularity is the cost. It has more ways to be configured wrongly than everything else on this list combined, and fragment cache optimization sits behind the $99 tier
WP Super Cache	Yes, on any server	Free. 1+ million installs, version 3.1.3, needs WP 6.8+ and PHP 7.4+	WooCommerce’s own docs call it natively compatible and note that WooCommerce prevents caching of the cart, checkout and account pages for you	Static caching with no object or fragment layer. Its answer to dynamic content is “redraw it in JavaScript”, which is honest but leaves the work to you
Perfmatters	No — it is an asset optimizer	$29.95/yr for 1 site, $59.95 for 3, $124.95 unlimited	Disables cart fragments conditionally, only when the woocommerce_cart_hash cookie is absent, so an empty-cart visitor skips the request and a real shopper keeps it	It is not a caching plugin and does not pretend to be. Buying it instead of a page cache is a mistake; buying it alongside one is a reasonable $30
Redis Object Cache	No — object cache only	Free. 500,000+ installs, version 3.0.0. Needs a Redis server plus PhpRedis or Predis	Cuts repeated database queries on pages you cannot page-cache, which is exactly where a store’s slow pages live	Useless without a Redis server your host actually provides, and a badly configured object cache is a new way to serve stale data

That is deliberately not a ranking. The right answer depends on your web server before it depends on anything else, which is the part most roundups skip because it makes the recommendation conditional.

Cart fragments are the request nobody budgets for

WooCommerce ships a script, wc-cart-fragments, that fires an AJAX request on page load to refresh the mini-cart. The URL looks like this:

GET /?wc-ajax=get_refreshed_fragments

It cannot be page-cached, because its whole job is to be per-customer. So on a store where every other request is served from cache in 40 ms, this one still boots WordPress, loads WooCommerce, resolves a session and renders the cart. Perfmatters’ own documentation reports seeing it add up to ten seconds on large sites. That is an extreme case, but it is routinely the slowest thing on an otherwise fast page, and it hurts INP because it competes with the main thread while the shopper is trying to interact.

Three approaches, in order of how much they cost you:

• Cache the empty-cart response. WP Rocket detects the fragments request, checks whether the cart is empty, and stores that response in a transient to return next time. Browsing visitors — most of your traffic — stop paying for it.
• Skip the request when the cart is empty. Perfmatters checks for the woocommerce_cart_hash cookie and only dequeues the script when there is no cart to refresh. Shoppers with items keep a live mini-cart.
• Dequeue it outright. Cheapest and bluntest. The mini-cart then only updates on a page load, which is fine on a store where “add to cart” goes straight to the cart page, and visibly broken on a store with an AJAX add-to-cart button.

If you take the third route, do it conditionally rather than globally:

add_action( 'wp_enqueue_scripts', function () {
    // Keep fragments on the cart and checkout pages, and for
    // any shopper who already has something in their cart.
    if ( is_cart() || is_checkout() || ! empty( $_COOKIE['woocommerce_cart_hash'] ) ) {
        return;
    }

    wp_dequeue_script( 'wc-cart-fragments' );
}, 99 );

Test it by adding a product and watching the header count on a third page. If the number is wrong, your theme relies on fragments and you want one of the first two approaches instead. This is also the kind of change worth making on staging first — the same discipline that applies when you troubleshoot a WordPress plugin conflict.

Page cache and object cache solve different problems

These get bundled together in roundups and they should not be, because a store spends most of its expensive time on pages a page cache is not allowed to touch.

• Page cache stores the finished HTML of a URL and serves it without running PHP. It covers your homepage, category pages and product pages — usually 90% of pageviews and close to 0% of the pain.
• Object cache stores the results of database queries in memory, so PHP still runs but stops asking the database the same question repeatedly. It is the only one of the two that helps on cart, checkout, My Account and wp-admin.

That second point is why a store with a genuinely fast front end can still have a checkout that takes four seconds and an admin that crawls. Redis Object Cache is free and mature, and if your host offers Redis it is usually the highest-value hour you will spend on store performance. W3 Total Cache can drive Redis or Memcached from inside its own settings if you would rather keep one plugin. If your dashboard specifically is the slow part, the diagnosis path is different — start with diagnosing a slow WordPress admin dashboard, because the cause is often an autoloaded options table rather than anything a cache will fix.

Before buying any of this, confirm you are on a current PHP version. Moving from PHP 7.4 to 8.3 is free and typically buys more than a caching licence does; here is how to check and update PHP safely.

Verify the exclusions instead of trusting the settings screen

Every plugin here has a checkbox that claims WooCommerce pages are excluded. Check it from outside with curl, where the cache headers cannot be tidied up by a dashboard:

# A product page SHOULD show a cache hit
curl -sI https://example.com/product/blue-widget/ | grep -iE 'x-.*cache|cf-cache|age:'

# Checkout should NOT. Look for no-store, or a MISS/BYPASS
curl -sI https://example.com/checkout/ | grep -iE 'cache-control|x-.*cache'

# And a request carrying a cart cookie should bypass, even on a product page
curl -sI -b 'woocommerce_items_in_cart=1' \
  https://example.com/product/blue-widget/ | grep -iE 'x-.*cache|age:'

The header name varies by stack — x-litespeed-cache, x-rocket-nginx-serving-static, cf-cache-status, or a plain age: from a reverse proxy. The value is what matters. The third command is the one that catches the expensive bug: if a request carrying a cart cookie still returns a hit, your header mini-cart is being served from cache and some proportion of your shoppers are seeing an empty basket they did not create.

What to buy at your store’s size

• You are on LiteSpeed or OpenLiteSpeed hosting. Install LiteSpeed Cache and spend nothing. Check which server you have first — curl -sI https://example.com | grep -i server — and if it says OpenLiteSpeed, remember ESI is off the table, so handle the mini-cart with the fragments approaches above.
• Apache or nginx, and you would rather not pay. WP Super Cache plus Redis if your host offers it. WooCommerce’s docs call WP Super Cache natively compatible, and the combination is more than adequate for a store doing a few hundred orders a month.
• Apache or nginx, and an hour of your time is worth more than $60. WP Rocket or FlyingPress. FlyingPress has the trial, WP Rocket has the fragments transient and a far larger body of people who have already hit your problem. Either is defensible; paying for both is not.
• You already have a page cache and the store is still slow. Stop shopping for caching plugins. The bottleneck is object caching, PHP version, or front-end weight, and the third of those usually means images — see optimizing images in WordPress without losing quality.

Full-page caching quietly breaks your campaign attribution

This one catches stores the week after they turn caching on, and it is worth planning for if you run paid traffic. When a page is served from cache, PHP does not run. Anything that recorded the visit server-side — a hook reading $_GET['utm_source'], a plugin writing the referrer into a session — records nothing, because there was no PHP request to hook into. Your ad spend keeps going out and your attribution goes quiet, and because the pages still load fast, nothing looks wrong.

The pattern that survives a cache is a client-side beacon: the page arrives from cache, JavaScript reads the query string in the browser and posts it back after load. That is how Google Analytics 4 works, and why it keeps reporting correctly behind a cache. If you want the same data in your own database rather than in Google’s, Burst Statistics and Independent Analytics are the established WordPress options and either is a safe pick.

My own UTM Manager takes the same approach — a navigator.sendBeacon call after page load, writing first-touch and last-touch attribution into its own indexed tables, which is what makes it work behind full-page caching. Disclosure: I build and maintain that plugin. Judged by the criteria I have used for everything else on this page, its weakness is obvious and I am not going to dress it up: 100+ active installs and a version number of 2.0.4 against Burst Statistics’ install base. If you want the option with the longest track record, take one of the other two. The point worth taking away is the mechanism rather than the plugin — anything that measures your campaigns server-side will stop measuring them the day you cache the page it runs on.

Frequently asked questions

Can I cache WooCommerce product pages?

Yes, and you should — they are usually the bulk of your traffic. The caveat is the mini-cart in your header. If your theme renders the cart count in PHP rather than through cart fragments, a cached product page will show a stale count. Test it: add something to the cart, then open a product page you have not visited and check the header number.

Does my host’s built-in cache mean I do not need a caching plugin?

Often it does, for page caching. Managed WooCommerce hosts generally exclude the cart, checkout and account pages at the server level already, and stacking a plugin page cache on top of a server page cache creates two layers to purge and two places for stale HTML to hide. Verify the exclusions with the curl commands above rather than assuming, then use a plugin only for what the host does not do — object caching, or asset optimization.

Is LiteSpeed Cache worth installing if I am not on a LiteSpeed server?

You will not get its page cache, which is the main reason to install it. The general optimization features work on any server, but you would be choosing it over tools built for that job. Check first with curl -sI https://example.com | grep -i server. If the answer is Apache or nginx, look elsewhere for page caching.

Why is my checkout still slow when the rest of the store is fast?

Because checkout is never page-cached, so it runs the full PHP stack every time — sessions, cart recalculation, shipping rate lookups, payment gateway handshakes. Page caching cannot touch it by design. Object caching, a current PHP version and fewer live shipping-rate calls at checkout are the levers that actually move it.

Do I need to exclude WooCommerce pages from my CDN as well?

Yes, and this is the layer people forget. A CDN in front of your origin is another full-page cache, and it has its own rules that know nothing about your plugin’s exclusion list. Configure a bypass for the cart, checkout and account paths and for the WooCommerce cookies at the CDN too, then re-run the cookie curl test against your public hostname rather than your origin.

Should I clear the cache after every product update?

No — every plugin here purges the affected URLs when a post or product is saved. Purging everything on every edit means your next visitors pay to rebuild the whole cache, which on a large catalogue is worse than the stale page you were worried about. Reach for a full purge when something is visibly wrong, not on a schedule.

The short version

Find out what web server you are on, because that decides more than any feature list. Exclude the three pages and the five cookies, then prove it with curl rather than trusting a checkbox. Handle cart fragments deliberately instead of leaving the default in place. And if the store is still slow after all of that, the answer is object caching or images, not a second page cache.

One last thing worth doing before you change any of this: take a backup you have actually tested, because caching changes are easy to revert and plugin conflicts are not. WooCommerce backup plugins compared covers what a store-grade backup needs to capture.