What loads on a page with nothing to sell
Of the 106 WooCommerce store homepages in our audit base whose markup we could read (measured 18–29 September 2026), 64 showed no product listing at all: no grid, no price, no add-to-cart button. They are the pages this fix is aimed at. We left out the ones that combine their files with a caching plugin, because a combined file doesn’t say whose code is inside it, which left 47.
| On homepages with nothing to sell | Result |
|---|---|
| Load WooCommerce core files anyway | 33 of 47 (70%) |
| How much, median | 10 requests, 34 KB |
| Share of the page | 0.8% of bytes, 7% of requests |
| Load a WooCommerce stylesheet in the head | 26 of 64 (41%) |
So the advice is right that WooCommerce shows up where it has no job. It is wrong about the size. On a typical page 34 KB sits next to about three megabytes of everything else, and in our wider study of 107 stores WooCommerce’s own files came to a median of 0.3% of the homepage.
Check your own page
Before you install anything, see what your page actually loads. This lists every file served from the WooCommerce plugin directory:
curl -s https://yoursite.com/ | grep -o 'plugins/woocommerce/[^"?]*' | sort -u
An empty result means there is nothing to remove, or that a caching plugin has
combined the files. In the second case, turn combining off for a moment, or open
the page in Chrome DevTools, go to the Network tab and type
woocommerce into the filter box.
Scripts in that list are rarely the problem. On the stores we read, every one of
WooCommerce’s core scripts in the head carried defer, so they
download without stopping the browser. The part that does stop it is the next
check.
The part worth removing: stylesheets
A stylesheet in the head blocks the first paint until it has downloaded, whatever is inside it. This lists WooCommerce’s:
curl -s https://yoursite.com/ | grep -o '<link[^>]*woocommerce[^>]*>'
On the 26 homepages where we found them, they came to a median of 19 KB. The files
were the three WooCommerce ships by default (woocommerce-layout,
woocommerce-smallscreen and the general woocommerce.css,
about 18–19 KB each where present) and the blocks stylesheet at about 11 KB.
WooCommerce documents a filter,
woocommerce_enqueue_styles,
that controls its three default stylesheets. Returning an empty list everywhere
would unstyle the shop too, so keep them on the pages that need them:
// Child theme functions.php, or a code snippets plugin
add_filter( 'woocommerce_enqueue_styles', function ( $styles ) {
if ( is_woocommerce() || is_cart() || is_checkout() || is_account_page() ) {
return $styles;
}
return array();
} );
The blocks stylesheet is not covered by that filter. It is registered like any
other WordPress style, and its handle is in the page source: the
id of the <link> tag is the handle followed by
-css. Dequeue it by that handle in the same conditional.
One condition before you do this: if your homepage uses a WooCommerce block or shortcode (a product carousel, a featured product), it needs those styles, and the check in the first section will have shown product markup. Our 64 pages were chosen because they had none.
Cart fragments
Cart fragments is the script that asks the server for a fresh copy of the cart after the page loads, so a mini cart in the header shows the right count. It has a reputation as the heaviest thing WooCommerce does on every page.
That reputation is older than the current behaviour. Since WooCommerce 7.8 the script is, in the words of the release notes, “only enqueued if using the Mini Cart widget”. In our base it turned up on 21 of 107 store homepages (20%), and those homepages did not score worse than the rest: a median of 66 against 57.5, a gap in their favour and within the noise.
If you see it and your header shows a cart count, it is doing its job. Removing it leaves visitors looking at a stale cart. We can’t tell you what it costs in milliseconds from our data, and we have not seen it make a homepage measurably slower.
Order attribution
On 28 of the 64 homepages, WooCommerce loaded two small scripts for order
attribution, sourcebuster and order-attribution.js.
They record which channel or campaign a visitor came from, so the order screen can
say where each sale originated. They load on every page because a visit can start
on any page.
Stripping them saves a few kilobytes and loses that report. We would not trade one for the other for speed.
What it is worth
- Conditional stylesheets are the one change with a mechanism behind it. They sit in the path to the first paint, and nothing else WooCommerce loads on these pages does.
- Everything else is housekeeping. Deferred scripts at under one percent of the page won’t move the score, and a plugin that strips them all can remove the two you wanted.
- The weight is elsewhere. Across the store homepages in our study, third-party scripts made up 70% of the JavaScript, and a synchronous jQuery in the head held up the parser on most stores. Those are the places a slow store homepage loses its time.
- Measure before and after, three runs each. A change this small can land inside the run-to-run noise, see how to run the test.