How to Disable WooCommerce Cart Fragments (and Speed Up Every Page)

If you run a WooCommerce store, there is a good chance every single page on your site makes a request it does not need. Not on the cart page. Not on checkout. On your homepage, your blog posts, your product pages — everywhere.

The culprit is a small piece of JavaScript called cart fragments. WooCommerce loads it by default, and on most stores it quietly adds an extra server request to every page load. On a fast server you may never notice it. On shared hosting, or on a store with real traffic, it is one of those small taxes that adds up to a noticeably slower site.

The good news: for many stores, you can safely turn it off. This guide explains what cart fragments actually do, how to check whether they are hurting your site, and how to disable them — with a code snippet, with a plugin, and with a middle-ground option that keeps them only where they matter.

What Are Cart Fragments?

WooCommerce’s cart fragments feature keeps the mini-cart in your site’s header up to date without reloading the page. When a customer adds a product to their cart, the little cart icon in the header — the item count and the total — updates instantly.

To make that work, WooCommerce loads a script called wc-cart-fragments on every page. That script then fires an AJAX request to admin-ajax.php asking the server: “Has the cart changed? Send me the latest cart contents.” The server answers, and the header updates.

That is genuinely useful — on a shop page, where customers are actively adding things to their cart. The problem is that the script runs everywhere, whether the visitor is shopping or not. A reader landing on a blog post gets the same cart-fragment request as a customer on a product page, even though they will probably never open the cart at all.

One more detail matters: cart fragments are not cached. A caching plugin can serve a static page in milliseconds, but the cart-fragment request bypasses the page cache entirely because it goes through admin-ajax.php. Every visitor triggers a fresh, uncached PHP request — which is why this small script can matter more than its file size suggests.

Why Cart Fragments Slow Down Every Page

There are three costs, and they stack.

1. An extra request on every page

Each page load gains an additional HTTP request. On its own that is not dramatic, but it competes with everything else the browser is doing and it delays the moment the page is fully settled — especially on mobile connections.

2. An uncached server hit

This is the real cost. The admin-ajax.php request cannot be served from your page cache, so it hits PHP and the database on every visit. On shared hosting, where CPU and database connections are limited, a busy blog post or a traffic spike can turn hundreds of pointless cart checks into real server load. If you have ever investigated why admin-ajax.php is slowing down your site, cart fragments are often one of the top offenders on the list.

3. Delayed interactivity

The script itself is small, but it runs JavaScript, waits for a server response, and then updates the page. On slower devices that work competes with the rest of the page’s interactivity, which can nudge metrics like Interaction to Next Paint in the wrong direction. For stores chasing Core Web Vitals, removing work the page does not need is one of the cheapest wins available.

How to Tell If Cart Fragments Are Hurting Your Site

Before changing anything, confirm the problem exists on your site. It takes two minutes.

1. Open any page on your site in Chrome and press F12 to open DevTools.
2. Go to the Network tab and reload the page.
3. Filter by “admin-ajax” or look for a request to admin-ajax.php with the action get_refreshed_fragments.
4. Check how long it takes. On shared hosting, 300–800ms is common — and that time is added to every single page view.

If you see that request on a blog post or a page where no cart widget is even visible, you have found wasted work. You can also check your server logs or a plugin like Query Monitor to see how often admin-ajax.php is being hit overall. On a content-heavy store, cart fragments are frequently responsible for a large share of those requests.

One caveat: if your theme does not show a mini-cart anywhere, cart fragments are doing literally nothing useful for your visitors. That is the clearest possible case for disabling them outright.

Method 1: Disable Cart Fragments With Code

The cleanest way to disable cart fragments is a short snippet that stops WooCommerce from loading the script. Add it to your child theme’s functions.php file, or better, through a code snippets plugin (such as WPCode or Code Snippets) so a theme update cannot wipe it out. Never edit a parent theme’s functions.php directly — your change will vanish at the next update.

add_action( 'wp_enqueue_scripts', 'disable_woocommerce_cart_fragments', 11 );

function disable_woocommerce_cart_fragments() {
    wp_dequeue_script( 'wc-cart-fragments' );
}

The priority of 11 matters: WooCommerce enqueues the script at the default priority of 10, so your dequeue needs to run after it. Save the snippet, clear your cache, and reload a page. The get_refreshed_fragments request should be gone from the Network tab.

After disabling, test the site as a customer would: add a product to the cart from a product page, then visit the cart and checkout pages and confirm everything still works. The cart and checkout pages themselves do not depend on the fragments script — they load the cart contents directly — so they will keep working normally.

Method 2: Disable Cart Fragments With a Plugin

If you would rather not touch code, several performance plugins include a one-click toggle for this exact setting:

