PageSpeed Insights explained: how to read every number
·4 min read
PageSpeed Insights shows two different reports on one page. The top half is field data, what real Chrome users experienced on your page over the last 28 days, and it decides whether you pass the Core Web Vitals assessment. The bottom half is one Lighthouse lab test, which produces the 0 to 100 performance score and the list of fixes.
Read the top half to know whether you have a problem. Read the bottom half to find the cause.
Field data and the Core Web Vitals assessment
The first section shows whether real visitors got a good experience. The data comes from the Chrome User Experience Report (CrUX), and PSI shows the 75th percentile of each metric over a rolling 28-day window, per Google's PSI documentation.
The assessment passes only if LCP, INP and CLS are all good at the 75th percentile. If INP lacks enough data, LCP and CLS decide it alone. If LCP or CLS lacks data, PSI cannot assess the page.
| Metric | Good | Poor |
|---|---|---|
| LCP | 2.5 s or less | Over 4 s |
| INP | 200 ms or less | Over 500 ms |
| CLS | 0.1 or less | Over 0.25 |
FCP and TTFB appear too but do not count toward the pass. For what each of the three vitals measures and which fixes move them, read our Core Web Vitals guide.
This URL vs origin
The toggle above the field data switches between "This URL" and "Origin". URL data covers only the page you tested. Origin data covers every page on the domain mixed together.
PSI shows URL data when that page has enough CrUX samples and falls back to origin data when it does not. A low-traffic blog post often shows origin numbers, so a slow checkout page can drag down a fast article's result. If neither has data, PSI shows no field section at all and you only have the lab test.
The performance score and how Lighthouse weights it
The 0 to 100 score comes only from the lab run. Field data never feeds into it. Lighthouse measures five metrics, converts each to a 0 to 100 score on a curve, then takes a weighted average. These are the weights from Chrome's scoring documentation.
| Lab metric | Weight | What it measures |
|---|---|---|
| Total Blocking Time (TBT) | 30% | Time the main thread was blocked by long tasks after first paint |
| Largest Contentful Paint (LCP) | 25% | When the largest image or text block rendered |
| Cumulative Layout Shift (CLS) | 25% | How much visible content moved while loading |
| First Contentful Paint (FCP) | 10% | When the first text or image appeared |
| Speed Index | 10% | How fast the visible area filled in, averaged over the load |
90 to 100 is green, 50 to 89 orange and 0 to 49 red.
TBT carries the most weight. The lab has no INP because nobody clicks anything in a lab test, so TBT stands in for responsiveness, and heavy JavaScript costs you more score than a slow hero image. FCP and Speed Index together are only 20%, so shaving 300 ms off first paint barely moves the number.
Google's page experience signals use field data, not this score. A page can score 55 and pass Core Web Vitals because its real users have fast phones and warm caches. Use the score to compare builds of the same page, not as a target. If LCP is the metric failing, how to improve LCP breaks it into subparts.
Insights and diagnostics
Below the metrics, PSI lists what Lighthouse found wrong. Since Lighthouse 13 in October 2025, the old audits such as "Properly size images" and "Eliminate render-blocking resources" are merged into insights like "Improve image delivery", "Render blocking requests" and "LCP breakdown", per the Lighthouse 13 release notes. Google says the change did not alter how the score is calculated.
Read them in this order:
- Expand the LCP breakdown insight first. It shows whether your LCP time goes to server response, discovery of the image or rendering.
- Look at insights with estimated savings in milliseconds and sort by size. Ignore anything under 100 ms.
- Treat diagnostics as context, not a to-do list. No single diagnostic is a score input.
The savings are simulated estimates. Fixing an item rarely returns the full figure, and some items overlap.
Why the PageSpeed Insights score changes run to run
Test the same page three times and you can get 71, 64 and 78. Google's docs list the causes as network availability, client hardware availability and resource contention on the test machine. Chrome's scoring docs add A/B tests, rotating ads and routing changes.
Run the test three to five times and take the median. Five points is noise. A drop of 20 after a deploy is a signal.
Mobile and desktop are separate tests. Mobile emulates a mid-tier phone on a throttled mobile network, and desktop emulates a desktop on a wired connection. Desktop also uses its own scoring curves since Lighthouse 6, so the two scores are not comparable. Prioritize the mobile field data, because Google indexes the mobile version of your site.
Check your Core Web Vitals on any page
Our Core Web Vitals Snapshot calls the PageSpeed Insights API for one public URL, mobile or desktop, and splits the answer the way this post does. Field LCP, INP and CLS come first and say whether they cover the URL or the whole origin. Lab LCP, CLS, FCP, TBT, TTFB, Speed Index and the performance score follow, with up to eight insights ranked by estimated savings and the Lighthouse accessibility score.
When Google has no field record for the URL or origin, the tool says so instead of filling the gap with lab numbers. It tests one URL per run, not a list. Each run costs 20 credits.