Press Analyze in PageSpeed Insights, note the score, then press it again without touching the site. The second number is often different. A third run may give a third. It is easy to conclude that the tool is broken, or that your site is unstable, or that every score a designer has ever sent you is meaningless. Usually none of those is quite right.
The short answer: your PageSpeed score changes every time because each run is a fresh, single page load, and a single page load is affected by a lot of things outside your control. Some movement is normal. Large or erratic movement is worth investigating, because sometimes it is the most useful clue you have. Below we go through the causes in roughly the order we check them, and then a simple way to get a number you can actually work with.
First, what a single score is made of
The Performance score in PageSpeed Insights comes from a Lighthouse lab test. Google’s servers load your page once, on an emulated mobile phone or desktop with a throttled connection, and time how long various things take. Those timings are turned into a weighted score from 0 to 100.
Two things follow from that. One page load is one sample, and any sample can be unlucky. And the score is not linear: near certain points, a small change in one timing can move the score by more than you would expect, while elsewhere a big change hardly registers. So a score jumping around does not always mean the page itself changed much.
The field data at the top of the report, when your page has enough visitors, behaves differently. It is collected from real Chrome users over the previous 28 days and moves slowly. If the lab score is jumping but the field data is steady, that tells you something. Our post on how field data and lab data differ covers that relationship properly.
Why your PageSpeed score changes every time: the usual causes
Your server answered at a different speed
Every test starts by asking your server for the page. If that answer takes longer on one run than another, everything after it shifts too. On shared hosting your site shares a machine with other sites, so their traffic affects yours. If the page is cached, one run might be served straight from the cache and the next might trigger a rebuild because the cache had just expired.
This is the cause we look at first because it is common and because the fix is often simple. Compare the server response figure between runs. If it swings widely, the variation is coming from the server, not from the page design. Our explanation of time to first byte covers what is included in that first wait and how to measure it on its own.
Third-party scripts behave differently on each load
Ads, chat widgets, social embeds, review badges, heatmap tools, tag managers and analytics are all loaded from other companies’ servers. They do not always send the same thing twice. An ad network might return a small text ad on one run and a heavy animated one on the next. A tag manager might fire different tags depending on conditions. A chat widget might load quickly from a nearby server one time and slowly the next.
Sites with many of these see the most variation. If your report lists several outside domains among the heaviest or slowest items, they are a likely source. Reducing or delaying them is its own job, covered in how third-party scripts slow a site down.
The test ran from a different place or machine
PageSpeed Insights does not promise to run every test from the same data centre or on identical hardware. Google’s own documentation on Lighthouse variability lists differences in the test machine and network among the known causes. You cannot choose the location in PageSpeed Insights, so you cannot fully control this. You can only reduce its effect by running more tests.
A CDN or cache at the edge was cold
If you use a content delivery network, files are cached at many locations. A test that happens to hit a location where your files were not yet cached waits for them to be fetched from your server first. The next test through the same location gets the cached copy and looks faster.
Something on the page is randomised
Rotating banners, sliders that start on a random slide, “featured product” blocks that pick a different item, A/B testing tools that show different versions, cookie banners that appear or not depending on region. Each of these can change which element is the largest on screen, or how much layout shifts, from one run to the next.
The tool itself changed
Google updates Lighthouse regularly. A new version can adjust how metrics are calculated or weighted. If you are comparing today’s result with a screenshot from last year, the difference may be partly the tool. The report shows which Lighthouse version was used, so note it alongside your score.
Your site actually changed
It is worth ruling out the obvious. A plugin that updated itself overnight, a new image on the home page, a marketing tag added by someone else, or a host change you were not told about will all change results. If a score drops and stays down across many runs, look for a real change before blaming variability.
How much movement is normal?
We will not give you a fixed figure, because it depends on the site. A simple page on a good host with few outside scripts often gives results that sit close together. A busy page with ads and several widgets can spread much wider on the same day without anything being wrong.
A more useful test of “normal” is this: run the same URL five times in a row. If the results cluster and one or two are outliers, that is ordinary variability. If they are spread across a wide range with no clear middle, the page has a source of instability, and finding it will usually improve the real experience too, because real visitors get the same unpredictability.
Getting a score you can rely on
You cannot stop the variation, but you can stop it from misleading you. A simple routine helps:
- Warm the page first. Visit it once yourself, logged out, so any page cache is filled before testing.
- Run the test five times for the same URL, on the same device setting (mobile or desktop).
- Write down every result, not just the score: LCP, Total Blocking Time and CLS too.
- Take the median, the middle value when you sort the five. Do not use the best, and prefer the median to the average, because one wild run distorts an average.
- Look at which metric moves most. If Total Blocking Time swings and LCP is steady, scripts are the likely cause. If LCP swings along with server response, look at hosting and caching.
- Compare medians, not single runs, when you check whether a change helped.
This is part of a broader testing routine (same pages, same conditions, recorded each time), set out in our guide on testing website speed in a repeatable way.
When the variation is the problem
Sometimes the swinging score is the finding. If your server response time varies a lot between runs, that is not just a testing nuisance. Real visitors are getting the same uneven experience: fast at one moment, slow the next. Common causes include an overloaded shared server, a cache that keeps being cleared by a plugin, scheduled tasks running on page visits, or bots hitting the site hard.
Likewise, if blocking time jumps around because of an ad or a widget, some visitors are getting the slow version. Making the page steadier often matters more than raising its best-case number.
What not to do
- Do not rerun until you get a good number. It is tempting, especially before showing a client or a boss. It gives you a figure that real users rarely see.
- Do not judge a fix on one run. A single better result after a change could be luck. A better median across several runs is evidence.
- Do not compare across tools. GTmetrix, WebPageTest and PageSpeed Insights use different settings and locations. Each is only comparable with itself.
- Do not chase the score for its own sake. Whether a perfect score is worth pursuing at all is debatable; our view is in whether a 100 PageSpeed score is necessary.
The bigger picture of how speed, metrics and fixes fit together is in our guide to website performance. Once you have a reliable median, that is where to turn for what to do about it.
Frequently asked questions
Is it possible to make the PageSpeed score completely stable?
Not completely, because each lab run is a single load affected by network, test machine and server conditions you cannot control. You can make it much steadier by caching pages properly, reducing third-party scripts, removing randomised elements above the fold and using hosting that responds consistently. A steadier score usually reflects a steadier experience for visitors.
Why is my score lower when I test during the day?
If your site is on shared hosting, the server may be busier during working hours, when more sites on the same machine are getting traffic, so responses take longer. Cache expiry, backups or scheduled tasks running at certain times can also play a part. Testing at similar times of day makes before and after comparisons fairer.
Does a changing lab score affect my Google rankings?
Not directly. The individual lab runs you trigger in PageSpeed Insights are diagnostic tests. Where Google uses page experience signals, they are based on field data from real Chrome users, collected over weeks. Your lab score moving between runs does not change that data; real visitor experience over time does.
How many test runs are enough?
Five runs of the same URL with the same settings is a practical number for most sites, and the median of those five is more reliable than their average, because one unusual run cannot pull it far. For pages with heavy ads or many outside scripts, running a few more helps you see the true middle.
Scores that keep swinging with no obvious cause are often a sign of a server, cache or script problem worth tracing. That tracing is part of the audit in our website speed optimisation service, and the before-and-after comparison at the end is based on repeated runs rather than one lucky screenshot.
Next in this series: Is a 100 PageSpeed Score Necessary for Your Website?
