Why does my Lighthouse score change every run?

CPU contention on the machine running the test. A browser, a build and a video call compete for the same cores, and the metrics most affected are the ones measuring main-thread work.

Network conditions, even under throttling, because throttling simulates bandwidth rather than removing real latency and packet loss.

Third-party responses. Advertising, analytics and chat widgets answer at different speeds, and one slow response moves the result.

Cache state, at every layer: the browser, a CDN edge that had or had not seen the page, and the origin's own caches.

A/B tests, personalisation and consent flows, which can serve genuinely different pages to consecutive runs.

Anything measuring main-thread time is the most volatile, because it is the most sensitive to what else the machine is doing.

Largest Contentful Paint moves with network and cache state, which is why it can look excellent on a warm run and poor on a cold one.

Cumulative Layout Shift is comparatively stable, because it depends on layout behaviour rather than on timing — unless an advertisement or a consent banner loads inconsistently.

Interaction to Next Paint cannot be measured in a laboratory run at all, since it requires someone to interact.

The composite score amplifies the variance of its inputs, which is why it swings more than any individual metric.

Run it several times and take the median. Three runs is the practical minimum and five is better.

Run it from a consistent environment: a CI machine, or at least a laptop that is not doing anything else.

Keep the configuration identical between runs — same device emulation, same throttling, same URL, same consent state.

Compare the individual metrics rather than the composite score. A score moving from 72 to 81 is far less informative than knowing which metric changed.

Change one thing at a time. Twenty fixes shipped together make it impossible to attribute any movement.

Core Web Vitals are assessed on field data — real visits from real devices — at the 75th percentile over a 28-day window.

A laboratory run on a fast connection does not predict that percentile, and it is not meant to.

PageSpeed Insights shows both side by side, which is the fastest way to see whether they agree. When they disagree, the field data is the one that counts for the assessment.

Field data lags by up to 28 days, so an improvement shipped today appears there gradually rather than immediately.

A page with too little traffic has no field data at all, in which case the laboratory run is all you have — and its limits still apply.

VeriFixScan reports the observable causes rather than a timing score: `performance.render_blocking`, `performance.page_weight`, `performance.request_count`, `performance.third_party_resources` and `performance.dom_size`.

Those are stable between runs, because they are properties of the document rather than of the moment it was loaded.

`performance.ttfb` and `availability.response_time_breakdown` do measure timing, and are subject to the same variance as any other single observation.

Reading the stable findings alongside a median laboratory score is more useful than either alone: one says what is wrong, the other says how much it currently costs.