Google PageSpeed Insights (PSI) combines real-user performance data, when available, with a Lighthouse lab test of the URL you enter. The two sections answer different questions. Field data describes what eligible Chrome visitors experienced over time; lab data reproduces one controlled scenario and helps identify work to investigate.
The most common PageSpeed mistake is treating the 0–100 Lighthouse score as a direct measurement of every visitor or as a search ranking score. A useful PSI review begins by separating the data sources.
What PageSpeed Insights reports
PSI's official documentation describes two primary data sources:
- Field data comes from the Chrome User Experience Report (CrUX). It aggregates eligible real-user experiences over the previous 28 days.
- Lab data comes from Lighthouse. It runs the page with a defined device and network simulation and produces diagnostics plus a performance score.
The field section focuses on experience distributions and Core Web Vitals. The lab section includes Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), Total Blocking Time (TBT), First Contentful Paint (FCP), and Speed Index. TBT and Speed Index are valuable lab diagnostics, but they are not Core Web Vitals.
PageSpeed may also present accessibility, best-practice, and SEO audits. These are useful automated checks, not complete audits of those disciplines.
Read field data first
The current Core Web Vitals are:
- LCP for loading performance;
- INP for interaction responsiveness;
- CLS for visual stability.
Google evaluates the 75th percentile, separately for mobile and desktop, when classifying these metrics. PSI displays a distribution rather than only an average because a fast median can hide a poor experience for a meaningful group of visitors.
Field data can differ by geography, device capability, connection, signed-in state, cache state, and page behavior. It is also delayed by its rolling window. A production fix made today will not replace the previous 28 days of observations immediately.
If the page has insufficient eligible traffic, field data may be unavailable. That is not a pass or a failure. Use lab diagnostics, your own Real User Monitoring where available, and comparable templates until enough CrUX data exists.
Understand URL and origin data
Check the label above the field results. PSI may show data for the exact URL or fall back to the whole origin when URL-level data is unavailable. Origin data combines different page types and can conceal a slow template behind faster, higher-traffic pages.
For example, an origin can pass while a JavaScript-heavy configurator fails. The reverse can also occur if one optimized landing page is compared with weaker origin-wide data. Record which scope PSI used before sharing the result.
Test representative URLs: a home page, a high-traffic listing, an article, and a conversion page. Do not infer site-wide health from the home page alone.
Interpret the Lighthouse score
Lighthouse converts its lab metrics into a weighted performance score. In the current documented model, TBT carries 30%, LCP and CLS each carry 25%, and FCP and Speed Index each carry 10%. The formula is nonlinear, so the same raw improvement does not always produce the same point increase.
PSI labels 90–100 as good, 50–89 as needing improvement, and below 50 as poor for the lab score. These bands describe that run. They do not mean a score of 91 is complete or that a score of 89 is a production incident.
Use What Is a Good PageSpeed Score? to set an appropriate score policy. Prioritize passing real-user Core Web Vitals and correcting observable user friction over chasing a perfect number.
Use audits as evidence, not a checklist
Lighthouse audits identify resources and patterns associated with the run. An estimated saving is a model, not a guaranteed improvement. Start with the metric that is weak and connect each audit to its trace:
- for LCP, identify the element and split time into server, discovery, transfer, and render phases;
- for TBT, inspect long tasks and attribute script work to first-party or third-party owners;
- for CLS, use layout-shift records to identify the elements that moved;
- for Speed Index or FCP, inspect render-blocking work and above-the-fold progress.
Passed audits do not prove that a page is fast, and an audit warning does not automatically justify a code change. Validate the causal path first.
Investigate field and lab disagreement
It is normal for the two sections to disagree. Google's field and lab data guide highlights several causes:
- lab runs use one simulated environment; field data includes a distribution of real devices and networks;
- field data includes repeat visits, cache states, interactions, and page lifecycle behavior;
- lab CLS normally observes the initial load, while field CLS can include later shifts;
- lab TBT is a proxy for main-thread blocking, while field INP observes real interactions;
- the production page or third-party response may vary by location, consent, experiment, or account state.
When field data is poor and lab data is good, reproduce a representative device, route, state, and interaction. When lab data is poor but field data is good, the lab scenario may still expose risk for slower users. Do not discard either result without explaining the conditions.
Build a repeatable PSI workflow
Use the same process for each important template:
- Record the URL, test time, device tab, field-data scope, and current release.
- Save the field Core Web Vitals and their distributions.
- Run the lab test several times under comparable conditions.
- Choose one weak metric and open its relevant audits.
- Reproduce the finding in Chrome DevTools or an application trace.
- Make one attributable change in a staging or preview environment.
- Retest functionality, accessibility, and adjacent performance metrics.
- Deploy with an annotation and monitor field data over its full window.
For trend visibility between PSI checks, compare representative sites and historical measurements in IndieTools Speed. A monitoring chart is most useful when releases and campaign changes are documented beside it.
Avoid common interpretation errors
Do not:
- call every Lighthouse metric a Core Web Vital;
- compare a mobile run with a desktop run as if conditions were equal;
- average URL-level and origin-level field data;
- promise a ranking increase from a score change;
- remove a required business feature solely because it appears in an audit;
- declare a fix complete before field data has time to reflect it;
- repeatedly reload PSI until one favorable run appears.
Page performance can support users and search visibility, but Google's Core Web Vitals search documentation does not describe a perfect Lighthouse score as a guarantee of ranking. Relevant content, crawlability, and overall page experience still matter.
PSI works best as the entry point to an evidence chain: field outcome, reproducible lab symptom, trace-level cause, controlled fix, and post-release confirmation.
