A speed test of your shop lists a request you never asked for: ?wc-ajax=get_refreshed_fragments. It is not cached, it sometimes takes longer than the page itself, and a speed plugin offers a checkbox to switch it off. Before ticking that box, it is worth understanding what WooCommerce cart fragments are doing, because the request exists to fix a real problem that caching creates.
Below is what the request does, when it fires, how to tell whether it matters on your store, and the options for limiting it, from the gentlest to the most drastic. Which store pages must be kept out of the cache altogether is a separate question, answered in the post on cache exclusions for cart and checkout.
The problem cart fragments solve
Most store themes show a small cart in the header: an icon with a count, sometimes a total, sometimes a drop-down mini-cart listing the items. That header is part of the page’s HTML.
Now add a page cache. A product page is saved once and served to everyone, including the header. If the saved copy was made when the cart was empty, every visitor sees an empty cart icon, including the shopper who has just added three items. The page is fast and the cart count is wrong.
Cart fragments are WooCommerce’s fix. After the cached page arrives, a small script asks the server for the current shopper’s real cart snippets, then swaps them into the page. The header ends up correct for each shopper, even though the rest of the page came from the cache.
What the request actually does
The script behind it is called wc-cart-fragments. In general terms, it works like this:
- When the page loads, the script looks in the browser’s session storage for cart snippets it saved earlier, along with a fingerprint of the cart called the cart hash.
- It compares that stored hash with the one in the shopper’s WooCommerce cookie.
- If they match and the stored copy is recent, it simply reuses the saved snippets. No request is made.
- If nothing is stored, the hash has changed, or the copy is considered too old, it sends a request to
?wc-ajax=get_refreshed_fragments. - The server loads WordPress, WooCommerce and your plugins, reads the shopper’s session, builds the mini-cart and any other registered snippets, and returns them with the new cart hash.
- The script replaces the matching parts of the page and stores the new copy for next time.
Plugins and themes can register their own fragments, for example a wishlist count or a free-shipping progress bar, so the response can contain more than the mini-cart.
When it fires
- On a shopper’s first page in a browsing session, when nothing is stored yet.
- After the cart changes, because the hash no longer matches.
- When the stored copy expires.
- When another tab changes the cart, so tabs stay in step.
Adding to cart through AJAX on a category page usually returns updated fragments in the add-to-cart response itself, so a separate refresh is not always needed after that.
Where it loads
In older versions of WooCommerce, the script loaded on every page of the site, which is where its bad reputation comes from: blog posts and contact pages were firing cart requests for visitors who had never touched the shop. Recent versions no longer load it everywhere by default. It loads where something asks for it, such as the classic cart widget or a theme’s header mini-cart, and many themes still ask for it on every page. The block-based Mini-Cart in newer block themes takes a different route, using WooCommerce’s Store API rather than this script.
Is it actually slowing your store?
The request is uncached by design. How much it costs depends on how quickly your server builds an uncached WooCommerce request, and how many visitors trigger it.
Check three things:
- Does it fire, and where? Use a private window with developer tools open (F12 in most desktop browsers), switch to Network and type
wc-ajaxinto the filter box. Load the home page, a blog post, a product page. Note which pages sendget_refreshed_fragments. - How long does it take? Click the request and look at the timing. A quick response is harmless. One that takes a long time means every uncached WooCommerce request on your server is slow, and the fragments are just where it shows.
- How many hit the server? In your access logs or host statistics, count requests containing
get_refreshed_fragmentsin a day. On small hosting, a high count competes with real shoppers for the same limited processes.
Remember that the request does not block the page from appearing. It runs after the page loads. A speed score may still count it, and it adds server load, but it is rarely why a page looks slow to a visitor. If the response itself is slow, the real fix is making uncached store requests faster, which is the subject of our guide to priorities for a slow WooCommerce store.
Options, from gentle to drastic
1. Leave it alone
If the request is fast and only fires on shop pages, there is nothing to fix. Many stores are in this position after recent WooCommerce changes.
2. Stop it on pages that do not need it
If your theme loads the script site-wide, you can stop it on pages with no cart display, or where a stale count does not matter, such as blog posts. Performance plugins such as Perfmatters include an option for this, and some themes have their own setting. In code, it means dequeuing the wc-cart-fragments script on the pages you choose, after WooCommerce has queued it. Keep it on product, category, cart and checkout pages.
3. Change the header so it does not need live data
A header cart icon that links to the cart page, with no count and no drop-down, does not need fragments at all. The shopper sees the correct cart as soon as they open the cart page, which is never cached. For some stores this is a perfectly good trade; for others, especially where customers add several items before checking out, the visible count reassures shoppers that the click worked.
4. Switch it off entirely
This removes the request everywhere. On a cached site with a header count, the count will be wrong for many shoppers until they reach the cart page. Some themes also stop updating the mini-cart after add-to-cart. Only choose this if you have tested what your theme shows without it and you are content with that.
Whichever you choose, change one thing at a time and keep a note, so you can reverse it if customers report odd cart behaviour.
Testing cart behaviour after a change
Cart problems often reach you as lost sales rather than complaints, so test like a customer before you call the change done. In a private window, logged out:
- Add a product from its product page and check the header count and mini-cart.
- Add another from a category page using the archive add-to-cart button.
- Open a second tab, remove an item there, and switch back to the first tab.
- Visit a blog post or content page and check what the header shows.
- Go through to the cart page and checkout and confirm the totals.
- Repeat on a phone and while logged in as a customer.
If the header disagrees with the cart page, that is the trade-off showing. Decide whether it is acceptable or roll back. If the cart page itself shows wrong or empty contents, the cause is usually caching rather than fragments; our post on a WooCommerce cart that keeps emptying works through that.
A note on wc-ajax and admin-ajax
WooCommerce uses its own endpoint, wc-ajax, for front-end store requests like this one, rather than WordPress’s admin-ajax.php. If your logs show many admin-ajax requests on a store, they come from something else; our guide to finding what calls admin-ajax on the front end shows how to trace them.
Cart fragments are one small example of a wider point in the section guide on why some plugins weigh more than others: a feature can be light in the browser and still add uncached work on the server. For how that background work fits with caching, page weight and scripts, see our website loading speed guide.
Frequently asked questions
Is it safe to disable WooCommerce cart fragments?
It can be, depending on your theme and caching. Without fragments, a cached page’s header cart count may be wrong until the shopper reaches the cart page, and some mini-carts stop updating after add-to-cart. Test the full add, remove and checkout flow on your own theme before deciding, and consider stopping it only on pages without a cart display.
Why does get_refreshed_fragments fire when the cart is empty?
The script has no way to know the cart is empty until it checks. On a shopper’s first page, nothing is stored in the browser yet, so it asks the server once and saves the answer. After that, it normally reuses the stored copy until the cart changes or the copy expires. Older WooCommerce versions loaded it on far more pages, which made this more noticeable.
Can a caching plugin cache the fragments request?
It should not cache it in the ordinary way, because the response is personal to each shopper and a cached copy would show one person’s cart to another. Some optimisation tools handle the empty-cart case specially, but treat any such feature with care and test with several browsers and carts before trusting it.
Does a block theme mini-cart use cart fragments?
The block-based Mini-Cart takes a different route, fetching cart data through WooCommerce’s Store API rather than the classic fragments script. It still makes a background request, but it is a different one. If your theme mixes block and classic parts, check the Network tab to see which requests your header actually sends.
A slow fragments request is usually a sign that every uncached store request is slow. Finding out why is the job of an audit, and our WooCommerce speed work begins with one, followed by a prioritised fix list you approve before anything changes.
Next in this series: WooCommerce Checkout Slow? Find the Slow Step
