What a slow site actually costs

"Faster means more sales" is so worn out in this industry that it has stopped meaning anything. Everyone agrees with it, nobody can say what it is worth in money, and as a result performance work loses the queue to any feature that has an owner.

It can be done better than that. There are two serious studies with real numbers, there are established thresholds above which users feel the problem, and there is a way to measure your own situation instead of borrowing someone else's averages. There is also a methodological catch that almost nobody citing these studies mentions, and it changes the conclusions. Start with what is being measured.

Three numbers that describe a feeling

Core Web Vitals are three metrics chosen so that each answers a different user question, rather than a different engineering question.

All three are assessed at the 75th percentile of page loads, split between mobile and desktop. That detail matters more than it looks. The 75th percentile means three quarters of visits must sit below the threshold and one quarter may be worse. An average would not work here: a handful of very fast loads from the office on a fast line can hide the fact that every fourth mobile user waits five seconds.

Since 12 March 2024 INP has replaced the old First Input Delay, and the change is worth understanding because it addresses a real problem. FID measured only the delay of the first interaction, and only up to the moment the event handler began. A page that accepted your click instantly and then drew nothing for a second scored an excellent FID. INP measures the full path from click to the next frame, across all interactions during the visit rather than just the first. In other words, it measures what users call "the page is janky".

What the web actually looks like

Before the money, a baseline is useful. The Web Almanac, the annual HTTP Archive report built on Chrome User Experience Report data, states that in 2024 43% of sites achieved good scores on all Core Web Vitals on mobile and 54% on desktop.

The most telling figure in that data is the INP gap: 74% on mobile against 97% on desktop. That is one sentence about an entire industry. Responsiveness is not a problem with code in general, it is a problem with code running on a phone, which is several times slower than the machine of the developer who wrote it.

The numbers everyone quotes

The most cited study here is Milliseconds Make Millions, produced by Deloitte Digital with Google. It covered 37 European and American brands, more than 30 million sessions, over 30 days at the end of 2019. The researchers compared business outcomes for users whose pages loaded faster against those where it was slower, expressing the difference as the effect of a 0.1 second improvement.

The second study is smaller but methodologically stronger, and worth more for exactly that reason. Vodafone ran an A/B test on its own landing page: one optimised version, one unchanged, the same traffic split at random. The faster version had a 31% better LCP. The result: 8% more sales, a 15% improvement in the lead-to-visit rate and 11% in cart-to-visit.

The catch nobody mentions

These two studies are not the same kind of evidence, and conflating them is the most common error in the whole performance conversation.

The Deloitte study is correlational. It compares different users on different sites and asks whether the faster ones do better. They do. But a fast load does not come from nowhere: it correlates with a better connection, a newer phone, a closer server and a wealthier user. Someone on a new iPhone over fibre buys more often than someone on a five-year-old Android with poor signal, and would do so even if the page loaded identically for both.

The Vodafone study is experimental. Same traffic, random split, the only difference being page speed. There, 8% more sales genuinely means the effect of speeding the page up, because every other factor was distributed evenly between the versions. One number like that is worth ten correlational ones, and it is the one to build your argument on, even though it is less spectacular.

Lab measurement against field measurement

A second distinction, equally important, concerns where your own numbers come from.

Lab tools such as Lighthouse load the page under controlled conditions: fixed network, fixed CPU throttling, a single load. They are repeatable and excellent for checking whether a change helped. They say nothing about what your users experience, because your users are not in a lab. INP in particular is essentially unmeasurable in a lab, since it requires real clicks on real elements.

Field data is collected from actual visitors and is the only thing that answers "is my site fast for my customers". Its drawback is noise: you need a lot of visits before the 75th percentile stops jumping from day to day.

A healthy approach uses both without confusing their roles. Field data tells you whether you have a problem and for whom. The lab tells you why, and whether the fix worked. Reversing that leads to optimising a tool's score rather than the user experience, and those two diverge faster than you would expect.

How to work out your own number

Rather than transplanting someone else's percentages onto your business, do your own arithmetic. The numbers you need are ones you already have.

1. Split traffic by speed, not by page. Take LCP from field data and separate visits below 2.5 s from those above. Compare conversion in the two groups. Still correlational, but computed on your customers rather than 37 strangers' brands.
2. Check the difference is not a device difference. Repeat the same comparison separately for phones and desktops. If the conversion gap vanishes within each group, what you saw was the difference between phone and computer, not between slow and fast.
3. Pick one high-traffic page and run a real A/B test. One change, affecting performance only, with no change to content or layout. That is what Vodafone did, and only that kind of measurement yields a number you can put in front of a board without caveats.
4. Convert to money under two scenarios. A conservative one, say a quarter of the published effect, and an optimistic one at full strength. A range is more honest than a single figure and easier to defend when someone asks where it came from.

What speed will not fix

A fair caveat in the other direction to close, because performance articles usually end with a bottomless promise. Speed is necessary, not sufficient. A page that loads in a second but lacks the thing somebody came for will sell nothing, only faster.

Performance also saturates. The difference between four seconds and two is felt by everyone. The difference between 1.2 and 1.0 seconds is felt by nobody, and usually costs more work than the first one did. The best return always lies in moving the worst quarter of your users below the threshold, not in polishing the score of those who are already fine. That is precisely why the measurement uses the 75th percentile rather than the mean.