How Much Faster Does a Page Need to Be to Matter?

"The site needs to be faster" is advice with no stopping condition. Faster than what, and how much faster before the work stops paying? Site speed — and the page speed numbers behind it — has both a threshold worth clearing and a ceiling past which further work buys very little, and most performance projects are argued without either being named.

What thresholds actually exist?

Google publishes explicit ones for Core Web Vitals, and they are the only speed numbers with a documented connection to search. Each is assessed at the 75th percentile of real visits, which means clearing them requires being fast for three quarters of your visitors, not for your test machine.

These are the boundary between "passing" and "not passing". They are not a ranking scale — there is no documented additional benefit to an LCP of 0.9 seconds over 2.4 seconds as far as search is concerned. Both pass.

Where does the real money sit?

Below the threshold, and mostly at the slow end. The relationship between load time and abandonment is not linear — the difference between two seconds and four is far more costly than the difference between one and two, because the second range is where people give up.

Which is why the highest-value performance work is almost always on the worst pages rather than the average one. A template at six seconds on mobile is losing visitors before they see anything. A template at 2.2 seconds is fine, and squeezing it to 1.6 will not show up in any business number you can defend.

Whose experience are you optimising?

The 75th percentile, and it is worth checking who that is. Field data aggregates real visits across real devices and networks, and the tail is usually a specific segment — older Android hardware, rural connections, a particular region.

That segment is why lab scores mislead. A test run on a fast laptop over office broadband measures an experience almost none of your visitors are having. When lab and field disagree, field wins, and the gap is telling you which devices you have not been testing on.

When is more speed still worth buying?

When it converts, not when it ranks. Past the search thresholds there is still a case for speed on pages carrying commercial weight — checkout flows, booking forms, anything where hesitation costs money. That case has to be made on conversion evidence rather than on search.

A reasonable order of operations:

1. Find templates failing in field data. Fix those first; they are losing visitors now.
2. Get every important template comfortably inside the thresholds, not marginally inside them, so normal variance does not push you back out.
3. Stop. Re-measure after a month of field data.
4. Only then consider further work, and only on pages where you can measure conversion.

How do you keep it from regressing?

By making it somebody's monitored number rather than a project. Performance decays through ordinary work — a new tag, a new font, a new hero video — and a site optimised once will be slow again within a year without a check that runs on its own.

The cheapest version is a monthly look at the Core Web Vitals report in Search Console, which tells you which templates moved and when. That is enough to catch a regression while it is still one change rather than twelve.

Pull your field data and find the template with the worst 75th-percentile LCP. That page, and not the site average, is where the next hour of performance work belongs.