• Perfmatters — under Script Manager / WooCommerce settings, there is an option to disable cart fragments. Perfmatters is also useful for the broader job of controlling scripts per page, which is the theme of the middle-ground method below.
• WP Rocket — includes a WooCommerce optimization that can reduce cart-fragment behaviour, though it does not offer the same granular toggle as Perfmatters.
• Disable Cart Fragments — a small free plugin that does exactly this one job and nothing else. It is a good choice if you do not want to buy a larger performance plugin for a single setting.

Whichever route you choose, the result is the same: the script stops loading and the extra request disappears. Do not use both a code snippet and a plugin toggle at the same time — pick one method so you always know where the setting lives when you need to change it later.

What Breaks When You Disable Cart Fragments — and How to Handle It

Disabling cart fragments has one visible consequence: the mini-cart in the header no longer updates itself without a page reload. A customer who adds a product from a product page will not see the header cart count change until they navigate to another page or refresh.

Whether that matters depends on your store:

• If your theme has no visible mini-cart, nothing changes for visitors. Disable with confidence.
• If you use AJAX add-to-cart on product archives, customers may briefly think the add-to-cart button did nothing. Consider also turning off AJAX add-to-cart (WooCommerce → Settings → Products → “Enable AJAX add to cart buttons on archives”) so the button takes the customer to the cart page, where the cart contents are always correct.
• If the header mini-cart is central to your design, use the middle-ground method below instead of disabling fragments everywhere.

One thing that does not break: the cart page, the checkout page, and order processing. Those pages do not rely on the fragments script, so disabling it is safe for actual purchasing. This is also why a slow WooCommerce checkout is almost never caused by cart fragments — checkout slowness usually comes from elsewhere, and that guide covers the real culprits.

The Middle Ground: Load Cart Fragments Only Where They Matter

For many stores, the best answer is not all-or-nothing. You can keep cart fragments on the pages where customers actually shop — the shop page, product pages, cart, and checkout — and remove them everywhere else, such as blog posts, landing pages, and informational pages that never show a cart.

This snippet does exactly that. It dequeues the script on every page except the WooCommerce pages where the mini-cart matters:

add_action( 'wp_enqueue_scripts', 'limit_woocommerce_cart_fragments', 11 );

function limit_woocommerce_cart_fragments() {
    if ( is_cart() || is_checkout() || is_shop() || is_product() ) {
        return;
    }
    wp_dequeue_script( 'wc-cart-fragments' );
}

This is the option I recommend for most established stores. You keep the smooth mini-cart experience where it counts, and you stop paying the server cost on the large share of pages where visitors are reading, not buying. If your store also publishes a lot of content, this pairs well with the other WooCommerce product-page optimizations — gallery image fixes, related-product trimming, and correct caching exclusions — that together make the whole shop feel faster.

Verify the Fix

After making the change, verify it properly rather than assuming it worked:

1. Clear all caches — your caching plugin, any server cache, and your CDN cache if you use one. Otherwise you may be testing a stale page.
2. Reload a blog post or landing page in DevTools and confirm the get_refreshed_fragments request is gone.
3. Test the full purchase flow — add a product, view the cart, and complete a test checkout. Confirm the cart count and totals are correct on the cart and checkout pages.
4. Re-run your speed test on a page that previously triggered the request. The improvement may be modest in a lab score, but the server-side saving is real: every visitor who no longer triggers an uncached request frees capacity for visitors who do need one.
5. Watch for a week. If any plugin or theme feature relied on the fragments script in an unexpected way — a floating cart widget, for example — it will show up quickly, and you can switch to the middle-ground method instead.

Common Mistakes

• Editing the parent theme’s functions.php. Use a child theme or a snippets plugin, or the change disappears at the next theme update.
• Forgetting to clear caches. A cached page can keep serving the old script for hours, making it look like the fix failed.
• Disabling fragments and then wondering why the mini-cart count is stale. That is the expected trade-off. If the stale count bothers your customers, use the conditional method instead.
• Chasing this fix while ignoring bigger problems. Cart fragments are a real cost, but if your site is slow because of unoptimized images, a bloated page builder, or slow hosting, fix those first — they will move the needle far more.
• Disabling fragments on a store that depends on them. If your checkout flow or a third-party cart widget updates via fragments, test thoroughly before deploying to a live store. A staging site exists for exactly this reason.

The Bottom Line

Cart fragments are a small feature with an outsized footprint: an uncached server request on every page of your site, including pages where no cart is ever shown. For stores without a visible mini-cart, disabling them is a free win. For stores that do show a mini-cart, loading them only on shop pages is the sensible compromise.

Either way, the work takes ten minutes and the saving repeats on every page view, forever. It may not transform a single speed score, but it quietly makes a store cheaper to run and faster to browse — and on a busy store, that quiet saving is worth more than a flashy one.