Why does your PageSpeed Insights score change every time you run it?

Your PageSpeed Insights score changes every time you run it because each test is a fresh simulation rather than a stored measurement. Lighthouse loads your page on Google’s hardware over a deliberately throttled connection, and network routing, server response time and processor contention all shift between runs, moving the score with them.

A fifteen-point swing on a page you haven’t touched since breakfast is unsettling, and the instinct is to decide that one of the two runs must be broken. Neither is. The question worth answering is which number on that report you should act on, because most people spend a weekend chasing the wrong one.

Why does the same page score 90 one minute and 61 the next?

Because the performance score leans hardest on the metric most sensitive to whatever else is happening on the machine running the test. Google’s Lighthouse scoring documentation weights Total Blocking Time at 30% of the performance score, Largest Contentful Paint and Cumulative Layout Shift at 25% each, and First Contentful Paint and Speed Index at 10% each. Total Blocking Time measures how long the main thread stayed tied up. A busy test machine inflates it.

The test conditions are fixed. The world around them is not. Lighthouse throttles to 1.6 Mbps down, 750 Kbps up and 150 ms of latency, with a 4x processor slowdown, and PageSpeed Insights runs on those default throttling settings. None of that pins down the route your server is reached by, how loaded that server happens to be at nine on a Tuesday evening, or which ad creative your page pulled in this time.

Then there is the curve. Lighthouse maps each raw metric onto a 0 to 100 scale through a log-normal distribution, so points are not spread evenly across seconds, and a page whose Largest Contentful Paint hovers near a boundary can shed ten points to three hundred milliseconds that would have cost it almost nothing further up the scale.

Which number should you fix, the lab score or the field data?

Fix the field data, and use the lab score to work out what to fix. PageSpeed Insights stacks two different things on one page: real-user measurements collected from Chrome over a trailing 28-day window at the top, and one simulated load at the bottom. Only the first describes your visitors.

They are not two readings of the same thing anyway. The field section reports Interaction to Next Paint and Time to First Byte, neither of which a lab run can produce, because nobody clicked anything and nothing was measured from a real network. The lab section reports Total Blocking Time and Speed Index, which do not exist in real-user data at all. Raise the mismatch in Google’s own Chrome UX Report discussion group and an engineer there will tell you the same thing: the real-user section is what matters, and the lab section is there to explain it.

Why does Search Console say your Core Web Vitals are fine when PageSpeed Insights says 48?

Because the Core Web Vitals report in Search Console is built from field data only, and 48 is a lab score. They are allowed to disagree, and it is not a sign that one of them is broken. Your actual visitors use better phones than Lighthouse emulates, sit on faster connections than 1.6 Mbps, and plenty of them arrive with your CSS and fonts already cached.

A page passes Core Web Vitals when the 75th percentile of real loads comes in at 2.5 seconds or less for Largest Contentful Paint, 200 milliseconds or less for Interaction to Next Paint, and 0.1 or less for Cumulative Layout Shift, measured separately for mobile and desktop. Interaction to Next Paint replaced First Input Delay in 2024, so a guide still telling you to watch FID is out of date. Green in Search Console means your users are fine. A poor lab score sitting next to it means the page is fragile on a slow device, which is worth knowing and is not an emergency.

What if PageSpeed Insights shows no real-user data for your page at all?

Then your site does not have enough Chrome traffic to qualify, and the lab score is the only number you are going to get. PageSpeed Insights looks for your specific URL first, falls back to origin-level data covering the whole site, and shows nothing when that comes up empty as well. Small sites hit this constantly.

This is the genuinely maddening version of the problem, because you are left watching a figure move with nothing to check it against, and Search Console’s Core Web Vitals report will be just as blank for the same reason. Work relatively instead. Test the page before a change and again after it, on the same day, and compare the audit list rather than the headline number.

How many times should you run the test before you believe the number?

Five, and take the median. Google’s Lighthouse variability documentation states that the median score of five runs is twice as stable as a single run, and it names seven separate sources of variance, rating how likely each one is inside PageSpeed Insights specifically. A single run is a sample of one.

What Google has never published is how far a score is expected to drift between runs on the same page. So the tidy rule you have read somewhere, the one that says five points either way is normal, was invented by whoever wrote it. The Page Speed Test calls the same PageSpeed Insights API and returns the mobile and desktop runs side by side, which makes taking five samples less tedious than doing it by hand. It caches each result for two minutes, so an immediate re-run hands back the identical number instead of a second sample.

Which causes of a moving score are actually your site’s fault?

Most of the swing is environmental. Four causes are yours, and separating them out is the difference between fixing something and refreshing a tab.

• Third-party scripts - Ad slots, chat widgets and testing tools fetch different payloads on different runs, and all of them land on the main thread that Total Blocking Time measures.
• Server response time - Shared hosting that answers in 200 ms while idle and 900 ms under load will produce two very different scores for identical HTML.
• Redirect hops - A URL that answers on http, redirects to https, then redirects again to the www version is spending two extra round trips before the HTML starts arriving. The Redirect Checker lists every hop, so you can see whether you are paying that on each test.
• Cache state - A page that only performs while a full-page cache is warm scores well right after you visit it and badly once that cache expires.

Does the PageSpeed score itself affect your Google rankings?

No. There is no 0 to 100 Lighthouse score anywhere in Google’s ranking systems, and chasing a green 100 is a hobby rather than an SEO task. According to Google’s page experience documentation there is no single page experience signal, and good results in Search Console or a third-party tool do not guarantee that a page ranks well.

Real-user Core Web Vitals data is used, as one consideration among many. A page that loads in 1.8 seconds and answers the question badly still loses to one that loads in 3 seconds and answers it properly. Speed breaks ties. It does not make you the right result.

Final Thoughts

Stop refreshing. Take the median of five runs, read the opportunities list rather than the number sitting above it, and where you have real-user data, optimise against that instead. The score was built as a diagnostic, and it makes a poor scoreboard.