Why Your PageSpeed Score Changes Every Time You Test (and Which Number Matters)

You run PageSpeed Insights and get 71. You run it again a minute later and get 58. Nothing on the site changed. This is one of the most common questions we hear, and the honest answer is that the score is a rough lab estimate that was never meant to be precise. The numbers that actually matter for rankings live elsewhere on the same page.

PageSpeed Insights shows two different kinds of data

• Field data, at the top: real measurements from Chrome users who visited your page over the last 28 days, from the Chrome User Experience Report. This is what Google uses.
• Lab data, below it: a single Lighthouse test run from a Google server, emulating a mid-range phone on a slow mobile connection. The 0 to 100 score comes from this.

If your page does not get enough traffic, the field section shows no data for the URL and may fall back to data for your whole domain. Newer and smaller sites often only see lab data.

Why the lab score moves between runs

1. 01Server response time changes from request to request, especially on shared hosting or uncached pages.
2. 02Ads, A/B tests and personalization serve different content each time.
3. 03Third-party scripts load at different speeds and sometimes fail.
4. 04The test machine itself is shared, so available CPU varies slightly between runs.
5. 05Lighthouse simulates a slow network and CPU from a fast connection, and small timing differences get magnified by that simulation.

How the 0 to 100 score is calculated

In Lighthouse 10 and later, the performance score is a weighted blend of five lab metrics. Each metric is converted to a 0 to 100 value on a curve, so small changes near a threshold can swing the total noticeably.

• Total Blocking Time: 30 percent.
• Largest Contentful Paint: 25 percent.
• Cumulative Layout Shift: 25 percent.
• First Contentful Paint: 10 percent.
• Speed Index: 10 percent.

Total Blocking Time carries the most weight and is also the most sensitive to CPU and third-party scripts, which is why scripts are usually the reason scores bounce around.

How to test properly

1. 01Run the same URL at least five times and use the median score, not the best or the worst.
2. 02Test the pages people actually land on, such as product pages, not just the home page.
3. 03Compare mobile with mobile. Mobile scores are always lower because of the simulated slow phone.
4. 04Change one thing at a time and re-test, so you know what made the difference.

for i in 1 2 3 4 5; do
  npx lighthouse https://example.com \
    --only-categories=performance \
    --output=json --quiet --chrome-flags="--headless" \
    | node -e "let s='';process.stdin.on('data',d=>s+=d).on('end',()=>console.log(JSON.parse(s).categories.performance.score*100))"
done

The number that matters

Google's ranking systems use Core Web Vitals field data: LCP, INP and CLS at the 75th percentile of real visits. The lab score is not a ranking factor. A page can score 60 in the lab and still pass all three Core Web Vitals for real users, and the reverse happens too.

Track progress in Search Console

The Core Web Vitals report in Google Search Console groups similar URLs and tells you which groups pass or fail on real data. After deploying a fix, use Start tracking on the affected issue. Google validates over the following 28 days as fresh field data comes in.

LightLoader is designed around field data. The point is passing Core Web Vitals for real visitors, with a better lab score as a side effect, not chasing a perfect 100 on a single run.