Eliminating WooCommerce wc-ajax=get_refreshed_fragments Performance Drag Without Breaking Cart Badges

If you inspect the network waterfall of almost any standard WooCommerce store in Chrome DevTools, you will notice an infuriating request appearing on every single page load:

POST /?wc-ajax=get_refreshed_fragments
Status: 200 OK
Time: 650ms – 1,800ms

Whether a visitor is browsing a blog post, inspecting an FAQ page, or reading your return policy, WooCommerce insists on bootstrapping the entire WordPress core, querying database sessions, and returning an uncached JSON response just to verify if an item is sitting in their shopping basket.

For stores with moderate to high traffic, this single legacy script creates massive server load, wastes bandwidth, and sabotages Time to First Byte (TTFB) and mobile Interaction to Next Paint (INP).

This runbook demonstrates how to eradicate this script safely without breaking cart counters or live checkout interactions.

---

The Battlefield Scenario

A client operating a busy WooCommerce store with 1,200 products noticed their server load averages were constantly elevated ($>4.00$ on a 4-core VPS), even though they had PageSpeed caching and Cloudflare configured.

Running a performance trace in Chrome DevTools revealed:

• Main document HTML delivered in 120ms (cached).
• 0.8 seconds later, ?wc-ajax=get_refreshed_fragments fires.
• The request takes 1,240ms to return because it completely bypasses page caching and executes a full PHP-FPM bootstrap.
• The browser main thread stutters, delaying mobile user interactions.

# Simulating the raw fragment request from terminal
$ curl -s -X POST "https://client-store.co.uk/?wc-ajax=get_refreshed_fragments" \
  -H "X-Requested-With: XMLHttpRequest" \
  -w "HTTP: %{http_code} | Total Time: %{time_total}s\n" -o /dev/null

HTTP: 200 | Total Time: 1.182s

On a store receiving 10,000 daily pageviews, this means your origin server is forced to process 10,000 uncacheable dynamic PHP requests every single day just to display a shopping cart count of 0!

---

Phase 1: Why WooCommerce Does This

WooCommerce introduced cart-fragments.js to solve a fundamental caching problem: When you use a full-page cache (LiteSpeed, Varnish, Nginx FastCGI, or WP Rocket), the server saves a static HTML copy of your header. If a customer adds an item to their cart, a cached header would still display “Cart: (0 items)”.

To work around this, WooCommerce executes an AJAX call after the page loads to update the mini-cart HTML snippet client-side.

The architectural blunder: WooCommerce loads and executes this script unconditionally on every single page, even for visitors who have never added a single item to their cart!

---

Phase 2: The Surgical PHP Snippet

We do not want to break the mini-cart for shoppers who actually have items in their basket.

The optimal engineering solution is to:

1. Deregister cart-fragments.js by default on all non-cart/checkout pages for empty carts.
2. Re-enable it dynamically only when an item is actually added to the cart or when a cart session cookie exists.

Add this surgical filter to your child theme’s functions.php or via a lightweight mu-plugin (/wp-content/mu-plugins/disable-cart-fragments.php):

<?php
/**
 * Plugin Name: Surgical WooCommerce Cart Fragment Disabler
 * Description: Prevents wc-ajax=get_refreshed_fragments from firing on empty cart sessions.
 */

if (!defined('ABSPATH')) exit;

add_action('wp_enqueue_scripts', function () {
    // Never disable on cart or checkout pages
    if (is_cart() || is_checkout()) {
        return;
    }

    // Check if WooCommerce session cookie exists and has items
    $has_cart_items = false;
    if (isset($_COOKIE['woocommerce_items_in_cart']) && (int)$_COOKIE['woocommerce_items_in_cart'] > 0) {
        $has_cart_items = true;
    }

    // If the cart is empty, dequeue the heavy fragment script completely
    if (!$has_cart_items) {
        wp_dequeue_script('wc-cart-fragments');
    }
}, 99);

---

Phase 3: Modern Client-Side JavaScript Handling (Zero-AJAX)

For modern WooCommerce stores, you can take this a step further by updating the cart counter purely client-side via native sessionStorage or localStorage.

When a visitor clicks “Add to Cart” on an archive or product page, WooCommerce triggers the added_to_cart jQuery event. You can listen to this event directly and update your cart count without ever calling ?wc-ajax=get_refreshed_fragments:

// Minimal Vanilla JS snippet added to theme footer
document.addEventListener('DOMContentLoaded', function () {
    // Listen for WooCommerce AJAX add-to-cart events
    if (window.jQuery) {
        window.jQuery(document.body).on('added_to_cart', function (event, fragments, cart_hash) {
            // Save updated state to browser storage
            if (fragments && fragments['div.widget_shopping_cart_content']) {
                sessionStorage.setItem('wc_fragments', JSON.stringify(fragments));
            }
        });
    }

    // Restore cached fragment on page load without any network requests
    const cachedFragments = sessionStorage.getItem('wc_fragments');
    if (cachedFragments) {
        const parsed = JSON.parse(cachedFragments);
        Object.keys(parsed).forEach(function (selector) {
            const el = document.querySelector(selector);
            if (el) el.outerHTML = parsed[selector];
        });
    }
});

---

Phase 4: Verification & Performance Impact

After deploying this configuration:

1. Clear all caches: Purge your server micro-cache, CDN, and object cache.
2. Open an Incognito browser tab: Navigate to a category or product page.
3. Inspect the Network tab:
   • Filter by wc-ajax.
   • Confirm that zero requests are made to ?wc-ajax=get_refreshed_fragments.
4. Test an actual purchase:
   • Add a product to the cart.
   • Notice that the cart badge updates instantly.
   • Proceed to /checkout/ and verify that the checkout flow functions with zero issues.

The Real-World Result

• Server CPU utilization: Dropped by 45% under load.
• Network payload: Eliminated 1 dynamic HTTP request per pageview across 90% of all sessions.
• PageSpeed INP / TBT: Reduced main-thread blocking time by 300ms–800ms on mobile devices.

---

🔗 Interconnected Engineering Triages & Architecture Mesh:

Infrastructure bottlenecks are rarely isolated. Upstream server performance, database query patterns, and DOM execution are tightly interlocked:

• Reducing DOM Tree Size Below 800 Nodes: Prevent mobile viewport rendering stalls and main-thread blocking.
• Mitigating Interaction to Next Paint (INP) Delays from GTM: Audit heavy tracking payloads blocking main-thread responsiveness.
• Fixing Canonical Traps on Paginated Product Archives: Protect crawl budget and prevent duplicate content dilution.