Why Lighthouse Scores Vary Between Runs

Lighthouse scores vary between runs because each run measures a single page load, and no two loads happen under the same conditions. The server answers a bit faster or slower, the network takes a different route, your laptop is busy with something else, or the page shows a different ad. A few points of movement on an unchanged page is normal. Before you react to a lower score, run the test a few more times and look at the metrics under it.

To see how big the swing really is, I ran Lighthouse 13.5 twenty times in a row on our own homepage, with the default mobile settings, on an idle M1 Pro laptop. Nobody touched the page between runs.

Metric	Lowest	Median	Highest
Performance score	95	96	98
First Contentful Paint (FCP)	1.69 s	2.11 s	2.13 s
Largest Contentful Paint (LCP)	2.07 s	2.42 s	2.51 s
Total Blocking Time (TBT)	0 ms	0 ms	0 ms
Cumulative Layout Shift (CLS)	0	0	0

LCP moved 440 ms, and one run landed at 2.51 s, just over the 2.5 s line Google draws for a good LCP. Look at that report alone and you’d go hunting for a problem the page doesn’t have. (I explained what each metric measures in another post.)

The score only moved three points because TBT and CLS, which make up 55% of it according to Chrome’s scoring docs, stayed at their best possible value of 0. Our homepage runs very little JavaScript. On a page with more of it, TBT wobbles too, and the score swings further.

Why your Lighthouse score fluctuates

A/B tests, rotating ads, cookie banners, personalized content and third-party scripts can make the page itself load something different on every visit. Lighthouse’s variability guide rates this as a high-impact source that no test setting can fix. The only cure is making sure every run tests the exact same version of the page.

The network and the server add their own noise. A busy server, a CDN cache that’s still cold after a deploy or a different route across the internet changes how fast files arrive. In my 20 runs, the server took anywhere from 61 to 188 ms to answer.

Your computer matters too. Other apps, browser extensions and antivirus software compete with Chrome for the CPU. I tried to provoke this by running a do-nothing loop on all ten CPU cores during ten more runs, and the results didn’t move: the score stayed between 95 and 98. The default test partly corrects for a busy CPU, and with so little JavaScript on the page, there was almost nothing to slow down. A heavier page would likely move more, so a quiet machine is still the safer bet.

The settings change the result as well. Mobile and desktop tests emulate different devices and networks, and a new version of Lighthouse or Chrome can measure the same page differently. So can the throttling method, which is easy to overlook.

The default mobile test is an estimate

By default, Lighthouse loads the page at full speed and then calculates how long the same load would take on a mid-range phone over slow 4G. This is called simulated throttling. It filters out a lot of network noise, but small differences in that fast load can move the estimate in jumps. In my runs, 12 of the 20 FCP values landed within 25 ms of 2.11 s, and the other eight jumped at least 140 ms lower, down to 1.69 s.

Then I ran ten more tests with --throttling-method=devtools, which slows the real connection down instead of estimating. The two methods model a slow phone differently, so the numbers don’t line up: FCP came out faster, at about 1.25 s. The score went down anyway, to about 91, because CLS went from 0 to 0.18 in every run. On the slow connection, a web font arrived after the first paint and shifted the dashboard preview on the page.

Visitors on a slow connection can get that shift too. The default test missed it because layout shifts aren’t simulated: CLS comes from the fast load Lighthouse actually ran, and in that load the font arrived in time. So compare runs only when they used the same method, and know that a clean CLS in the default test doesn’t prove the page never shifts.

Why PageSpeed Insights shows a different score

PageSpeed Insights runs Lighthouse too, but on Google’s servers, in a data center in North America, Europe or Asia, and not necessarily on the same Lighthouse version as yours. So its score rarely matches the one from your laptop.

The top part of the report is a different kind of data. When your site has enough traffic, it shows field data from the Chrome UX Report: what real Chrome users experienced over the previous 28 days, at the 75th percentile, as Google’s PageSpeed Insights docs explain. That window rolls forward slowly, so a fix you ship today takes about four weeks to fully show up there. The field data is the better guide to what your users get. Lab runs are where you test a fix, because you can repeat them whenever you want.

How to compare Lighthouse runs

1. Keep the setup identical: the same URL and page state, device mode, throttling method, Lighthouse and Chrome versions, and machine. Save the full report from every run.
2. Run each version at least five times and compare the medians. The variability guide says the median of five runs is twice as stable as a single run. With Lighthouse CI, lhci collect --url=https://example.com -n 5 runs the five tests for you.
3. Compare metrics instead of the score. Find the metric that moved and check whether the change is bigger than the spread on an unchanged page. On our homepage, LCP varied by 440 ms while nobody touched the page, so a 200 ms gap between two single runs tells me nothing.
4. Test on a quiet, consistent machine. The guide recommends at least two dedicated CPU cores and warns that free CI runners and burstable cloud servers give unstable results.
5. Watch the trend. A drop that shows up run after run is a change. A drop that shows up once is usually noise.

If a drop survives five runs, it’s probably real, and the checklist for a website slow after deployment picks up from there.

PulseCare runs a full Lighthouse audit on every scan, once as desktop and once as mobile, and keeps the reports, so one odd number sits next to the runs before it. When it compares scans from before and after a deploy, it first checks whether the page downloaded exactly the same files at the same sizes and whether the server answered as fast as before. If both hold, it treats a moved score or timing as run-to-run noise and doesn’t flag a regression. Deploy checks start on the Growth plan, and you can click through sample reports in the demo.