WooCommerce Cart Fragments: Fix Slow AJAX

If your WooCommerce store feels sluggish even though your hosting looks fine and your page weight is reasonable, the culprit is often not your theme or your plugins list — it's WooCommerce cart fragments, the built-in AJAX call that fires on nearly every pageload to keep the mini-cart in sync. Open your browser's Network tab on almost any WooCommerce site and you'll usually spot wc-ajax=get_refreshed_fragments firing on load, sometimes taking 800ms–2s on its own, and sometimes firing more than once per page. This post walks through why it happens, how to confirm it's actually your bottleneck, and three real fixes ranging from a quick win to a proper architectural fix.

Why WooCommerce Cart Fragments Exist

Cart fragments are how WooCommerce keeps the cart icon, cart count, and mini-cart contents updated without a full page reload after someone adds an item to their cart. The wc-cart-fragments.js script listens for cart-related events and, more importantly, fires an AJAX request to wc-ajax=get_refreshed_fragments on nearly every single pageload — even pages that have nothing to do with the cart, like a blog post or a static About page — because WooCommerce can't otherwise know if the cart changed in another tab.

That request has to bootstrap a good chunk of WordPress and WooCommerce just to answer "what's in the cart right now," which is why it's disproportionately expensive compared to what it actually returns.

How to Confirm Cart Fragments Are Your Bottleneck

Before changing anything, confirm this is actually the problem:

1. Open Chrome DevTools → Network tab, filter by "Fetch/XHR"
2. Load any page on the site (not just the cart page)
3. Look for a request to ?wc-ajax=get_refreshed_fragments
4. Check its timing — anything over 300–500ms consistently is worth fixing, and it's worse if PHP OPcache is cold or the server is under load

If that request is either slow or firing multiple times per page (a common bug when a theme also queues its own cart-refresh script), you've confirmed the issue.

Fix 1: Disable Cart Fragments on Pages That Don't Need Them

The fastest fix, and the one to try first, is to stop loading wc-cart-fragments.js on pages where the mini-cart total doesn't actually need to be live — typically every page except the cart and checkout pages themselves.

add_action( 'wp_enqueue_scripts', 'my_dequeue_cart_fragments', 99 );
function my_dequeue_cart_fragments() {
    if ( is_cart() || is_checkout() ) {
        return; // keep it where it's actually needed
    }
    wp_dequeue_script( 'wc-cart-fragments' );
}

This alone removes the AJAX call from every non-cart, non-checkout page — usually the majority of pageviews on a typical store. The tradeoff: the header cart icon on those pages will show a cached/stale count until the visitor navigates to a page where fragments still load, which for most themes is a fine tradeoff for the performance gain.

Fix 2: Cache the Fragments Response Itself

If you need the mini-cart to stay live everywhere (some checkout flows genuinely depend on it), don't remove fragments — cache the response per session instead using a WooCommerce session transient, so repeat requests within a short window skip the expensive rebuild:

add_filter( 'woocommerce_add_to_cart_fragments', 'my_cache_cart_fragments', 1 );
function my_cache_cart_fragments( $fragments ) {
    $session_id = WC()->session->get_customer_id();
    $cache_key  = 'cart_fragments_' . $session_id;
    $cached     = get_transient( $cache_key );

    if ( false !== $cached ) {
        return $cached;
    }

    set_transient( $cache_key, $fragments, 30 ); // 30 seconds
    return $fragments;
}

This keeps fragments functionally live (updates within 30 seconds of a real cart change) while avoiding a full rebuild on every single request, which matters most on high-traffic pages during a sale or launch.

Fix 3: Check for Duplicate Fragment Requests

If DevTools showed the request firing more than once per page, the real bug usually isn't WooCommerce core — it's a theme or plugin enqueuing its own copy of wc-cart-fragments.js, or a page builder re-triggering the added_to_cart event on scroll. Search your theme's functions.php and any custom JS for wc-cart-fragments or get_refreshed_fragments to find the duplicate enqueue, then either dequeue the theme's copy or guard the event listener so it only binds once.

Common Mistakes When Fixing This

• Removing cart fragments entirely without keeping them on the checkout page, which can break payment gateways that rely on session data staying in sync
• Caching fragments too aggressively (multiple minutes), which can show a stale cart count right after checkout and confuse customers
• Not testing with an actual multi-tab scenario — cart fragments exist specifically to keep tabs in sync, so verify your fix doesn't break that use case if your store gets a lot of multi-tab shoppers
• Blaming hosting first — this is one of the most common WooCommerce performance issues and it's rarely fixed by upgrading server resources alone, since the bottleneck is the request pattern, not raw CPU

Frequently Asked Questions

Does disabling cart fragments break "Add to Cart" buttons? No. Add-to-cart functionality itself doesn't depend on fragments — fragments only handle refreshing the display of the cart icon/count without a page reload. Dequeuing the script on non-cart pages doesn't affect add-to-cart requests.

Will this fix show up in PageSpeed Insights or GTmetrix? Yes, often significantly — cart fragments frequently show up as a render-blocking or long-running request in Lighthouse audits, and removing it from non-essential pages is one of the more reliable wins for WooCommerce Time to Interactive scores.

Is there a plugin that does this automatically? Several performance plugins (including some caching plugins) include a "disable cart fragments" toggle. The code above does the same thing without adding another plugin dependency, and it's easy to scope to exactly the pages you want.

Does this affect WooCommerce Blocks-based checkout? The block-based checkout (Cart and Checkout blocks) relies less on the legacy AJAX fragments pattern, but many stores still run the classic shortcode-based checkout or a mix of both, so it's worth confirming which checkout your store actually uses before assuming fragments are irrelevant.

Key Takeaways

Cart fragments are a legitimate feature, not a bug, but they're overused by default — WooCommerce ships them firing on every page as a safe default, not an optimized one. Start with Fix 1 (dequeue on non-cart/checkout pages) since it's the lowest-risk, highest-impact change for most stores, confirm the improvement in DevTools' Network tab afterward, and only reach for session-based caching if you have a specific reason the mini-cart needs to stay live everywhere.