LiteSpeed Cache for WooCommerce: Complete Configuration Guide

Most LiteSpeed Cache guides walk through every settings tab without addressing what WooCommerce stores actually need.

The result? Store owners either cache too aggressively and break their checkout, or play it safe and leave performance on the table.

The challenge isn’t understanding what each toggle does – it’s knowing which combination of settings works for your specific store type.

This guide covers every WooCommerce-specific decision you’ll face, from choosing the right cache strategy to handling cart fragments, payment gateway conflicts, and multi-currency setups.

If you haven’t configured the general LiteSpeed Cache settings yet, start with the complete LiteSpeed Cache settings guide first, then come back here for the WooCommerce-specific layer.

Skip to the configuration steps

How LiteSpeed Cache handles WooCommerce

LiteSpeed Cache includes built-in WooCommerce integration through its Third Party module. When the plugin detects WooCommerce, it automatically applies several cache rules behind the scenes.

The plugin registers WooCommerce-specific cookies (woocommerce_items_in_cart, woocommerce_cart_hash) as cache-vary triggers. It also marks the cart, checkout, and my-account pages as non-cacheable by default.

This automatic detection handles the basics. But it doesn’t optimize for your specific store configuration – that’s where manual tuning comes in.

What the auto-detection covers

When LiteSpeed Cache detects an active WooCommerce installation, it applies these rules automatically:

• Cart, checkout, and my-account pages are excluded from public cache.
• The woocommerce_items_in_cart cookie triggers private cache variation.
• Product pages are cached publicly by default.
• WooCommerce REST API endpoints respect the global REST cache setting.

What you still need to configure

The auto-detection doesn’t cover ESI blocks for mini-carts, object cache group exclusions, cart fragment optimization, crawler behavior for large catalogs, or multi-currency cache variation. That’s where most of the performance is won or lost.

Public cache, private cache, or ESI

Most guides skip this decision entirely. LiteSpeed Cache offers three caching approaches, and the right choice depends on how personalized your store pages are.

When to use each approach

If your store shows the same prices to all visitors and doesn’t display user-specific content on product pages, public cache is the right choice. Most WooCommerce stores with standard product catalogs fall into this category.

Switch to private cache if your store displays role-based pricing (wholesale vs retail), personalized recommendations based on purchase history, or membership-gated content on product pages.

ESI works best when most of the page is identical for all visitors, but you have small dynamic blocks like a mini-cart counter in the header, a “recently viewed products” widget, or a logged-in user greeting.

ESI lets you cache the page body publicly while serving those small blocks privately. The LiteSpeed blog covers the technical details of how these three approaches compare under the hood.

Cache exclusions for WooCommerce

LiteSpeed Cache’s auto-detection handles the obvious pages, but you should verify and add a few more manually.

Pages to exclude

Navigate to LiteSpeed Cache > Cache > Excludes and confirm these URLs are listed under “Do Not Cache URIs”:

• /cart/
• /checkout/
• /my-account/
• /wishlist/ (if using a wishlist plugin)
• Any custom endpoint that displays user-specific data

LiteSpeed Cache typically adds the first three automatically, but check to be sure – especially after WooCommerce or plugin updates that may change page slugs.

Cookies to watch

Under LiteSpeed Cache > Cache > Excludes > Do Not Cache Cookies, be careful about what you add. Adding a cookie that appears on every page request (like woocommerce_cart_hash) effectively disables caching for your entire site.

Instead, use the Vary Cookie approach under Cache > Advanced > Vary Cookies. This tells LiteSpeed to create different cache versions based on cookie values rather than skipping cache entirely.

Query strings

Some WooCommerce extensions append query strings for tracking or filtering. Under Do Not Cache Query Strings, add any parameters that produce user-specific results:

• add-to-cart
• removed_item
• undo_item

Fixing the cart fragments problem

WooCommerce ships with a script called wc-cart-fragments that fires an AJAX request on every page load. This request (?wc-ajax=get_refreshed_fragments) updates the mini-cart widget with the current cart contents.

The problem: this AJAX call runs on every single page, even when the cart is empty and even when your theme doesn’t display a mini-cart. On a busy store, these requests add up fast – I’ve seen them account for 30-40% of total server requests.

How to identify the problem

Open your browser’s DevTools, go to the Network tab, and filter by wc-ajax. If you see a get_refreshed_fragments request firing on product pages or archive pages, you’re paying a performance tax on every page view.

Look at the response time. A healthy response should complete in under 300ms.

If it’s taking longer, the problem is compounding with every concurrent visitor.

Three solutions

Option 1: Disable fragments everywhere except cart and checkout. This is the safest approach for stores that don’t rely on a dynamic mini-cart in the header.

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

Option 2: Load fragments only after user interaction. This delays the AJAX call until the visitor scrolls, clicks, or hovers – keeping the functionality while eliminating the upfront cost.

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

