I'm trying to improve a website's Lighthouse performance score, but repeated tests can vary by 5–10 points, sometimes landing anywhere from about 39 to 58. That makes it hard to tell whether a change actually helped or made things worse. How should I run and interpret Lighthouse tests so I can reliably measure improvements?
4 Answers
Don't focus only on the combined performance score. Track the specific metric your change was meant to improve—such as LCP, TBT, CLS, or total blocking time—in milliseconds. The score combines several metrics, so unrelated changes in CPU or network timing can move the total even when your target metric improved.
Some variation is caused by the test environment itself. CPU throttling and simulated network conditions can amplify small timing differences, and a slower server response can delay everything that follows. Once the site has enough real traffic, field data from actual users is a better measure of performance than a single lab test.
Lighthouse is naturally noisy because CPU load, network conditions, server response time, and resource loading can change between runs. Run it several times under the same conditions, then compare the median rather than trusting one result. Using a clean browser profile, the same Chrome version, device profile, and throttling settings will reduce the variation.
For each version, collect around 5–10 runs and record every individual metric. Use the median for each metric and compare those medians before and after the change. Also check the diagnostic details to confirm that the expected resource, script, or rendering stage actually changed instead of relying on the headline number.
Even LCP seems unstable for me. In one set of runs it ranged from about 3.3 to 5.1 seconds before the change, and from 3.3 to 5.0 seconds afterward, despite using a clean browser with no extensions.