# Why your Lighthouse score changes every time you run it

> Lighthouse scores vary because network, CPU, server time, ads and third-party scripts differ on every run. Learn what causes it and how to compare fairly.

Published: 2026-11-15 · Author: AiroPages

Your Lighthouse score changes on every run because no two page loads are identical. Network timing, CPU load on the test machine, server response time, ads, A/B tests, browser extensions and third-party scripts all shift slightly from one load to the next, and each shift nudges the metrics behind the score. The fix is not to chase a stable single number but to compare runs fairly and look at patterns.

## Some movement is normal

A score that moves a few points between back-to-back runs is not a sign that something is broken. Lighthouse measures one real page load each time, then models how that load would look on a slower device. Small timing differences in that load become small differences in the metrics, and those feed the [Lighthouse performance score](/glossary/lighthouse-score).

For example, a blog post might score 81, then 86, then 79 in three runs a minute apart, with no code change in between. That page is not getting faster and slower. You are seeing the normal spread of measurements. Larger swings usually mean something on the page or server genuinely behaves differently from one load to the next, which is worth investigating.

## The main sources of variance

Most variance comes from a short list of causes. Knowing which one is at play tells you whether to ignore it or fix it.

### Network conditions

The connection between the test machine and your server is never perfectly steady. Packet loss, routing changes and congestion all change how long requests take. This matters most for large files, such as a hero image or a big JavaScript bundle, where small delays add up.

### CPU and machine load

When you run Lighthouse in Chrome DevTools, it shares your computer with everything else you have open. A video call, a build process or a dozen busy tabs can slow down script execution during the test. Since mobile runs model a CPU that is 4 times slower, any extra delay on the host machine is magnified in metrics like [Total Blocking Time](/glossary/tbt).

### Server response time

Your server does not answer every request in the same time. A page may come from a cache on one run and be generated from scratch on the next. Serverless functions can have cold starts, databases can be busy, and a CDN edge might miss its cache. Any change in time to first byte (TTFB) delays everything that follows.

### A/B tests and personalization

If your site runs experiments, Lighthouse may get a different variant on each load: a different hero image, an extra banner, a heavier script. Personalization based on location or cookies has the same effect. You end up comparing two different pages that happen to share a URL.

### Ads and third-party scripts

Ad slots are filled by auctions, so the creative, its size and the scripts that come with it change every time. Tag managers, chat widgets, analytics, heatmaps and embedded videos can also load in a different order or take different amounts of time. Third-party code is often the single biggest source of TBT swings.

### Browser extensions and state

Extensions inject scripts and styles into the pages you visit, and Lighthouse in DevTools measures them along with your own code. Cached files, stored cookies and a consent banner you already accepted also change what loads. An incognito window with no extensions removes most of this.

### Tool and version differences

A new Chrome or Lighthouse version can change how audits work or how metrics are calculated. If one run used an older version and the next used a newer one, the difference might be the tool, not your page.

## How simulated throttling helps

Simulated throttling is the main reason modern Lighthouse scores are steadier than they used to be. Instead of slowing the real connection during the test, Lighthouse loads the page on a fast connection, records what happened, and then calculates how that load would have played out on a slow 4G connection with a slower CPU. PageSpeed Insights uses this method, and it is the default in DevTools and the CLI.

Because the slow network is modeled rather than real, live network hiccups have less effect on the final metrics. Simulation cannot help with everything, though:

- If your server takes longer to respond, the model starts from a slower load.
- If the test machine's CPU is busy, the recorded script work is longer before it is scaled up.
- If an ad or A/B test serves different content, the model is simulating a different page.

So simulated throttling reduces noise, but it does not make a page with unpredictable third-party content produce a predictable score.

## Which metrics move the most

The five metrics in the performance score do not vary equally. Looking at which one moved tells you a lot about the cause.

| Metric | Weight | How much it tends to vary | Common cause of swings |
|---|---|---|---|
| Total Blocking Time | 30% | Often the most | Third-party scripts, CPU load on the test machine |
| Largest Contentful Paint | 25% | Moderate | Server response time, hero image loading |
| Cumulative Layout Shift | 25% | Usually stable | Ads or banners that sometimes appear |
| First Contentful Paint | 10% | Moderate | Server response time, render-blocking files |
| Speed Index | 10% | Moderate | Anything that delays visible content |

Because TBT carries the largest weight and is often the most variable, it is behind many of the biggest score swings. Our explainer on [how the Lighthouse performance score is calculated](/blog/how-the-lighthouse-performance-score-is-calculated) shows why a change in one heavily weighted metric moves the overall number so much.

## How to compare Lighthouse scores fairly

Fair comparison comes down to changing one thing at a time and looking at more than one data point.

1. **Use the exact same URL.** A trailing slash, a query string or a redirect can mean a different page or an extra round trip.
2. **Use the same device setting.** Mobile and desktop are separate tests with different throttling and scoring. Never compare a mobile score with a desktop score.
3. **Use the same tool and settings.** DevTools, the CLI and PageSpeed Insights run in different environments. Pick one for any before-and-after comparison, as we explain in [Lighthouse vs PageSpeed Insights](/blog/lighthouse-vs-pagespeed-insights).
4. **Check the Lighthouse version and test location.** Both appear in the report. If either changed, note it before drawing conclusions.
5. **Run more than once.** For an important decision, run the page several times and compare the median, not the best or worst result.
6. **Compare metrics, not just the score.** If TBT jumped and everything else held steady, look at scripts. If LCP and FCP both moved, look at server response time.
7. **Watch trends over time.** A score that sits around 70 for a month and then settles around 60 after a release is a real change, even if individual runs overlap.
8. **Look for template-level patterns.** If 40 product pages all show the same render-blocking script, that is a fact about the template, not a lucky or unlucky run.

That last point matters most at scale. Single runs on single pages are noisy, but the same failed audit appearing on every page built from one template is a strong signal. We cover this approach in [template-level fixes](/blog/template-level-fixes).

## How to check this across your whole site

Variance is easier to read when you have many pages to compare. The manual way is to collect URLs from your sitemap, run Lighthouse on each one with the CLI or the PageSpeed Insights API using fixed settings, store the results with the date and Lighthouse version, and repeat on a schedule so you can compare trends. The pages that share a template should show similar results, and outliers are worth a closer look.

AiroPages does this as a hosted service. It runs every page on mobile and desktop with PageSpeed Insights settings, one run per device, and records the Lighthouse version and test region so you know which results are comparable. Identical issues are grouped by page template, and [scheduled monitoring](/features/monitoring) runs weekly or monthly scans and alerts you when scores drop. You can re-scan any single page to see how much it moves. It is the same idea we describe in [Lighthouse only tests one page](/blog/lighthouse-only-tests-one-page): one page tells you little, the whole site tells you a lot.

## Stop chasing one number

A Lighthouse score is a measurement of one page load, and every page load is a little different. Expect a few points of movement, keep your test setup consistent, compare the individual metrics, and trust patterns that repeat over time and across templates. That way you spend your effort on real regressions instead of on noise.