TL;DR
Your Lighthouse score changes between runs because every page load is slightly different: network timing, CPU load, server response time, ads, A/B tests, extensions and third-party scripts all vary. Simulated throttling reduces some of this noise but cannot remove it, so compare runs with the same URL, device and settings, and look at trends and template-wide patterns instead of single scores.
Key takeaways
- A few points of movement between back-to-back runs is normal, even when nothing on the page changed.
- Total Blocking Time is usually the most variable metric, and it carries the largest weight in the score.
- Simulated throttling removes much of the network noise, but not server, CPU or third-party variation.
- Only compare runs that use the same URL, device, tool, settings and Lighthouse version.
- A trend over several weeks tells you more than any single run.
- When the same issue shows up on every page built from one template, it is a real problem, not noise.
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.
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.
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 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.
- Use the exact same URL. A trailing slash, a query string or a redirect can mean a different page or an extra round trip.
- 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.
- 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.
- Check the Lighthouse version and test location. Both appear in the report. If either changed, note it before drawing conclusions.
- Run more than once. For an important decision, run the page several times and compare the median, not the best or worst result.
- 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.
- 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.
- 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.
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 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: 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.
Frequently asked questions
Why is my Lighthouse score different every time?
Each Lighthouse run is a fresh page load, and small differences in network timing, CPU load, server response time and third-party scripts change the measured metrics. Ads and A/B tests can also serve different content on each load. A few points of movement between runs is expected, even if the page itself has not changed.
How much should a Lighthouse score vary between runs?
On a stable page with few third-party scripts, back-to-back runs usually land within a few points of each other. Pages with ads, tag managers, chat widgets or slow servers can swing much more. If a score moves by a large amount, look at which individual metric changed, because that usually points to the cause.
Why is my PageSpeed Insights score lower than yesterday?
It could be normal variance, a slower server response at the time of the test, a third-party script that loaded differently, or a real change such as a new plugin, image or tracking tag. Run the test again a few times and compare the metrics, not only the overall score. If the drop repeats across runs and across similar pages, treat it as a real regression.
How do I get a consistent Lighthouse score?
Test the exact same URL with the same device setting, tool and Lighthouse version, in an incognito window with no extensions. Run the page several times and use the median instead of a single result. For long-term tracking, use a hosted or scripted setup that always tests from the same environment.
Does simulated throttling make Lighthouse scores stable?
Simulated throttling makes scores more stable than applying real network throttling, because Lighthouse models the slow connection instead of depending on live network conditions. It cannot remove variation from your server, from the test machine's CPU, or from scripts that behave differently on each load. Some variance always remains.
Published