How Much Does Site Speed Really Affect Sales?

Conversations about site speed usually start with a number: the score from a testing tool. And they usually end there too, because that number on its own tells nobody what to do. Speed only becomes meaningful once you know which moment of the experience is slow and what that moment costs you.

The three numbers that matter

Google treats three metrics as the basis of page experience, and all three describe what the user actually feels rather than how powerful the server is.

• LCP — how many seconds until the largest piece of content is visible. The measure of "it loaded".
• INP — when someone taps or clicks, how long until the page responds. The measure of "it feels smooth".
• CLS — how much the layout jumps around while loading. The measure of "it feels reliable".

The real causes of slowness, in order of frequency

Across the projects we have audited, the cause has almost always come from this short list, and usually in roughly this order of importance.

1. Unoptimised images: a multi-megabyte photo the browser has to shrink itself. Converting to WebP or AVIF and setting explicit dimensions gives the biggest gain for the least work.
2. Heavy fonts with no display strategy: text stays invisible until the font loads and the visitor stares at an empty page.
3. Unnecessary JavaScript: a library pulled in for one small effect, whose execution then slows the page's responsiveness.
4. Third-party scripts: analytics, live chat and advertising pixels, each taking its share of the speed budget.
5. No caching and a distant server: every request is processed from scratch and the network path is long.

How speed connects to money

Speed affects revenue in two ways. Directly: a visitor who waits abandons part of the path to purchase, and in a store that drop-off is clearly measurable. Indirectly: page experience is a ranking signal, so a slow site also loses ground in search. The important caveat is that the effect is not linear. Going from six seconds to three makes a visible difference; going from 1.5 seconds to 1.2 usually does not.

Fix the glaring problems first, then move on to the subtle optimisations. The other order is a waste of time.

Where to start

A practical route: record the current state using field data; pick your three highest-traffic pages, not the whole site; fix the images and fonts on those pages; measure again. That single cycle usually delivers most of the improvement available in the whole project. After that, if it is still needed, go after the JavaScript and the third-party scripts.

And one simple piece of advice: measure again after every change. Optimisation without measurement quite often makes a site slower, and nobody notices.