Why PageSpeed Tests Give Different Results

You run your site through PageSpeed Insights and get 96.

A minute later, you run it again and get 91.

Then you test from another browser and get a different number again.

Nothing on the website changed, so why did the score change?

The short answer is that website speed is not one fixed number. Every test happens under slightly different conditions, and PageSpeed itself shows more than one kind of data.

Once you understand that, the changing scores make much more sense.

PageSpeed has lab data and real-user data

PageSpeed Insights can show two very different types of performance data.

The first is lab data.

This comes from Lighthouse and is created by testing the page in a controlled setup.

The second is field data, which comes from real Chrome users through the Chrome User Experience Report, usually called CrUX.

They answer different questions.

Lab data
↓
How did the page perform in this test?

Field data
↓
How has the page performed for real users?

It is normal for these numbers to be different.

Lab data is one test

A Lighthouse test loads your page under a set of simulated conditions and measures what happens.

It can report things such as:

• First Contentful Paint;
• Largest Contentful Paint;
• Cumulative Layout Shift;
• Total Blocking Time;
• Speed Index.

The final Performance score is calculated from several metrics.

The important part is that this is one test.

If one network request takes a little longer, the result may change.

Real users have different devices

Field data comes from many real visits.

Those users may have:

• new phones;
• old phones;
• fast laptops;
• slow laptops;
• Wi-Fi;
• 5G;
• 4G;
• weak mobile signals;
• cached files;
• empty caches.

That is why field data is usually more useful for understanding the real experience.

According to Google’s PageSpeed documentation, field data is based on real users over a rolling period rather than one single page load.

The test server can be in a different place

PageSpeed tests are run from Google’s infrastructure.

Google notes that the data center used for the test can vary, including locations in North America, Europe, or Asia.

A page hosted close to the test location may respond slightly faster than one hosted farther away.

A CDN reduces this problem, but network routes are never perfectly identical.

Server response time changes

Even a simple page can have a slightly different response time on every request.

For a dynamic site, the difference can be bigger.

The server may need to:

Receive request
↓
Run application code
↓
Query database
↓
Build page
↓
Send response

Maybe the database is busy. Maybe the page was already cached. Maybe another request is using server resources.

Static pages usually have less of this work, but the network itself can still vary.

Third-party scripts are not always consistent

Ads, analytics, chat widgets, video embeds, cookie tools, and social scripts can all affect performance.

They may not load exactly the same way every time.

One test might receive an ad quickly.

Another might wait longer.

One test might hit a cached third-party file.

Another may download it again.

The Lighthouse team lists things such as ads and changing network traffic as common reasons why performance scores can move between tests.

A/B tests can change the page

If your site runs experiments, two page loads may not even receive the same content.

For example:

Visitor A
↓
Hero image A

Visitor B
↓
Video hero B

Those versions can have very different performance.

This is another reason a single Lighthouse number should not be treated as a permanent score for the whole website.

Browser extensions can affect local Lighthouse tests

If you run Lighthouse from Chrome DevTools, extensions can sometimes add scripts or requests to the page.

That can make your local test slower than a clean test.

Try testing in a clean browser profile or Incognito mode with extensions disabled if the results look strange.

Cache state matters

The first visit to a website can be slower because the browser has to download everything.

Later visits may reuse cached files.

For example:

First visit:
HTML
CSS
logo.svg
photo.webp

Second visit:
HTML
CSS        ← cached
logo.svg   ← cached
photo.webp ← cached

Different tools may test with different cache states, so the result can change.

The final score is not a speed in milliseconds

This is one of the biggest misunderstandings.

A Performance score of 90 does not mean your website loads in “90 speed units.”

It is a weighted score based on several measured metrics.

Google explains the calculation in its Lighthouse performance scoring documentation.

Because the score is calculated from several values, a small change in one important metric can move the final number more than you expect.

Do not chase 100

A perfect 100 looks nice, but it should not be the main goal.

I would rather have a site that gets:

94
96
95
93

and feels fast for real users than spend hours trying to force every run to say 100.

Performance tools are useful because they help find problems.

They are not a game score.

Look at the metrics

Instead of only looking at the large green number, check the actual metrics.

For Core Web Vitals, the main ones are:

LCP → Largest Contentful Paint
INP → Interaction to Next Paint
CLS → Cumulative Layout Shift

In simple terms:

LCP tells you how long it takes for the main content to appear.

INP tells you how quickly the page reacts when users interact with it.

CLS tells you whether the layout jumps around.

These are more useful than saying “my site is a 97.”

Field data matters more for real users

Lab data is very useful while working on a site because you can run it whenever you want and see detailed suggestions.

Field data answers a different question: what actually happened to users.

PageSpeed uses real-world CrUX data to show Core Web Vitals when enough data is available.

A small website may not have enough traffic for URL-level field data. In that case, PageSpeed may show origin-level data or no field data at all.

That does not mean anything is broken.

Run more than one test

If one run gives you an unexpected result, run it again.

A better approach is:

Test 1 → 94
Test 2 → 96
Test 3 → 93
Test 4 → 95
Test 5 → 95

Now you have a much better idea of the normal range.

One strange result should not send you into a full rewrite.

Test before and after changes

PageSpeed is especially useful when comparing changes.

For example:

Before image compression:
LCP 3.1 s

After image compression:
LCP 2.0 s

That tells you something useful.

The exact Performance score may still move between runs, but a repeated improvement in the main metric is a strong sign that the change helped.

Test the same page

Do not compare:

Homepage score: 98
Article score: 89

and assume something is wrong.

Different pages may load very different things.

A homepage may contain almost no images.

An article may contain:

• a large hero image;
• code highlighting;
• embeds;
• several photographs.

Compare the same URL before and after a change.

Mobile and desktop are different

PageSpeed has separate mobile and desktop tests for a reason.

A site may get:

Desktop: 100
Mobile: 92

That is normal.

Mobile testing uses slower device and network conditions, so it is usually harder to get the same score.

Do not assume your site became “bad” because mobile scored lower.

What I pay attention to

When I test a site, I usually look at things in this order:

1. Are there real Core Web Vitals problems?
2. Is LCP slow?
3. Is the page moving around because of CLS?
4. Is JavaScript blocking the page?
5. Are images much larger than they need to be?
6. Are third-party scripts doing too much?
7. Is the server response slow?
8. Does the problem happen across several tests?

Only after that do I care about the final score.

A good test process

A simple process looks like this:

Run several tests
↓
Find the repeated problem
↓
Change one thing
↓
Test again
↓
Compare the metrics

Do not change ten things at once if you are trying to learn what helped.

The number is a guide

PageSpeed Insights is a very useful tool, but it is still a test.

The web is messy. Networks change, servers change, third-party services change, and users have thousands of different devices.

So if your score changes from 96 to 93 and back to 95, that does not mean your site is broken.

Look for a pattern. Look at the real metrics. Check field data when it is available.

The goal is not to make PageSpeed happy.

The goal is to make the website fast for people.