Page speed rescue · WooCommerce
Same shop. Same server. 71 → 100 on PageSpeed.
Two live builds of one shop. Identical products, prices, photos and layout. The left one is a normal WooCommerce site: page builder, sixteen plugins, images straight from the camera. The right one is the same shop rebuilt.
At 10,000 visits a month, that speed gap is worth about 40 extra orders — roughly $2,480.
Model, not a promise. Coefficient and sources are below.
Drag it. Both sides are live.
Not screenshots. Two real sites loading in your browser, right now, over your connection.
Timings above are measured in your browser, not taken from our database. Reload the page and they will differ — that is what real traffic looks like.
The numbers, re-measured every six hours
Lighthouse, mobile preset: Slow 4G, 4× CPU throttling. Three runs, median. Last run: 4 August 2026 at 09:50 UTC.
| Metric | Before | After | Change |
|---|---|---|---|
| … | |||
INP is missing on purpose: it is a field metric and needs real traffic. A demo shop has none. TBT is its lab stand-in and it is in the table.
Do not take our word for it. Run Google's own PageSpeed Insights on both:
What the slow version costs
Speed is not a vanity metric — it is orders. Change the numbers to yours.
Where the coefficient comes from
We use the relationship Google published from its own retail data: each extra second of load time costs about 7% of conversions, and mobile sites loading in 1s convert roughly 2.5× better than those loading in 5s. Our two builds differ by 3.1s of LCP, which linearly would mean far more than we are willing to claim. That relationship was measured on differences of tenths of a second, not seconds, so we cap the model at 22% and treat anything above that as unknown. Even capped, this is an estimate for one shop, not a law of nature — your catalogue, traffic mix and checkout matter more than any coefficient.
Sources: Google/SOASTA «The State of Online Retail Performance» (2017); Google «Milliseconds make millions» (Deloitte, 2020); web.dev Core Web Vitals business case studies.
Every step, measured
We did not optimise and then guess what helped. The fast build can switch each optimisation off, so every line below is a real measurement of this page with and without that one thing.
| Step | What was done | Score | Gain |
|---|---|---|---|
| … | |||
Steps are cumulative: each row keeps everything above it. Gain is the difference from the previous row, in Lighthouse points, mobile.
How it was done
In one sentence
We kept the shop and threw away the scaffolding: the page builder that shipped 46 stylesheets to draw nine product cards was replaced by hand-written markup, and the server now hands out a finished page instead of rebuilding it for every visitor.
The old page was a flat-pack wardrobe delivered as parts, with the instructions in the last box. The new one arrives assembled.
For the technical reader
What we did not do
Both stands run on the same server, same PHP 8.3, same FPM pool settings, same TLS and HTTP/2, same OPcache. We did not move the fast one to better hosting — that would make the comparison worthless. We also left analytics and ad pixels off both sides: we do not track demo visitors. On a real client site those usually cost another 5–10 points, so the gap you see here is the conservative one.
The slow build is not sabotage. It is WordPress 7.0.2 with WooCommerce, a page builder and sixteen plugins that a real shop accumulates in a couple of years, on a server that is faster than most shared hosting. On typical shared hosting the same build scores lower still.
Same page — checked, not claimed
The whole case rests on the two pages being the same page. So we check it with a machine: both stands are screenshotted at 360, 768, 1024 and 1440 px and compared pixel by pixel.