Why Your PageSpeed Score Changes Every Time You Test

Short answer: A PageSpeed Insights score changes between runs because each test is a single lab measurement, and small differences in server response time, network conditions, third-party scripts and the test machine move the metrics behind it. Swings of a few points are normal; swings of 10 to 20 points usually point to an unstable server or heavy third-party code. Run the test several times, use the median, and judge real performance by the field data from actual visitors rather than one score.

What the PageSpeed score actually is

The number in the coloured circle at the top of a PageSpeed Insights report is the Lighthouse performance score. It is calculated from a single page load in a controlled lab environment: a Google server loads your page while simulating a mid-range phone on a slow mobile connection, records a set of metrics, and converts them into a score from 0 to 100.

Five metrics feed that score, each with its own weight. In current versions of Lighthouse, Total Blocking Time carries the most weight, followed by Largest Contentful Paint and Cumulative Layout Shift, with First Contentful Paint and Speed Index making up the rest. The exact weights are documented in the Lighthouse performance scoring guide.

Two details explain most of the confusion:

• It is one sample. Every time you press “Analyze”, a new page load happens. Nothing is averaged across runs.
• The scoring curve is not linear. Each metric is mapped onto a curve, so a small change in a metric near a threshold can move the score more than a large change far from it.

Below the lab score, the same report often shows a separate section with field data from real Chrome users over the previous 28 days. That section does not jump around between runs, and it is the part that reflects what visitors actually experience. If you are not sure which part of the report is which, our guide on reading a PageSpeed Insights report walks through every section.

The most common reasons the score moves

Lighthouse’s own documentation lists several sources of variability. For typical business websites, these are the ones that matter most:

1. Server response time. If your server sometimes answers in 200 ms and sometimes in 1.5 seconds, every metric that follows shifts with it. Shared hosting under load, cold caches and slow database queries are the usual causes.
2. Caching state. A page served from a full-page cache is fast; the same page rebuilt by the CMS after the cache expired can be several times slower. Tests that hit an uncached page score lower.
3. Third-party scripts. Ads, chat widgets, tag managers, A/B testing tools and embedded social feeds load different content and respond at different speeds on every visit.
4. Network path. The test machine reaches your server through the internet, and routing, CDN edge selection and DNS lookups vary slightly between runs.
5. Test machine load. Lab tests run on shared infrastructure. Lighthouse tries to correct for CPU differences, but it cannot remove them entirely, which mostly affects Total Blocking Time.
6. Page changes. Rotating banners, personalised content, cookie banners and lazy-loaded elements can make two loads of the same URL genuinely different.

Because Total Blocking Time has the largest weight and is sensitive to CPU conditions, sites with a lot of JavaScript tend to see the biggest swings. A page with little script and a fast, cached response usually scores within a few points each time.

How much variation is normal?

There is no official “acceptable” range, but experience gives useful rules of thumb:

The key is to look at which metric changes. If only Total Blocking Time moves, the cause is script execution. If First Contentful Paint and Largest Contentful Paint move together, the cause is usually the server or the network, because everything starts later.

How to measure speed reliably

You do not need special tools to get stable numbers. You need a consistent method:

1. Run the test at least three to five times and note the performance score and the main metrics for each run.
2. Use the median, not the best result. The best run shows what is possible, not what visitors usually get. The median is far more honest.
3. Warm the cache first. Load the page once in a normal browser before testing, so you measure the cached state that most visitors see. Then, separately, test once after clearing the cache to know the worst case.
4. Test the same URL at a similar time of day. Hosting that is slower in the evening will give lower scores in the evening.
5. Change one thing at a time. If you optimise images and remove a plugin on the same day, you will not know which change helped.
6. Record results. A simple spreadsheet with date, URL, median score, LCP, TBT and CLS turns noise into a trend.

Different tools also give different numbers, because they use different devices, connections and locations. Compare results from the same tool over time rather than one tool against another. Our comparison of PageSpeed Insights, GTmetrix and WebPageTest explains why their numbers rarely match.

Lab score versus field data: which one counts

The lab score is a diagnostic tool. It is excellent for finding problems and checking whether a fix made a difference, because you can rerun it whenever you like. But it is a simulation of one device on one connection.

