Someone ran your homepage through PageSpeed Insights and sent you a screenshot: a red 41 on mobile. Now there’s a question mark over the website, and possibly a quote to “get it to 90”.
Before acting on that number, know what you’re looking at. A PageSpeed Insights report has two halves: how the page performs for real visitors, and a single simulated test that is useful for finding causes but a poor target in its own right.
The short answer
- The report combines two kinds of data: field data from real Chrome users over the previous 28 days, then a Lighthouse lab test scored from 0 to 100.
- Judge the page on the field data. If the Core Web Vitals assessment says “Passed”, most real visitors are getting a good experience, whatever the lab score.
- Use the lab score to diagnose, not as a goal. Chasing 100 rarely changes anything visitors notice.
- Mobile scores are lower by design, because the lab test simulates a mid-range phone on a slow connection.
- Scores vary between runs, so test several times and use the middle result.
Field data vs lab data: the two halves of the report
The report opens on the Mobile tab, with Desktop beside it. Both have the same two sections:
| Compared on | Field data (top) | Lab data (below) |
|---|---|---|
| Source | The Chrome UX Report (CrUX): real visits by Chrome users | Lighthouse: one page load on Google’s servers |
| Conditions | Your visitors’ real devices and networks | A simulated mid-range phone on a slow connection (a faster desktop on the Desktop tab) |
| Period | The previous 28 days, rolling | The moment you run the test |
| Metrics | LCP, INP and CLS, plus FCP and TTFB | FCP, LCP, TBT, CLS and Speed Index, rolled into one score |
| Best for | Judging what visitors experience | Finding causes and testing fixes |
When the two disagree, the field data wins. It’s what visitors actually experienced, and the same CrUX data feeds Search Console’s Core Web Vitals report.
Reading the field data
The Core Web Vitals assessment
First comes a verdict: Passed or Failed. To pass, all three Core Web Vitals must be good at the 75th percentile, using Google’s published thresholds:
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | How quickly the main content appears | 2.5 s or less | Over 4 s |
| Interaction to Next Paint (INP) | How quickly the page responds to taps, clicks and typing | 200 ms or less | Over 500 ms |
| Cumulative Layout Shift (CLS) | How much the layout jumps around | 0.1 or less | Over 0.25 |
Anything in between is rated “needs improvement”. According to Google’s PageSpeed Insights documentation, a page without enough INP data is judged on LCP and CLS alone. First Contentful Paint and Time to First Byte appear too. They aren’t Core Web Vitals, but a slow TTFB points at the server first. For each metric and its usual causes, see Core Web Vitals in plain English.
The bars, the 75th percentile and the origin toggle
Each metric shows its 75th percentile: three in four visits were at least that fast (or, for CLS, that stable). A bar beneath splits visits into good, needs improvement and poor. A page can pass while up to a quarter of visits miss the mark, so note the red slice and which metric sits closest to its threshold: that one will fail first.
A toggle switches between this URL and the origin (every page on the site combined). A light homepage can pass while heavier pages drag the origin down, so check both.
Field data has limits. It covers only Chrome on desktop and Android, for users who share usage statistics, so iPhone, Safari and Firefox visits are missing. It changes slowly, and it tells you that something is slow, not why.
Reading the lab data and the Performance score
How the Lighthouse performance score works
The lower section, headed “Diagnose performance issues”, is a Lighthouse test. It loads the page once, scores five metrics against data from real websites, then combines them with fixed weights. Since Lighthouse 10, Total Blocking Time counts for 30%, Largest Contentful Paint and Cumulative Layout Shift for 25% each, and First Contentful Paint and Speed Index for 10% each.
Scores of 0–49 are poor (red), 50–89 need improvement (orange) and 90–100 are good (green). The curve flattens near the top: Google’s Lighthouse documentation notes that going from 99 to 100 takes about as much metric improvement as going from 90 to 94. Lifting a key page from 35 to 75 is often worth the effort; from 92 to 100, rarely.
Why Total Blocking Time stands in for INP
A lab test has no visitor tapping buttons, so it can’t measure INP. Total Blocking Time is its stand-in: how much time long tasks blocked the browser’s main thread during loading. High TBT warns that the page will feel sluggish. Low TBT is no guarantee, because INP also covers later interactions such as opening a menu.
The treemap and the other scores
The View Treemap button shows the page’s JavaScript file by file, including how much went unused: often the first sign that a plugin loads its code on every page.
The Accessibility, Best Practices and SEO scores are automated checks of the basics. A perfect SEO score doesn’t mean the page ranks, and automated accessibility checks catch only some barriers, as our guide to accessibility audits and automated checkers explains.
Why your mobile PageSpeed score is lower
If your PageSpeed score is low on phones but fine on a laptop, this is why. The mobile test emulates a mid-range phone on a slow connection, with the processor deliberately slowed. This is simulated throttling: Lighthouse loads the page on a fast connection, then calculates how long it would have taken on the slow one. The desktop test assumes a faster connection and no processor slowdown.
The slowed processor is why JavaScript from page builders, sliders and tracking tags hurts so much on mobile: running scripts is often costlier than downloading them.
So compare the mobile lab result with the mobile field data:
- Field data passes, lab score is low: most real visitors are fine. Treat the lab list as future-proofing, not an emergency.
- Field data fails too: mobile is where the work is, and the lab list shows where to start.
- No field data: the lab result is your best evidence for now (see low-traffic pages below).
Why the score changes every time you run it
The same page can score differently on every run, because:
- Server response varies, especially on busy shared hosting or just after a cache is cleared.
- Third-party content changes. Ads, A/B tests, chat widgets and tag managers can load different things each time.
- Test conditions vary. The test machine and the network route to your server differ slightly on every run.
- Lighthouse itself changes. The report states which version it used, and new versions can change what is measured, so an old score may not be comparable.
For reliable figures, load the page once to warm the cache, then run the test three to five times and use the middle result. Record the metric values, not just the score, and treat a change of a few points as noise.
Which PageSpeed Insights suggestions to fix first
Below the scores comes a list of findings. At the time of writing (September 2026), PageSpeed Insights groups them as Insights and Diagnostics; older reports and guides call the first group Opportunities. Each item points at a cause, often with an estimated saving.
Start from the metric that fails
If field data shows LCP failing, only items affecting LCP matter for now, and the metric filters above the list cut it down fast. With no field data, start with the weakest lab metric.
Find the LCP element and where its time goes
The report names the Largest Contentful Paint element, usually a hero image, slider or large heading, and splits its loading time into four parts. The biggest part tells you where to look:
| LCP part | When it’s the biggest | Where to look first |
|---|---|---|
| Time to first byte | The server is slow to respond | Hosting, page caching, a CDN |
| Resource load delay | The browser found the main image late | Lazy-loading on the hero, images set in CSS, JavaScript sliders |
| Resource load duration | The image takes too long to download | File size, format and dimensions |
| Element render delay | The content arrived but couldn’t be shown | Render-blocking CSS and JavaScript, web fonts |
A text heading has nothing to download, so only the first and last rows apply. Our guides to choosing hosting for speed, image optimisation and render-blocking resources take each row further.
Rank the rest by size, reach and control
- How big is the saving? Estimates are rough, but seconds come before milliseconds.
- How many pages share the cause? A fix in the theme, a plugin or the hosting improves every page at once.
- Do you control it? Your own files you can change. A third-party widget you can only keep, delay or remove; our guide to third-party scripts and site speed helps with that call.
You can usually leave alone items with tiny savings, cache warnings about files hosted by someone else (a map or video embed, say), and the last few points before 100.
Then fix, re-test and let the field data confirm it. If the list keeps pointing at the theme, page builder or hosting, our guide to finding out why a website is slow ends with how to choose between optimising and rebuilding.
When a page has too little traffic for field data
New sites, niche B2B pages and many individual articles show a message that the Chrome UX Report lacks enough real-world data. That isn’t a fault; you just need other evidence:
- Switch to origin data. The whole site may have enough traffic even if the page doesn’t.
- Check Search Console. Its Core Web Vitals report groups similar URLs, so quieter pages can appear as part of a group.
- Test templates, not every page. Track one page of each type (home, service, article, landing page) over time.
- Try a real phone. Load key pages on a mid-range phone over mobile data.
- Collect your own field data. Google’s open-source web-vitals JavaScript library measures LCP, INP and CLS from your visitors and can send them to your analytics (check its documentation for browser support).
Our website speed optimisation guide shows how these checks fit into a complete plan.
Frequently asked questions
Do I need a PageSpeed Insights score of 100?
No. Anything from 90 up is already in Lighthouse’s good band. Passing Core Web Vitals in the field data is a far better goal than a perfect lab score.
Does the PageSpeed Insights score affect Google rankings?
Google says its ranking systems use Core Web Vitals, which it describes as measures of real-world user experience: the field data, not the lab score. It also says it still shows the most relevant content when page experience is poor, so speed counts most when competing pages are equally useful.
Why do other speed tools give a different score?
Each uses its own device, connection, location and settings, and Lighthouse in Chrome’s developer tools runs on your own computer. Pick one tool and compare its results over time, not across tools.
How long do fixes take to show in the report?
The lab section reflects a fix as soon as it is live and caches are cleared. Field data uses a rolling 28-day window, so improvements appear gradually and take about four weeks to show in full.
What to do next
Read a PageSpeed Insights report in order: field data first, then the lab metrics, then the fixes that match what actually fails. The score is a symptom, not a diagnosis.
Make testing a routine rather than a one-off scare: check your main templates monthly and after every new plugin, script or redesign. Our website maintenance checklist shows where that fits alongside updates and backups.
If you’d rather not work through the report alone, ask for a free website audit. Speed is one of the areas it covers, and we’ll tell you which items on that list are worth fixing now and which can wait.