Google PageSpeed Insights (PSI) analyzes one URL on mobile and desktop. It combines a Lighthouse lab run with real-user Chrome UX Report data when enough eligible data exists. Read the two sections separately: field data describes what people experienced across a rolling period; lab data helps you investigate a specific test run. A green lab score is useful, but it does not prove that every visitor had a fast page or that Google will rank it higher.
Start with the exact page your users visit, then check whether PSI is showing URL-level or origin-level field data. This guide explains how to read the report and choose a fix. For implementation tasks, see our page speed optimization guide. Google's PSI documentation is the primary reference for the data and thresholds below.
Read the field-data scope before reading the numbers
PSI's real-user data comes from the Chrome User Experience Report. Its field metrics reflect a trailing 28-day collection period, and the displayed value is the 75th percentile of eligible experiences. The field panel may describe the requested URL or fall back to the whole origin when that URL lacks sufficient data. Some pages have no eligible field data at all. Read the label before comparing pages; an origin result is not proof that one specific template is fast.
The Core Web Vitals are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). They represent loading of the main visible content, responsiveness to interactions, and visual stability. Google currently classifies a “good” 75th-percentile result at LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less in Google's current PSI guidance. See our Core Web Vitals guide for interpretation and debugging.
Illustrative reading: A product URL may show no URL-level field data but an origin-level LCP of 2.3 seconds. You cannot conclude that the product template itself reaches 2.3 seconds. Test representative product URLs in the lab and gather page-specific field evidence if the business needs that answer.
Understand what the Lighthouse lab run can and cannot say
PSI runs Lighthouse under simulated conditions for the requested page. The lab report includes a performance score and metrics such as FCP, LCP, Speed Index, CLS, and Total Blocking Time. Its diagnostic audits point toward possible causes: delayed resource discovery, render-blocking work, unused code, large images, or long main-thread tasks. The score summarizes that one test; it is not a full measurement of your audience.
Speed Index estimates visual progression, while Total Blocking Time highlights long lab tasks that can delay interactivity. TBT is not INP: INP is based on real user interactions and their latency. If the lab score is green but field INP is poor, investigate actual interaction paths rather than trying to polish the lab score alone.
PSI's own guidance says lab and field results can disagree because one is a controlled test and the other aggregates varied users, devices, and networks. A code change can improve today's Lighthouse run while the trailing field window still contains weeks of earlier visits.
Compare mobile and desktop as separate experiences
Run both device views if both matter to your visitors. A responsive layout may load a different hero image, navigation, or third-party widget on mobile. Mobile and desktop field populations also differ. Do not copy a desktop score into a mobile performance report.
When a page behaves differently by device, record the problem in plain language: “The booking form appears promptly on desktop but takes several seconds to respond on mobile,” or “The mobile product image arrives late.” This focuses the investigation. Check whether the field panel has enough data for that device before treating an absence of data as a pass.
If a site has multiple templates, sample pages from the templates that users actually visit: homepage, service, location, product, and article. One fast homepage does not establish that a checkout or article template performs well.
Turn the report into one testable fix
- Record the exact URL, device, date, field-data scope, and the symptom a user experiences.
- Use the lab filmstrip and diagnostics to identify the likely bottleneck. If LCP is late, find the LCP element and trace how the browser discovers it. If responsiveness is weak, inspect long tasks and the interactive workflow.
- Choose one focused change. Resize and prioritize an important image, reduce blocking code, or correct a slow response only when the trace supports that cause.
- Verify that the page still renders and works. Retest under comparable conditions more than once; compare underlying metrics and the filmstrip, not only the aggregate score.
- Watch field data over time. A rolling 28-day dataset will not instantly reflect today's deployment.
For example, an oversized hero image that occupies most of the first viewport is a plausible LCP issue. Measure its transfer size and loading path before changing it; do not assume that minifying a small footer script will fix the main-content delay. Screpy's page speed monitoring can help track repeated checks, while the PSI field panel remains the source for eligible CrUX observations.
FAQ
Does PageSpeed Insights include real-user data?
Yes, when enough eligible Chrome UX Report data exists. It can be URL-level, origin-level, or unavailable; check the label.
Is a score of 100 required for SEO?
No. Lighthouse's lab score is a diagnostic summary, not a guaranteed ranking outcome.
Why did the score move without a deployment?
Test conditions, server response, third-party resources, content, and caching can change. Compare repeated runs and the specific metrics.
Is TBT the same as INP?
No. TBT is measured in a lab page-load run. INP describes responsiveness from real user interactions.
Should I fix every opportunity listed?
Prioritize opportunities tied to an important user problem and verify the result. A report can list technically possible changes that bring little practical benefit to that page.