You run PageSpeed Insights and get 62. You run it again a minute later and get 71. A client sends you a screenshot showing 48. Nothing on the site changed. This is normal, and once you understand what the score is (and is not), it stops being stressful. This post explains where the number comes from, why it moves, and which parts of the report deserve your attention.
Key takeaways
- The PageSpeed score comes from one Lighthouse lab test, while Google's page experience assessment uses Core Web Vitals field data from real users.
- Scores vary between runs because of ads, A/B tests, server response times and network routing, so run the test several times and use the median.
- Mobile scores are lower because Lighthouse applies a 4x CPU slowdown and a throttled network to mimic a mid-range phone.
- Total Blocking Time carries 30% of the score, so heavy JavaScript can pull it down even when a page looks fast.
Two reports on one page
PageSpeed Insights (PSI) shows two completely different kinds of data, and mixing them up causes most of the confusion.
| Field data (top section) | Lab data (performance score) | |
|---|---|---|
| Source | Real Chrome users, via the Chrome User Experience Report (CrUX) | One simulated page load by Lighthouse |
| Time span | Previous 28 days, updated daily | Right now, single run |
| Metrics | LCP, INP, CLS (Core Web Vitals), plus FCP and TTFB | FCP, LCP, TBT, CLS, Speed Index |
| Result | Pass/fail per metric at the 75th percentile | A 0-100 score |
| Used by Google for page experience | Yes | No |
The top section ("Discover what your real users are experiencing") is the one that reflects your actual visitors. The big colored circle is a lab score from one test.
If your page does not have enough traffic for CrUX, PSI shows origin-level field data for the whole site instead, or no field data at all.
How the lab score is calculated
The Lighthouse performance score is a weighted average of five lab metrics. Each metric's raw value is converted to a 0-100 score using a curve based on real-world website data, then weighted:
| Metric | Weight |
|---|---|
| Total Blocking Time (TBT) | 30% |
| Largest Contentful Paint (LCP) | 25% |
| Cumulative Layout Shift (CLS) | 25% |
| First Contentful Paint (FCP) | 10% |
| Speed Index | 10% |
The color bands:
- 90-100 good (green)
- 50-89 needs improvement (orange)
- 0-49 poor (red)
Two consequences worth knowing:
- TBT carries the most weight, and it is driven by JavaScript. Heavy scripts on a slow emulated CPU can pull the score down hard even when the page looks fast.
- INP is not in the score at all, because a lab test does not interact with the page. TBT acts as a stand-in.
Lighthouse also publishes a scoring calculator that lets you plug in metric values and see how the score changes, which is useful for setting realistic targets.
Why the score fluctuates
Lighthouse's own documentation lists the sources of run-to-run variability. The ones that affect PSI most:
- Page nondeterminism. Ads that change on every load, A/B tests, rotating hero images, chat widgets that load at different speeds. This is often the biggest factor, and it is in your control.
- Network conditions between the test server and your server, including routing changes.
- Your server's response time varying under load. A cache miss on one run and a cache hit on the next can swing LCP noticeably.
- Browser nondeterminism. The browser does not schedule work identically every time.
- Test location. PSI runs from Google data centers, and the location used can differ between runs.
If you run Lighthouse in your own Chrome DevTools, add more variables: your machine's speed, other open tabs, browser extensions injecting scripts, and antivirus software.
How to get a number you can trust
- Run it several times and use the median. Lighthouse's documentation notes the median of five runs is about twice as stable as a single run.
- Remove your own randomness where possible: disable A/B tests for testing, or test a page without rotating ads.
- Compare like with like. Same URL, same tool, same device setting. A DevTools score on a fast laptop is not comparable to a PSI score.
- Track trends, not single numbers. Scheduled re-scans over weeks tell you far more than one test.
Why mobile scores lower than desktop
The mobile test deliberately simulates a much slower experience:
- CPU slowdown. Lighthouse applies a 4x CPU slowdown to mimic a mid-range phone. JavaScript that runs in 200 ms on your laptop takes far longer, which inflates TBT.
- Throttled network. Lighthouse's default mobile throttling simulates roughly 150 ms of latency and about 1.6 Mbps download speed, much slower than typical broadband.
- Smaller viewport, which can change which element is the LCP element.
Desktop runs with an emulated wired connection and no heavy CPU throttling. So a 95 on desktop and 60 on mobile is common and does not mean something is broken. Google evaluates mobile and desktop field data separately. Check your analytics for the device split; if most visitors arrive on phones, as they do for many local businesses, the mobile result is the one to prioritize.
Why your score and your field data disagree
| You see | What it usually means |
|---|---|
| Low lab score, field data passing | Real visitors have faster devices or networks than the throttled test, or hit cached pages. Your users are fine; the lab is harsher. |
| High lab score, field data failing | Real users experience things the lab missed: slow interactions (INP), late ads and banners (CLS), distant regions, slower phones. |
| Field data missing | Not enough Chrome traffic in CrUX. Lab data and your own monitoring are all you have. |
When they conflict, field data answers "do my visitors have a problem?" and lab data helps answer "why?".
What actually matters
The score is a diagnostic summary, not a business metric. A few principles:
- Core Web Vitals in field data come first. Passing LCP, INP and CLS for real users is what Google's page experience assessment uses. See Core Web Vitals explained.
- Read the metrics, not the circle. "Score went from 70 to 64" tells you nothing. "LCP went from 2.1 s to 3.4 s" tells you where to look.
- Use the diagnostics. The opportunities and diagnostics sections point to specific causes: render-blocking resources, unoptimized images, unused JavaScript, long main-thread tasks.
- Chasing 100 rarely pays off. Moving from 85 to 100 often means removing analytics, chat or marketing tools the business relies on. Moving from 35 to 75 usually means fixing real problems users feel.
- Watch trends after changes. Field data takes up to 28 days to fully reflect a fix.
A sensible workflow
- Check field data for mobile. Note which Core Web Vital fails, if any.
- Run the lab test three to five times and take the median score and metrics.
- Open the diagnostics for the failing metric and fix the top item. Our guides on LCP, INP and render-blocking resources cover the common ones.
- Re-test in the lab to confirm, then watch field data over the following weeks.
Frequently asked questions
Why is my PageSpeed score different from GTmetrix or other tools?
Each tool uses different test locations, devices, network throttling and sometimes different metrics or weights. Scores from different tools are not comparable to each other. Pick one tool for tracking and use the same settings each time.
Does a low PageSpeed score hurt my Google rankings?
Google's page experience signals use Core Web Vitals field data from real users, not the Lighthouse lab score. A low lab score can point to problems that also affect real users, but the score itself is not what Google evaluates.
Why does my score change when I have not changed anything?
Ads, A/B tests, third-party scripts, server response times and network routing all vary between runs. Run the test several times and use the median, and treat changes of a few points as noise.
What is a good PageSpeed Insights score?
Lighthouse rates 90 and above as good and 50-89 as needing improvement. For a typical small-business site, passing Core Web Vitals in field data matters more than any particular lab score.
What to do next
Stop comparing single screenshots. Pick your five most important pages, record the median mobile metrics, and fix the worst metric first. You can run a free audit to get the PageSpeed score and Core Web Vitals in one report, and paid plans add history and scheduled re-scans so you can see trends instead of one-off numbers (see plans).
Related reading
- GTmetrix vs PageSpeed Insights: Data, Locations and Scoring: GTmetrix vs PageSpeed Insights compared: field vs lab data, test locations, throttling, how each score is built, and which tool to trust for which job.
- How to Check Website Speed: Free Tools and What the Numbers Mean: How to check website speed with a free page speed test, read LCP, INP and CLS correctly, and test the whole site, not just one page. Free tools compared.
Sources
Written by the MakeItFlow team
We build the website audit these guides are based on. Every fact is checked against the primary sources listed above . How we research and check
Check your own site in 30 seconds
Run a free audit covering speed, SEO, DNS, email authentication and security headers — and get a prioritised fix list.
