The Performance Number Everyone Tracks and Almost Nobody Uses Properly

There is a particular kind of disappointment that comes from a tool that promises insight and delivers a number. You run the audit, it says 47, and yesterday it said 91. Nothing you shipped explains the gap, and yet you spend the morning quietly convinced you have broken something.

The Lighthouse score is not a fake signal. The metrics underneath it are well researched and mostly sound. The problem is that the number is answering a narrower question than the one you are asking.

What the number actually measures

The score is a weighted blend of lab metrics collected in a single simulated run: one page, one location, one throttled CPU, one throttled network, once. Largest Contentful Paint carries the most weight. Total Blocking Time is close behind.

Note the word simulated. Lighthouse is not measuring your users. It is measuring a synthetic device that resembles nobody in particular, and it is doing it on the machine you happened to run it from.

Three things that move the number and have nothing to do with your code

The host machine matters. CPU throttling is applied on top of whatever load the machine is already carrying, so a laptop on battery with a build running in another terminal produces a worse score than the same commit on an idle desktop. Nothing shipped. The number moved.

Run-to-run variance on an unchanged commit is routinely five to ten points. A single run is a sample, not a measurement, and treating it as a verdict is the most common mistake teams make with it.

And the score is a percentile curve, not a percentage. Dragging LCP from 4.0s to 3.5s can be worth more points than dragging it from 2.0s to 1.5s, even though the second is the harder engineering problem. The curve rewards escaping the bottom, not approaching the top.

The version that works

Stop reading the composite and read the metrics underneath it. LCP, INP and CLS each fail for different reasons and have different fixes. A single score averages three unrelated problems into one number you cannot act on.

Then get field data. Real users, real devices, real networks, aggregated over weeks. Lab data tells you why something is slow and lets you test a fix in a minute. Field data tells you whether it is slow for anyone who actually visits. You need both, and they answer different questions.

The pattern worth internalising: when lab and field disagree, the field is right about whether you have a problem, and the lab is right about what is causing it.

What to do on Monday

Run the audit three times and take the median. Put the field metrics on a dashboard where a regression is visible without anyone running anything. Alert on the metrics, never on the composite.

And when the score moves without a deploy, believe the deploy.