How to read a PageSpeed Insights report

A PageSpeed Insights report has two halves: real-user field data up the top, a simulated lab test below. Read the field data first, because that is the part Google actually ranks on - then use the lab "Opportunities" list as your to-do list for fixing it. Almost everyone does this backwards, fixating on the big coloured 0–100 score at the bottom, which is the half that matters least and changes every time you press the button.

The two halves of the report

Open Google PageSpeed Insights, paste in a URL, and the result that comes back is two completely different kinds of measurement stacked on one page. They look similar. They are not.

The top section - headed "Discover what your real users are experiencing" - is field data. It is built from real Chrome visitors who loaded your page over the previous 28 days, pulled from the Chrome User Experience Report. These are actual people on actual phones and connections, and this is the Core Web Vitals assessment Google uses as a ranking signal.

The bottom section is lab data: one simulated Lighthouse run, performed in a controlled environment the instant you pressed the button. It produces the 0–100 score, plus the "Opportunities" and "Diagnostics" lists. No real visitor was involved.

The distinction between lab data vs field data is the single most useful thing to understand about this tool. Field data tells you whether you have a problem. Lab data tells you what to do about it. Confusing the two is how businesses spend a fortnight chasing a 90-something score while the page Google sees still fails.

Reading the field data

Scroll to the top section and look for one line above everything else: "Passed the Core Web Vitals assessment" or "Failed". That single pass/fail is the headline. It is the closest thing on the page to "does Google think this page is fast enough", and it is the first thing to action.

Below it sit the individual metrics, each with a real-world value and a colour:

• LCP (Largest Contentful Paint) - how long until the biggest thing on screen (usually your hero image or headline) has loaded. A good LCP is 2.5 seconds or less for 75% of visits. This is the metric that most often fails for small-business sites, and usually the one to fix first.
• INP (Interaction to Next Paint) - how quickly the page responds when someone taps or clicks. Green is 200 milliseconds or less.
• CLS (Cumulative Layout Shift) - how much the page jumps around as it loads. Green is 0.1 or less. This is the one where a late-loading ad or banner shoves the text down just as someone goes to tap a link.

Each metric is judged against the 75th percentile of your visitors - so "green" means at least 3 in 4 real visits were good. The assessment passes only when LCP, INP and CLS are all green. One amber or red metric fails the whole thing. (If you want the longer version of what each of these measures and why Google chose them, we have a plain-English Core Web Vitals walkthrough and a primer on what Core Web Vitals are.)

Two things to watch. First, a low-traffic page may show "not enough data" instead of a field assessment - Chrome needs a minimum number of real visits over the 28 days to report. That is not a failure; it just means you fall back to the lab data below. Second, the field data lags by up to 28 days, so a fix you shipped yesterday will not show here yet. Re-check it a month later.

Reading the lab data

Now the bottom half - and the big number people came for. The Performance score out of 100 is a lab-only figure. It is calculated from that one simulated Lighthouse run, weighted across a handful of lab metrics, and it is the part of the report most worth not obsessing over.

It jumps around because the run is sensitive to the conditions of that exact moment: the test server's load, your network, a third-party script that was slow on this particular pass. Run the same URL three times in a row and you will often see three different scores, sometimes 10 or more points apart. A page scoring 72 one minute and 81 the next has not changed - the measurement has. So treat the score as a rough band (poor / okay / good), never as a precise grade to chase to 100.

What the lab section is genuinely good for is the lists underneath:

• Opportunities - concrete changes with an estimated time saving next to each: "Properly size images - 1.8 s", "Eliminate render-blocking resources", "Defer offscreen images". This is the part of the whole report you act on.
• Diagnostics - supporting detail on how the page is built (cache policy, DOM size, main-thread work). Useful context for whoever does the fixing, less of a direct to-do list.

Lighthouse also runs Accessibility, Best Practices and SEO audits alongside Performance. They are worth a glance, but they are not the speed report and they are not Core Web Vitals - don't let a perfect SEO tab convince you the page is fast.

What to actually do with it

The workflow that works is short:

1. Read the field-data pass/fail first. Passed and green across LCP, INP and CLS? Your speed is fine in Google's eyes - stop here and spend the effort elsewhere. Failed, or one metric amber/red? Note which metric, because that tells you which Opportunities matter.
2. Open the top Opportunity that targets your failing metric. If LCP failed, the image-sizing and render-blocking items are your targets. Fix the biggest estimated saving first - usually compressing and correctly sizing the hero image, which is the most common LCP culprit on small-business sites.
3. Ship one change, then re-test. Run the URL again and check the lab Opportunities shrank. The field-data assessment will not move for up to 28 days - that is expected. The lab list confirms the fix landed; the field data later confirms real visitors felt it.
4. Ignore the vanity score. Do not refresh hoping the 0–100 climbs. A page that passes the field-data assessment at a score of 78 beats a page that scores 95 in the lab but fails real visitors. Google ranks on the field data, which is why page speed affects ranking at all - the lab number is a workshop tool, not the verdict.

Done in that order, the report stops being a source of anxiety and becomes a short, prioritised job list.

When this isn't enough

PageSpeed Insights tells you whether one page is fast and roughly why. It does not tell you how much it matters for your business, or what to fix across a whole site, or how speed sits next to the other things Google weighs.

Two limits worth naming. The field data only covers pages with enough Chrome traffic, so a new site or a quiet internal page may never get a real assessment - you are stuck with lab estimates and your own judgement. And speed is one signal among many: a fast page with thin content still won't rank. We dig into whether Core Web Vitals affect your ranking and how page speed affects Google ranking more honestly than the "make it green or die" crowd - the short version is that speed is a tie-breaker, not a trump card.

If you want the underlying engineering detail behind every Opportunity, Google's own web.dev is the canonical reference. And if you would rather not read a report at all, run your domain through our scan - the Speed category checks the same Core Web Vitals against the rest of your site's posture, in one place, in plain English, so page speed sits alongside the email and DNS basics instead of in its own silo.