How to track Lighthouse scores over time and catch regressions after a deploy

A Lighthouse score is useful when you watch it move, not when you read it once. A client's site can be fast on Monday and slow on Friday because of one deploy, one new script or one large image, and you only notice if you kept the earlier number.

This guide explains how to get steady measurements, where to store them and how to connect a drop to the change that caused it.

What does Lighthouse measure?

Lighthouse is an open-source tool that loads a page in a controlled environment and reports scores for performance, accessibility, best practices and SEO. For tracking regressions, the performance score and the metrics behind it are what move most often:

• Largest Contentful Paint (LCP): how quickly the main content appears. A good result is 2.5 seconds or less.
• Cumulative Layout Shift (CLS): how much the page jumps while loading. A good result is 0.1 or less.
• Total Blocking Time (TBT): how long the page is unresponsive during load. It is the lab stand-in for Interaction to Next Paint (INP), where a good result is 200 milliseconds or less.

Why are my Lighthouse results different every time?

Lighthouse runs in a simulated environment, and small things shift the numbers.

• Network and CPU conditions on the machine running the test.
• Third-party scripts such as chat widgets, tag managers and ads that behave differently each time.
• Caching, A/B tests and personalised content.
• The first request after a deploy, which may hit a cold server.

The fix is not a better run. It is more runs.

How do I get consistent measurements?

1. Run the same test every time. Same page, same device profile (mobile or desktop) and same tool.
2. Run it several times and take the median. Three to five runs smooth out most of the noise.
3. Test the pages that matter. The homepage, the main landing page and the page that earns money, not just one URL.
4. Keep the conditions fixed. Do not compare a run on your laptop with one from a different tool.

You can get a result without installing anything through the PageSpeed Insights API:

curl -s "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://example.com&strategy=mobile&category=performance"

The response includes the Lighthouse result for that page, and Google's own field data when it exists.

How do I store and compare the results?

A score without a date cannot show a trend. For each run, record the URL, the date and time, the device profile, the performance score and the individual metrics.

Then record when each deploy went live. Putting the two on one timeline is what turns a number into an explanation: the score was 91 until Tuesday afternoon, the deploy happened at 15:40 and it was 64 afterwards.

Be careful with the conclusion. The deploy is where to look first, but it is timing and not proof of cause. A third-party script or a change in the data the page loads can lower the score without any deploy.

What should I do when the score drops?

1. Re-run the test a few times to rule out noise.
2. Compare the individual metrics with the last good run. A big LCP change points at images, fonts or server speed. A big TBT change points at JavaScript.
3. Look at what changed in the deploy: new dependencies, new scripts, larger images or removed caching.
4. Revert or fix, then run the test again and note the result.

What is the difference between lab data and field data?

Lighthouse is lab data: a repeatable test under fixed conditions. Core Web Vitals in the field are measured from real visitors on real devices, and they are what Google uses to judge page experience.

Use Lighthouse to catch regressions early and to compare releases, and use field data, for example from Search Console's Core Web Vitals report, to see what users actually get. A site can score well in the lab and still be slow for real visitors on poor connections.

Where Datumboard fits

Datumboard keeps Lighthouse results over time through PageSpeed Insights and shows a score drop next to the deploy that came before it, so you know where to start looking. The page says it is timing, not cause. It is in early access, and you can join the list below.