WooCommerce: Cache Plugins Are Not Enough

The Cache Illusion

“Install WP Rocket and your site will be fast.” That’s the advice you read everywhere. And it’s half true. My WooCommerce optimization service goes far beyond cache and addresses the root causes of slowness.

A page cache plugin does one simple thing: the first time a page is visited, it saves the generated HTML and serves it directly to subsequent visitors, without running PHP or querying the database. For a blog or a brochure site, it’s magic. For WooCommerce, it’s insufficient.

Why? Because a WooCommerce store is fundamentally dynamic. The cart changes. The checkout calculates shipping in real time. The customer account displays personal data. Stock levels change. None of this can be cached.

What Cache Doesn’t Cover

Dynamic Pages

These pages are never served from cache (and shouldn’t be):

/cart/ - the shopping cart
/checkout/ - the checkout funnel
/my-account/ - the customer dashboard
Any page with a WooCommerce session cookie

If your checkout takes 3 seconds to load, a cache plugin won’t change a thing.

Admin-Ajax Requests

This is the most common blind spot. As WP Engine’s documentation explains (source: wpengine.com), admin-ajax.php requests are uncacheable - every request is generated fresh, full WordPress bootstrap, WooCommerce loading, PHP execution.

The worst culprit: cart fragments. This WooCommerce script sends an AJAX request on every page to update the mini-cart. Even on your “Terms & Conditions” page. Even for visitors with an empty cart.

According to official WooCommerce documentation (source: developer.woocommerce.com), cart fragments fires “all the time, even when completely unnecessary.” At scale, that translates to thousands of uncacheable requests per day consuming server resources for nothing.

Product Searches and Filters

When a customer filters your products by size, color, or price, each combination generates an SQL query. The larger your catalog, the heavier these queries. A page cache doesn’t speed them up - you need an Object Cache (Redis) to store query results in memory.

The Back-Office

The WordPress admin and WooCommerce back-office are never cached. If your “Orders” page takes 5 seconds to load with 50,000 orders, visitor-side cache won’t help. It’s a database problem - and the solution is called HPOS.

What Actually Works

Cache is an accelerator, not a solution. Fix the underlying problems first, then layer cache on top.

1. Remove What’s Not Needed

Before caching heavy pages, lighten them. Identify scripts and styles loaded needlessly on each page. A tool like Perfmatters (source: perfmatters.io) with its Script Manager lets you disable CSS and JS per page.

The theme is often the first culprit. As Remkus de Vries points out (source: remkusdevries.com): “WooCommerce itself already loads a lot of CSS and JavaScript, and if your theme also loads heavy fonts, jQuery plugins, and icon packs, you’ve just doubled the bloat.”

2. Clean the Database

Autoloaded options load on every request - cached or not. According to Kinsta (source: kinsta.com), keeping autoloaded data under 800 KB is the target. Above that, every request starts by loading MBs of useless data into memory.

3. Set Up the Right Type of Cache

There isn’t one cache - there are three, and they don’t do the same thing:

Object Cache (Redis) - Stores SQL query results in memory. Most impactful for WooCommerce because it speeds up dynamic pages: product search, cart calculation, back-office. Tool: Object Cache Pro + Redis.

Page Cache - Stores the complete HTML for static pages. Effective for the homepage, categories, content pages. Useless for cart and checkout. Tool: WP Rocket, WP Super Cache, or equivalent.

Edge Cache (CDN) - Distributes cached pages on servers worldwide. Visitors get the page from the nearest server. Tool: Cloudflare for WooCommerce — Cloudflare APO ($5/month, designed for WordPress).

4. Disable Cart Fragments

The fastest and most visible gain. Disable wc-cart-fragments.js on all pages except cart and checkout:

add_action( 'wp_enqueue_scripts', function() {
    if ( is_cart() || is_checkout() ) {
        return;
    }
    wp_dequeue_script( 'wc-cart-fragments' );
}, 999 );

Since WooCommerce 7.8, the default behavior has improved: cart fragments is no longer loaded on all pages by default, only when the cart widget is rendered. But many themes still force the old behavior.

5. Migrate to Block Checkout

Block checkout is lighter than legacy, updates without page reload, and supports native express payments. It’s a direct optimization of the part of the site that cache can’t help.

The Lighthouse Score Trap

A cache plugin can give you a 95/100 Lighthouse score on the homepage. But if your checkout takes 4 seconds to load and your admin-ajax requests are saturating the server, your customers don’t see that score - they see a slow site.

Lighthouse tests static pages in lab conditions. Your customers browse dynamic pages in real conditions, on a mobile network with a server under load.

That’s why I always measure field Core Web Vitals (CrUX data via PageSpeed Insights) in addition to Lighthouse audits. They tell a different story.

In Summary

A cache plugin is necessary, but it’s the last layer to set up - not the first. The logical order:

Remove what’s not needed (scripts, styles, unused plugins)
Clean the database (autoloaded options, transients)
Fix structural issues (cart fragments, legacy checkout, HPOS)
Cache what can be cached (Object Cache, Page Cache, Edge Cache)

Adding cache before steps 1-3 is like varnishing a wobbly table.

Your cache plugin isn’t enough? Request a free audit - I look at what’s happening underneath.