Why a store is mostly a WordPress site with products
The usual suspicion is that WooCommerce itself is the heavy part. On the homepages we read, it
isn’t. WooCommerce’s own scripts and styles were a median of 0.3% of the page’s bytes, and
none of its core scripts loaded synchronously in the head on any of the 106 stores we checked.
Scores told the same story: a store homepage scored about the same as a plain WordPress
homepage built the same way (57 against 59, within the noise). The numbers are in
our study of 107 stores.
What does differ is jQuery. On 74% of those store homepages it loaded synchronously in the
head, against about a third of plain WordPress sites, and every plugin and tag written to
expect it waits behind it. That is where the parser-blocking card above mostly comes from.
The other difference is what the first screen is made of. A blog’s hero is an <img>; a
store’s is often a category banner set as a CSS background, which the browser cannot see
until the stylesheet has arrived and been applied. On 76% of the stores we audited, that
image was still waiting on the CSS chain when it should have been the first thing fetched.
Being straight about the range
We publish the misses along with the hits, so here is the honest range for a store.
Across 100 WooCommerce stores with a clean measurement (as of September 2026), the mobile
score went up without costing more than two points on desktop on 51% of them, and went
down on 30%. The median mobile gain was 2 points. That is modest, and smaller than the
cards above might suggest. The reason is in a larger study we ran across
381 sites: what the score gains depends far more on
where it started than on the platform. Sites starting in the 30s and 40s gained a median of
11 points. Sites already above 70 were a coin flip.
There is a second number worth knowing before you buy anything. Visible loading speed —
Speed Index, how fast the page fills in — improved on nearly three quarters of the 381 sites,
and it often improves on the same sites where the score barely moves. If your problem is that
customers see a blank screen for two seconds, that is the number to watch. If your problem is
a report with a red circle in it, the score is, and the two do not always agree.
What we cannot fix from the outside
Three things, plainly.
Server response time on an under-resourced host. We can serve a cached copy of a
catalogue page quickly, but a checkout that takes two seconds to compute takes two seconds.
That is a hosting or a database conversation.
Requests you want made. The stores in our sample load from a median of
12 hosts they don’t own, and every one of them was
added deliberately. We defer third-party scripts until the page is usable, which stops them
competing with your catalogue. We do not remove them, because that is your marketing team’s
call and not ours.
A theme that fights the fix. A minority of themes render the first screen with JavaScript
after load. On those, deferring anything moves the problem rather than solving it, and we
switch the optimization off for the domain rather than pretend otherwise.
What the audit gives you
The free audit measures your store twice — as it is now, and served through WebSpeed — on
both mobile and desktop, and lists every change that was applied to get the second number. It
takes a few minutes and needs nothing from you but the address. If the answer is that your
store does not have much to gain, the report will say that too.