What a 1-second page speed improvement actually does to your conversion rate
Share
Abstract
"Faster sites convert better" is the archetypal platitude-true and almost useless. The number that matters is not your raw speed score but where the second comes from; a second saved on the product image carousel vs. one saved on the time-to-first-byte do very different things to revenue. This is what a one-second improvement is actually worth, and how to find exactly which second is the one worth chasing.
Hypothesis
Page speed work fails not because the advice is wrong, but because stores optimise the second that's easiest to find rather than the second the customer actually experiences. A store can improve its score meaningfully and see no change in conversion at all — and that outcome is common enough to have soured a lot of owners on the whole exercise.
Required Lab Equipment
- Google PageSpeed Insights, for the lab score and, more importantly, the field data underneath it
- Search Console's Core Web Vitals report: real visitors, real devices, over real days, weeks and months; not a simulation
- A mid-range Android phone on a normal mobile connection (your iPhone on office wi-fi is lying to you)
- Your analytics split by device, because the desktop numbers will hide the problem (and for most sites, desktop traffic is an almost insignificant fraction of actual customer traffic)
- The honesty to measure conversion before and after rather than assuming the improvement paid off
Observations
- The headline stat everyone quotes is doing a lot of work. The widely-cited figures on one-second improvements come from very large retailers with enormous traffic, where a fractional percentage change is a meaningful revenue number. The famous Google/Deloitte study "Milliseconds Make Millions" showed an 8-10% uplift in conversion rate and AOV The overall gist of the finding (faster pages = faster sales) transfers to an independent store. The magnitude does not.
- Speed score and speed experience are different measurements. A lab score is one simulated load of one page on one simulated device; change the time, date, device or internet connection and you can get a wildly different score. Field data-what your actual customers on actual phones actually got, compiled over time to average out the differences-is where the rubber really meets the road. Stores routinely have a respectable score and poor field data, or vice versa. _If you only ever look at the score out of 100, you are optimising a simulation.*_
- Most of the recoverable second on an independent store sits in third-party scripts. Review widgets, chat bubbles, upsell tools, pop-overs (aka dickovers) and multiple analytics tags each add their own round trip before the page becomes usable. Mobile websites are about 11.5x bigger than they were 15 years ago The fastest speed win available to most stores is a deletion, not an optimisation.
- The second that matters most is the one before anything appears. A customer who sees a blank white screen has no evidence the site is working. A customer who sees the product image and price while the reviews section is still loading is already shopping. Perceived speed converts; measured speed only reports.
- Mobile is where the second is lost and where the sale is lost with it. Desktop connections are forgiving enough to hide a slow site almost entirely, which is why so many owners are genuinely surprised by their own field data. Mobile devices account for nearly 80% of all online retail traffic and 70% of sales Check the number on a mid-range Android or an older iPhone before deciding you don't have a problem.
Experimental Results
The reason "improve your page speed" is such unsatisfying advice is that it describes an outcome rather than a mechanism. Two stores can both cut a second off their load time and get completely different results, because they cut different seconds. One removed a render-blocking script that was sitting between the customer and the product image. The other compressed a set of images that were loading below the fold, after the customer had already decided. Both improved a metric. Only one improved a business.
What actually moves conversion is the interval between tapping a link and having something worth looking at. That interval is where doubt lives. It is also where the customer's patience is at its absolute thinnest, because they have not yet invested anything in the visit and have a search results page one back-swipe away. Everything after that first meaningful paint is played on easier ground — a customer who is reading a product description will tolerate a reviews widget taking another two seconds to appear, and will often not notice it at all. Check your bounce rate as part of any page speed improvement exercise.
This is why a streamlining audit is usually a better move than the optimisation. Independent stores accumulate apps the way a kitchen drawer accumulates takeaway menus: each one arrived for a defensible reason, and nobody has audited the drawer in two years. A store running a review app, a chat widget, a popup tool, a loyalty scheme, a currency converter, and three separate analytics tags is not slow because of its theme. It is slow because it asked six third parties (over whose servers you have no control) for their input before showing a customer a jumper.
To be clear, analytics, reviews, cart abandonment apps… these all have their place. It's not about going back to hand-coded HTML and nothing else, it's about making sure that every app is optimised to minimise speed impact and earns its keep through whatever benefit it brings.
There is a version of this work that is genuinely a developer job — server response times, theme-level rendering, image delivery. But most independent stores never get far enough down the list to need it, because the first pass through the app stack recovers more time than a theme rebuild would, for a fraction of the cost and none of the risk.
The last part matters as much as the fix: measure the conversion rate before and after, split by device, over a window long enough to mean something (this will depend on your traffic, but 1-3 months should give meaningful data). Page speed work is one of the few technical improvements where the payoff is directly measurable, and skipping the measurement is how stores end up believing either that it did nothing or that it fixed everything. Usually it did something specific, and knowing what tells you where the next second is.
Sources of Error
- Optimising for the score rather than the customer. A score of 90 with poor field data is worse than a score of 70 with good field data, and only one of those is visible on a dashboard.
- Testing on the wrong device. Owners test on their own phone, on their own wi-fi, with the site already cached. That is the single most flattering condition the site will ever see.
- Compressing images that were never the problem. Below-the-fold assets can be made smaller all day without touching the moment that decides the sale.
- Adding an app to fix the speed problem caused by apps. Speed-optimiser apps have their place, but installing a seventh script to manage the other six is not the obvious first move it appears to be.
- Not measuring conversion afterwards. Without a before-and-after, page speed work becomes an article of faith rather than a decision you can repeat.
Where To Start This Week
Open Search Console's Core Web Vitals report and look at the mobile field data — not the score, the field data. Then open your installed apps list and find the ones nobody remembers choosing. For most independent stores, those two screens contain the whole first round of work, and it's an afternoon rather than a project.
If you'd rather have someone find the second that's actually worth chasing on your store, that's what a Quantised technical audit does. Get in touch.