Above 70, speeding up a site is a coin flip

The average is true and useless

Two thirds of the sites we put through the proxy scored higher on mobile. That is the number a vendor prints, and on its own it earns nothing: it hides both what happened to the other third and how much anyone gained.

Change in mobile score	Sites	Share
Higher	254	67%
Lower	106	28%
Unchanged	21	6%

The distribution behind it is wide. The 10th percentile of the change is −8 points and the 90th is +25, with the median at +4. A stricter reading — mobile up and desktop not down by more than two points, which is the test we use before a result may appear on this site — leaves 230 of 379, or 61%.

The starting score decides almost everything

Split the same 381 sites by the score they had before we touched them and the blur resolves:

Original mobile score	Sites	Improved	Regressed	Median change
0–29	11	73%	18%	+9
30–49	97	79%	20%	+11
50–69	174	73%	22%	+5
70–89	71	49%	46%	0
90–100	28	25%	46%	0

Below 50, the service does what it says on almost four sites in five, and the typical gain is large enough to survive the measurement noise several times over. Between 50 and 69 it still works, at half the size. Above 70 it is a coin flip, and above 90 the likelier single outcome is a small loss.

Nothing about the software changes across those rows. The same thirty-odd optimizations run in the same order. What changes is how much was left to fix — and on a site that already inlines its critical CSS, prioritises its hero image and defers its analytics, a generic optimizer arrives with nothing to do and a small amount of overhead to add.

The sites that lost points weren’t the broken ones

The 106 regressions are not a set of catastrophes. Their median loss is 5 points — inside the range a repeat measurement produces on its own — and only 13 sites lost 20 or more.

What separates them is where they started. The median regressing site began at 67; the median improving site began at 56. The losses come from the top of the sample, not the bottom, which is the same finding as the table above arriving from a different direction.

That is also the reason we publish this. A speed service that reports averages will happily sell to the site sitting at 78, because the average says two thirds of customers improve. Our own measurements say that site has even odds, and the honest recommendation for it is a tuned profile or nothing at all.

Score is not the only axis

One number moved much more consistently than the score did. Speed Index — how quickly the visible area of the page fills in — was faster through the proxy on 73% of sites, with a median ratio of 1.22×.

The two disagree because the score is a weighted average of several metrics, and a page can paint visibly sooner while a single component of the score, most often layout stability or total blocking time, moves the other way and cancels it out. Neither number is the truth on its own. If what you care about is when the visitor sees the page, the Speed Index figure is the relevant one; if what you care about is the number in the report your client will run, the score is.

Platform is a weaker signal than starting score

Platform	Sites	Improved	Regressed	Median change
Bitrix	22	82%	18%	+9
Duda	47	79%	19%	+9
WooCommerce	44	73%	25%	+3
Tilda	33	70%	27%	+8
Squarespace	29	69%	21%	+3
Wix	29	66%	31%	+5
Webflow	26	65%	27%	+4
Elementor	30	60%	30%	+2
WordPress	51	55%	39%	+3
Next.js	22	50%	50%	−1

The spread here is narrower than the spread by starting score, and each group carries its own selection story: our Duda sites came from one batch of small local businesses, our Next.js sites are developer-facing products that render their first screen in the browser. We would not defend a single row of this table as a fact about the platform. It is here because leaving it out, having run it, would be choosing which of our own results to show.

What we do with this internally

Three things, and none of them is a talking point.

Sites arriving above 70 get told the honest range before anything is measured. A page in the 90s does not need us and we would rather say so than sell it a coin flip.

Regressions get read as bugs first. Several of the 106 above turned out to be defects in our own filters rather than facts about the sites — that is how we found a minifier that was truncating a runtime and a filter that was moving scripts a site’s own optimizer had already scheduled. Both had been quietly inflating scores elsewhere by preventing code from running at all, which is the failure mode this whole line of measurement exists to catch.

And the 30–49 band is where the service is actually worth buying. That is not the segment with the best story, but it is the one where the median outcome is eleven points and the downside is a rounding error.