The suspicion, and why the homepage is a fair place to test it
“WooCommerce makes WordPress slow” is repeated often enough to sound measured. It usually comes with a plugin recommendation that strips WooCommerce’s scripts and styles from every page that isn’t the shop.
A homepage is where that claim is easiest to test. It is the page most stores send their traffic to, it is the page our audits measure, and a plain WordPress site has one too. If the plugin carries a cost on every page, it should show up there.
We had 107 WooCommerce homepages and 108 plain WordPress homepages, all measured between 18 and 29 September 2026. We looked at three things: how much of the page belongs to WooCommerce, whether the stores score worse, and what in the head blocks the browser.
How much of the page is WooCommerce
Very little. On the 75 stores whose files we could attribute:
| Share of the homepage that is WooCommerce core | Median |
|---|---|
| Bytes | 0.3% |
| Requests | 4% |
| JavaScript bytes | 0.8% |
For scale, third-party scripts (analytics, pixels, chat, reviews, payment badges) made up 70% of the JavaScript bytes on the same pages. The store’s own plugin is a rounding error next to what it has been asked to carry.
The scripts are also out of the way. Across 106 store homepages whose head we could read,
none loaded a WooCommerce core script that blocks the parser. All 181 core script tags in
those heads carried defer. That is not an accident of our sample: WooCommerce moved its
front-end scripts to the loading strategy WordPress 6.3 added to its script API, which lets a
plugin put a script in the head “with the defer attribute which will enable earlier discovery
while still remaining non-blocking”, in
the words of the change request.
Store against site, with the builder held fixed
A store built with Elementor is not comparable to a hand-coded blog, so we compared like with like. Median mobile score of the original page:
| Builder | Stores | Median | Plain sites | Median |
|---|---|---|---|---|
| None | 66 | 57 | 106 | 59 |
| Elementor | 27 | 65 | 363 | 61 |
| Divi | 14 | 65.5 | 39 | 60 |
Without a builder the stores come out two points lower; with either builder they come out higher. Neither direction survives a closer look. The no-builder gap was −6, −4 and −2 points in three consecutive windows and significant in none of them, and on desktop it changed sign. Page weight and request count, the usual suspects, were identical: 3.0 MB and a median of 98.5 requests in both groups.
A two-point gap is also smaller than the instrument. Three runs of the same page in one sitting differ by a median of 9 points when they differ at all, so “57 against 59” is the same number measured twice.
What does differ: jQuery in the head
One thing separates the stores clearly, and it is not WooCommerce’s own code.
| Loads jQuery synchronously in the head | Share |
|---|---|
| Stores, no builder (49 of 65) | 75% |
| Plain WordPress sites (38 of 106) | 35% |
The gap is large (z = 5.0), and almost all of it is the copy of jQuery that ships with WordPress itself, about 36 KB. Across all 106 store heads, the scripts that block the parser were jQuery on 74% of stores, other plugins on 35%, third-party tags on 28%, and WooCommerce extensions on only 8%.
The likely reason is compatibility. A script that calls jQuery the moment it runs breaks if jQuery has been deferred, and a store tends to collect more of those (sliders, filters, review widgets, older payment plugins) than a brochure site. So the theme or a plugin keeps jQuery synchronous to be safe, and everything written against it waits in line.
We expected this to cost points. Inside the store group it doesn’t show: homepages with synchronous jQuery scored a median of 55 against 57.5 without it, a gap well inside the noise. We can say that stores carry it twice as often. We cannot say what it costs them.
What this means for a slow store
If your store’s homepage is slow, WooCommerce core is the least likely explanation on it. On the pages we measured it is a fraction of a percent of the bytes and none of the blocking. Stripping its assets from the homepage takes away very little; we measured how little, file by file, in a separate guide.
The weight is in what surrounds it: third-party scripts at 70% of the JavaScript, and a synchronous jQuery that the rest of the head depends on. Those are the places to look, and the first one is also the one a WooCommerce setting cannot reach.
What we have not measured is the rest of the store. Product pages, the cart and checkout load far more of WooCommerce than a homepage does, and our audits don’t reach them yet. That is where the question is still open.
Method and limits
Every completed audit that passed our measurement gate (finished, no failed run, the accelerated copy rendered faithfully, no redirect leak), latest measurement per host, all taken 18–29 September 2026: 107 homepages our detector named WooCommerce and 108 it named plain WordPress, plus 363 Elementor and 39 Divi sites without a store for the builder comparison. Bytes and requests come from the Lighthouse network log of the original page, not the accelerated one; a file counts as WooCommerce core when it is served from the plugin's own directory. Parser blocking is read from the stored HTML: a script with a `src` in the head and no `async`, `defer` or `type="module"`. Scores are compared by median with the page builder held fixed. The no-builder comparison was repeated on earlier measurements of the same sites kept in our archive, in three windows (August, 1–15 September, 16–29 September).
Measured on 29 Sept 2026 across 617 sites. These figures are frozen at that date — we don't quietly restate a published study when the audit base grows.
What this doesn't show
- Homepages only. Our audits measure the page an owner submits, which is almost always the front page, so product pages, the cart and checkout were not measured at all. Those are where WooCommerce loads most of its own code, and nothing here says how heavy they are.
- "WooCommerce" means the plugin is installed. The group includes publishers and service businesses with a small shop on the side, not only dedicated stores.
- 29 of the 107 stores combine their scripts and styles with a caching plugin, which hides whose file is whose. They are left out of the byte shares, as are three whose network log was cut short, so those shares describe 75 stores.
- Three lab runs of the same page in one sitting differ by a median of 9 points when they differ at all. A two-point gap between two groups of this size is inside that noise, which is why we say "indistinguishable" and not "slightly slower".
- The jQuery difference is a description, not a price. Inside the store group, homepages that load jQuery synchronously did not score worse than the ones that don't, so we cannot say what it costs.
- Not a random sample of the web: these are sites that were submitted to us or reached us through our own discovery feed.
Sources
- Eliminate render-blocking resources — Chrome for Developers
A <script> tag that: Is in the <head> of the document. Does not have a defer attribute. Does not have an async attribute.
- [Enhancement]: Leverage new Script API strategy feature to defer front end scripts (#40685) — WooCommerce on GitHub
WordPress introduced a new strategy feature in the Script API in version 6.3. See this post for more details. The plugin can leverage this feature to enqueue scripts in the header with the defer attribute which will enable earlier discovery while still remaining non-blocking.
- wp_enqueue_script() — WordPress Developer Resources
The $in_footer parameter of type boolean was overloaded to be an $args parameter of type array.