Field data comes from real Chrome users who visited your site. It is reported for the 75th percentile of visits over 28 days, which means three out of four visits were at least that fast. This is the data Google uses for its Core Web Vitals assessment, and it changes slowly because it is an average over weeks.

• If the lab score is low but field data passes, your real visitors are mostly fine. Improve what you can, but there is no emergency.
• If the lab score is high but field data fails, real visitors have slower devices, slower connections or different pages than your test suggests. Trust the field data.
• If your site has too little traffic to show field data, the lab score and your own repeated measurements are the best you have.

After a fix, lab results improve immediately, while field data needs up to four weeks to catch up fully. The Core Web Vitals report in Search Console shows the same field data grouped by URL type, which helps you see whether whole sections of the site are affected.

Fixing the causes of unstable scores

Large swings are not just an annoyance in reports. They often mean some real visitors get a much slower page than others. These fixes reduce both the swings and the slow visits:

• Stabilise server response time. Enable full-page caching, check that cache hit rates are high, and move off overloaded hosting if response times vary widely. See how to reduce server response time for the full list.
• Delay or remove third-party scripts. Load chat widgets, heatmaps and social embeds after user interaction or after the page is ready. Remove tools nobody uses any more.
• Reduce main-thread work. Less JavaScript means lower and steadier Total Blocking Time. Defer scripts that are not needed for the first view.
• Reserve space for dynamic content. Banners and embeds that appear late push content down and change Cumulative Layout Shift from run to run.
• Serve images at a fixed, optimised size. A hero image that sometimes arrives from cache and sometimes from a slow origin makes Largest Contentful Paint unpredictable.

When the page does less and depends less on outside services, every run looks more like the last one.

Mistakes to avoid when chasing the score

• Retesting until you get a good number. A screenshot of the best run proves nothing to a client or a manager. Report the median.
• Optimising for the score instead of visitors. Tricks that hide content from the test or delay everything until after the measurement do not make the site faster for people.
• Testing only the home page. Product pages, blog posts and checkout often behave very differently. Test one representative URL for each template.
• Panicking over one bad run. A single low score after a good streak is usually noise. Three low scores in a row are a signal.
• Treating 100 as the goal. A consistently good score with passing field data matters more than occasionally reaching 100.

How Site AI Audit handles speed measurements

Site AI Audit includes Google PageSpeed data in its report: the mobile performance score and Core Web Vitals such as LCP, CLS and INP, next to server response time, compression and page weight. Each finding is explained in plain words and ranked by impact, so you can see whether a speed issue deserves attention before SEO, SSL or e-mail problems. Because a single measurement can be noisy, it helps to re-check after each fix and watch the trend; paid plans include re-checks and weekly monitoring. You can run a free check of your website to see where it stands today.

Related reading

• How to Read a PageSpeed Insights Report Without Guesswork
• Website Speed Monitoring: Catch Slowdowns Before Customers Do
• How Third-Party Scripts Slow Down Your Website (and Fixes)
• Total Blocking Time Explained: What It Means and How to Cut It

The bottom line

A changing PageSpeed score is normal because every run is a single lab measurement. Small swings are noise; big swings point to unstable hosting or heavy scripts. Run several tests, use the median, change one thing at a time, and judge real performance by field data from your visitors.

FAQ

Why does my PageSpeed score change when I have not changed anything?

Each test is a new page load, and server response time, network routing, third-party scripts and the test machine’s load differ slightly every time. These differences change the metrics, and the metrics change the score.

How many times should I run PageSpeed Insights?

Run it at least three to five times for the same URL and use the median result. This smooths out random noise and gives a number you can compare fairly after making changes.

Is the mobile or desktop score more important?

The mobile score is usually more important, because it simulates slower devices and networks and most sites get much of their traffic from phones. Google also indexes sites primarily using the mobile version.

Does a low PageSpeed score hurt my Google rankings?

The lab score itself is not a ranking factor. Google uses field data from real users through Core Web Vitals as one of many signals, and relevance and content quality matter far more.

Why is my score different in GTmetrix and PageSpeed Insights?

The tools use different test locations, devices, connection speeds and scoring settings. Their numbers are not directly comparable, so track each tool against its own earlier results.