The speed score in your audit is not what your visitors experience

Almost every SEO audit you will be shown contains a performance score out of 100, coloured red. It comes from Lighthouse, or from PageSpeed Insights which runs Lighthouse for you, and it is the single most common piece of evidence used to sell website performance work.

It is also, for most sites, not a measurement of what anyone experienced.

We collect both kinds of speed data for every business in the Local Digital Visibility Index: the Lighthouse lab test, and Google’s Chrome UX Report, which records what real Chrome users actually got over 28 days. For 121 businesses we hold both. Nobody, as far as we can tell, had put them side by side.

Every figure here is computed from the published datasets when this page is built.

The finding

Largest Contentful Paint	Median across 121 businesses
Lighthouse (lab)	12.6s
Real Chrome users (field)	1.7s

The lab number is 7.4× the real-user number. Not slightly pessimistic. A different order of quantity.

That is not a bug in Lighthouse. It is what Lighthouse is for: it loads the page once, on a datacentre machine, with the CPU throttled roughly 4× and the network simulated as a slow connection, deliberately, to expose problems under stress. It is a laboratory instrument. Laboratory conditions are not your customers’ conditions.

Where the two disagree

Of the 121 businesses measured both ways:

• 37 are rated poorly by the lab test (a Lighthouse performance score under 50)
• 41 actually fail Core Web Vitals for real visitors
• The two verdicts agree for 77 and disagree for 44

The disagreements split in both directions, and they are not equally harmless:

20 businesses are condemned by the lab while their real visitors are fine. These are the ones at risk of buying performance work they do not need. Somebody shows them a red 34, and the honest answer is that their actual users are not experiencing a problem.

24 pass the lab test while real visitors fail Core Web Vitals. This is the more serious direction and the one nobody talks about, because a clean lab score reads as an all-clear. It is not. Real-user failures cluster in metrics a single scripted load barely touches — layout shift as ads and images arrive, and responsiveness while someone is actually clicking things.

Why the lab number runs so far ahead

Three reasons, and none of them is anyone behaving badly:

1. Throttling is applied on purpose. Lighthouse simulates a mid-range phone on a slow connection. If your customers are on modern phones and decent broadband, the simulation is not describing them.
2. One load is not a distribution. The field figure is a 75th percentile across thousands of real sessions with warm caches, real devices and real networks. The lab figure is one cold load with an empty cache.
3. The lab machine is not local. A single datacentre run cannot reproduce the geography of a business whose customers are all within twenty miles of it.

When the lab number is still the right one to use

This is not an argument that Lighthouse is useless. It is the right instrument in three cases:

• When there is no field data at all. CrUX only reports sites with enough real traffic. Of the businesses we measure, only 121 have field data — the rest are too quiet, and for those the lab test is the only speed evidence available.
• When you are diagnosing rather than measuring. Lighthouse tells you what is slow — the specific render-blocking script, the unsized image. Field data tells you whether anyone suffers. You need both, in that order.
• Before and after a change. As a controlled comparison against itself, the lab test is excellent, because the conditions are held constant.

What it should not be used for is establishing that a business has a problem worth paying to fix. For that, the field data exists and is free.

What to ask when you are shown a red score

Three questions, in order:

1. “What does the field data say?” If the person showing you a Lighthouse score cannot tell you the Core Web Vitals assessment from real users, they have not looked. It is one query away and costs nothing.
2. “Which metric is failing, and for whom?” “Performance: 34” is not a diagnosis. Layout shift on mobile is a diagnosis.
3. “What happens to enquiries if we fix it?” Nobody can promise a number here, and anyone who does is guessing — but the question forces the honest answer, which is that speed work is worth doing when real users are affected and is otherwise housekeeping.

What this does not prove

121 businesses is a modest sample, all in the South West, all local businesses rather than large e-commerce sites. A heavier, more transactional site would likely show a different gap.

Field data has its own bias. CrUX only covers Chrome users who opt into reporting, and only sites busy enough to report at all — so the businesses in this comparison are, by definition, the ones with traffic. The quiet sites that most need help are invisible to it.

And speed still is not why these businesses cannot be found. We audited our own scoring weights and found the Speed pillar correlates −0.13 with whether a business appears in search results at all. That finding stands regardless of which instrument measured the speed.

Where to see this for your own firm

Every scorecard in the index now shows both figures side by side, where both exist — the lab number, the real-user number, and which metric is actually failing. Find your business and look under “Lab speed against real users”.

If both agree you have a problem, it is worth fixing. If only the lab says so, ask a harder question before you spend anything.