add_action( 'wp_footer', function () {
    if ( is_cart() || is_checkout() ) {
        return;
    }
    ?>
    <script>
    (function() {
        var loaded = false;
        function loadFragments() {
            if (loaded) return;
            loaded = true;
            var s = document.createElement('script');
            s.src = '<?php echo includes_url( "js/jquery/jquery.min.js" ); ?>';
            s.onload = function() {
                var f = document.createElement('script');
                f.src = '<?php echo WC()->plugin_url(); ?>/assets/js/frontend/cart-fragments.min.js';
                document.body.appendChild(f);
            };
            document.body.appendChild(s);
        }
        ['scroll','mouseover','touchstart','keydown'].forEach(function(e) {
            window.addEventListener(e, loadFragments, {once: true, passive: true});
        });
    })();
    </script>
    <?php
}, 99 );

Option 3: Cookie-based conditional loading. Only fire the fragments request when a WooCommerce cart cookie exists, meaning the visitor actually has items in their cart.

add_action( 'wp_enqueue_scripts', function () {
    if ( is_cart() || is_checkout() ) {
        return;
    }
    if ( ! isset( $_COOKIE['woocommerce_items_in_cart'] ) || $_COOKIE['woocommerce_items_in_cart'] == 0 ) {
        wp_dequeue_script( 'wc-cart-fragments' );
    }
}, 100 );

Starting with WooCommerce 7.8, cart fragments are disabled by default unless a Cart Widget block is rendered on the page. If you’re running WooCommerce 7.8+, check whether the script is even loading before applying these fixes.

ESI configuration for WooCommerce

If you’re running LiteSpeed Enterprise or using QUIC.cloud, ESI gives you the best of both worlds – cached pages with dynamic blocks where you need them.

Navigate to LiteSpeed Cache > Cache > ESI to configure these settings.

Which blocks to ESI

The ESI blocks that matter most for WooCommerce:

• Cache Admin Bar: ON – caches the WordPress admin bar as a separate ESI block for logged-in admins browsing the store.
• Cache Comment Form: ON – keeps the comment/review form dynamic while caching the rest of the product page.
• ESI Nonces: Add WooCommerce-specific nonces that should be served dynamically. LiteSpeed already pre-defines several WooCommerce nonces (including PayPal Checkout nonces), but add any custom nonces from third-party plugins here.

Mini-cart ESI

The mini-cart widget is the most common ESI use case for WooCommerce. When ESI is enabled, the cart count and contents are cached privately per session, while the product page around them stays in public cache.

This eliminates the need for the cart fragments AJAX call on every page – the mini-cart block is served directly from ESI private cache, updated only when the cart actually changes.

Vary groups for role-based pricing

If your store uses role-based pricing (e.g., wholesale vs retail customers), configure Vary Groups under the ESI tab. Assign different Vary Group IDs to each user role so they receive the correct cached version of product pages.

For example, set the “wholesale_customer” role to Vary Group 1 and leave regular customers at 0. LiteSpeed will maintain separate cache copies for each group.

Object cache settings for WooCommerce

Object caching with Redis or Memcached cuts database queries on every uncached or dynamic page load. For WooCommerce stores with large catalogs, the TTFB difference is noticeable – especially if you’ve already enabled HPOS for faster order handling.

Navigate to LiteSpeed Cache > Cache > Object.

Redis vs Memcached

Both work, but Redis is the better choice for WooCommerce because it supports persistent connections and data structures that map well to WooCommerce sessions and transients.

Here are real-world TTFB numbers from a WooCommerce store I tested with and without Redis:

Recommended settings

• Object Cache: ON (only if your server has Redis or Memcached installed).
• Method: Redis.
• Host: 127.0.0.1 (or the Unix socket path for lower latency).
• Port: 6379.
• Default Object Lifetime: 3600 seconds (1 hour). Going lower than 600 seconds can cause issues with password reset tokens and WooCommerce session validation.
• Persistent Connection: ON.
• Cache WP-Admin: OFF – WooCommerce admin pages (orders, product editing) need live data.
• Store Transients: ON.

Groups to exclude

Under Do Not Cache Groups, verify that comment, counts, and any session-related groups are listed. WooCommerce sessions are handled through its own session handler, but if you’re using plugins that store session data in WordPress object cache groups, add those groups here.

TTL strategy for product pages

Not all WooCommerce pages need the same cache duration. A product page with fast-moving inventory shouldn’t have the same TTL as a static “About Us” page.

Navigate to LiteSpeed Cache > Cache > TTL.

Recommended TTLs

Purge rules for stock and price changes

LiteSpeed Cache includes “Smart Purge” that automatically clears a product’s cache when the post is updated. This covers manual product edits, but stock changes from orders need additional attention.

When a customer completes a purchase, WooCommerce reduces stock via the woocommerce_reduce_stock hook. LiteSpeed’s integration typically catches this and purges the product page.

But if you’re using third-party inventory management plugins that update stock outside WooCommerce’s standard hooks, you may need to trigger a purge manually:

do_action( 'litespeed_purge_post', $product_id );

You can hook this into any custom stock update process to ensure the cached product page reflects the current inventory.

Under LiteSpeed Cache > Cache > Purge, keep “Purge All On Upgrade” enabled. WooCommerce updates can change template output, and serving stale HTML after an update causes layout issues.

CSS/JS optimization without breaking checkout

LiteSpeed Cache’s page optimization features (minify, combine, defer) can break WooCommerce checkout flows. Payment gateway scripts are sensitive to being combined, deferred, or delayed.

Common conflicts

• Stripe: Google Pay and Apple Pay buttons disappear when scripts are combined or deferred. Stripe’s stripe.js must load synchronously.
• Braintree/PayPal: Payment form fields fail to render if scripts from braintreegateway.com are minified or delayed.
• Variation swatches: Plugins that render color/size swatches on product pages may break if their JS is combined with other scripts.
• Custom checkout plugins: CheckoutWC and similar plugins require ESI to be disabled in their documentation.

How to diagnose

Append ?LSCWP_CTRL=before_optm to any URL to load the page without LiteSpeed’s CSS/JS optimization. If the page works correctly with this parameter, the issue is in the optimization settings, not the cache itself.

Safe exclusion strategy

Navigate to LiteSpeed Cache > Page Optimization > Tuning Settings and add problematic scripts to the appropriate exclude fields:

1. JS Deferred Excludes: Add payment gateway scripts that must load synchronously (e.g., stripe.js, braintreegateway.com).
2. JS Delayed Excludes: Add scripts that break when loaded on user interaction (e.g., variation swatch scripts, quantity selectors).
3. JS Combine Excludes: Add third-party scripts that conflict when bundled (e.g., payment SDKs, analytics trackers on checkout).

Alternatively, add the data-no-optimize attribute to any script tag in your theme or plugin to exclude it from all LiteSpeed optimizations at once.

Crawler settings for WooCommerce

LiteSpeed’s crawler pre-warms your cache by visiting pages before real users do. If you have hundreds or thousands of products, configuring the crawler properly keeps visitors from hitting uncached pages.

Navigate to LiteSpeed Cache > Crawler.

Sitemap-based crawling

The crawler uses your sitemap to discover URLs. Make sure your WooCommerce product sitemap is included (check Crawler > Sitemap).

If you’re using Yoast SEO or Rank Math, the product sitemap is typically at /product-sitemap.xml.

Delay tuning for large catalogs

The default crawl delay works fine for small stores. For larger catalogs, reduce the delay to warm the cache faster without overloading the server:

• Delay: Start at 500 microseconds for stores under 1,000 products. Reduce to 200 for larger catalogs if your server can handle it.
• Run Duration: Keep the default or increase it if the crawler can’t finish a full cycle within the allotted time.
• Interval Between Runs: Set this shorter than your lowest page TTL. If product pages expire after 24 hours, run the crawler at least every 12 hours.

The geolocation cache warming limitation

If your store uses geolocation-based pricing or currency display (via WPML or a similar plugin), the crawler can only warm the cache for the server’s own location. It can’t simulate visitors from different countries.

WooCommerce’s “Geolocate (with page caching support)” option appends a version parameter to URLs per country, creating separate cache entries. Since the crawler runs from your server’s IP, it only warms the cache for that single location.

Visitors from other countries still hit an uncached page on their first visit.

There’s no workaround for this within LiteSpeed Cache alone. If geo-targeted caching matters for your store, QUIC.cloud’s CDN can serve and warm cache from edge locations globally.

Multi-currency and multilingual caching

Stores that serve multiple languages or currencies need extra cache configuration so visitors don’t see the wrong prices or language.

Multilingual caching with Polylang or WPML

If you’re running a multilingual WordPress site with Polylang or WPML, LiteSpeed Cache handles language variation automatically through URL structure. Each language version has a different URL, so each gets its own cache entry.

You don’t need extra configuration for language caching as long as your translation plugin uses directory-based or subdomain-based URLs (e.g., /en/shop/ vs /he/shop/).

Multi-currency configuration

Multi-currency is trickier. When a visitor switches currency, the selection is stored in a cookie.

LiteSpeed needs to know about this cookie to serve the correct cached version.

Navigate to LiteSpeed Cache > Cache > Advanced > Vary Cookies and add the currency cookie used by your plugin:

• WPML + WooCommerce Multilingual: wcml_client_currency
• Aelia Currency Switcher: aelia_cs_selected_currency
• WOOCS: woocs_current_currency

For WPML specifically, you may also need to force cookie-based storage instead of session-based storage. Add this to your theme’s functions.php:

add_filter( 'wcml_user_store_strategy', function ( $strategy, $key ) {
    return 'cookie';
}, 10, 2 );

Without this filter, the currency selection may be stored in the PHP session, which LiteSpeed can’t use for cache variation. The cookie approach ensures each currency gets its own cached version.

FAQs

Common questions about LiteSpeed Cache and WooCommerce:

Summary

Configuring LiteSpeed Cache for WooCommerce goes beyond the basics covered in a general settings guide. Start by picking the right cache strategy (public, private, or ESI) for your store type.

Then handle cart fragments, set up object cache with proper TTLs, and exclude payment gateway scripts from CSS/JS optimization.

If you’re using Guest Mode, make sure it’s configured correctly alongside the WooCommerce-specific settings covered here.

If you have questions about your specific store setup, drop a comment below.