Read a PageSpeed Insights report in three passes: identify the field data's scope and failing metric, inspect the current lab test, then choose a diagnostic that explains the problem. The field assessment and Lighthouse score answer different questions. A green circle in one section does not cancel a problem in the other.
Begin with a public URL that represents the page you want to improve. Confirm the final destination after redirects and select mobile or desktop. Save the report conditions before changing anything, so the next result can be compared with the same page and strategy.
Confirm the page and test conditions first
A successful test can still describe the wrong experience. Check whether the URL redirected, whether the returned page is the intended content, and whether access restrictions, bot protection or an error response affected the run. A fast challenge page is not proof that an article loads quickly.
Use representative templates instead of testing only the homepage. An article, category, product and search-results page can use different resources and scripts. Start with a page linked to a known problem, then test additional examples before treating a template-wide change as complete.
Record the date, device strategy and final URL. In the lab details, keep the reported Lighthouse version and environment. Interface wording and audit names can evolve between releases, so use the sections' purpose rather than relying on a screenshot from an old tutorial.
The official PageSpeed Insights overview explains its combined field and lab approach. The report is a diagnostic starting point, not an automatic instruction to apply every suggestion indiscriminately.
Read the real-user section before the laboratory score
The field section uses the Chrome User Experience Report, or CrUX. It describes eligible real Chrome visits over the previous 28 days and is updated daily. Check whether the panel is showing the tested URL or the broader origin before interpreting its assessment.
An origin is the combination of scheme, hostname and port. Origin-level evidence may combine several page types, so it cannot establish that the exact article in the lab test has the same performance distribution. Preserve the scope label when sharing a screenshot or recording a metric.
Core Web Vitals cover LCP for loading, INP for interaction responsiveness and CLS for visual stability. At the 75th percentile, good means LCP at most 2.5 seconds, INP at most 200 milliseconds and CLS at most 0.1. CLS has no time unit. Do not add the three numbers or average their different units.
Where all three have sufficient data, the assessment passes only if all three are good. PSI documentation allows assessment on LCP and CLS when INP has insufficient data. If LCP or CLS lacks sufficient data, the aggregation cannot be assessed. An absent INP value is not zero and should not be displayed as a measured good result.
Interpret the distribution bars and supporting metrics
The bars show the proportions of observed experiences in good, needs-improvement and poor ranges. They are distributions across visits, not the percentage of page resources that passed an audit. The displayed p75 marks a percentile of that population rather than an arithmetic mean.
Consider a hypothetical page with good p75 LCP but a visible poor tail. The overall classification can be good while some visitors still wait a long time. That can justify examining geography, device capability or a particular template in your own monitoring. The public bar alone does not identify the cause.
FCP and TTFB can appear as additional field measurements. They help explain loading behavior, but they are not additional Core Web Vitals. A slow first byte can delay everything that follows; it does not follow that buying a bigger server is the correct fix. Redirects, connection setup, application work and cache behavior need investigation.
Keep units visible when transferring values into a spreadsheet or issue. A millisecond value copied into a seconds field can turn a reporting mistake into an apparently catastrophic regression. Preserve CLS as a unitless number instead of adding “ms” to every metric.
Use mobile and desktop as separate views
The device toggle changes the lab strategy and the field form-factor view. Real mobile visitors differ from the simulated mobile test, but both can expose problems hidden by a powerful desktop and wide viewport. Do not average mobile and desktop scores to create a site-wide performance grade.
Layout changes matter as much as hardware. Mobile can select another hero image, display a taller header, hide content behind a menu or initialize a different component. If LCP changes between strategies, identify the largest element in each before choosing an image or server fix.
Test the journeys that matter on each form factor. A responsive layout that fits the screen can still have slow menu interaction or an unstable advertisement. Visual responsiveness in CSS is not the same as interaction responsiveness measured by INP.
Our Core Web Vitals introduction connects these distinctions to actual user experience. Maintain separate baselines for mobile and desktop so a change in one cannot hide a regression in the other.
Read the Lighthouse score as a lab summary
The lower diagnostic section runs Lighthouse against the URL under configured conditions. Its performance score ranges from 0 to 100; 90 and above is good, 50 through 89 needs improvement, and below 50 is poor. These score bands are not the field metric thresholds.
The composite is calculated from weighted metric scores. Audit recommendations help diagnose the work behind the metrics, but fixing an audit does not award a fixed number of points. The scoring curve and configuration depend on Lighthouse, so compare versions and individual timings as well as the headline circle.
A small timing change can produce a noticeable score movement, while a useful repair can leave the rounded score unchanged. Do not judge the engineering outcome solely by that integer. Inspect whether the affected milestone improved consistently and whether the page still behaves correctly.
The Accessibility, Best Practices and SEO categories answer other limited sets of checks. A high SEO score is not a promise of ranking, and an automated accessibility score is not a complete accessibility audit. Keep each category's scope clear when reporting results to a nontechnical owner.
Map the lab metrics to their investigative use
A navigation audit reports loading-related measurements, including LCP and CLS during its observation period. It can miss layout shifts triggered much later. It also does not supply the field INP distribution; interacting with the page requires a suitable interactive test.
Use this table to choose the next investigation, without treating supporting metrics as interchangeable.
| Measurement | What it helps you investigate | What it does not establish |
|---|---|---|
| LCP | Delivery and rendering of the largest content | Every later interaction is responsive |
| CLS | Unexpected movement observed in the test | No movement occurs later in a real visit |
| FCP | When the first content becomes visible | Main content is ready |
| TBT | Main-thread blocking during the measured loading period | The actual field INP value |
| Speed Index | How visual completeness progresses | A standalone Core Web Vitals pass |
If TBT is high, inspect long tasks and script execution. If field INP is poor, reproduce real actions such as typing, expanding navigation or changing an option. TBT may provide a useful lead, but replacing the INP label with a TBT number would misrepresent the evidence.
If field and lab CLS differ, extend the recording and test delayed content. For a broader explanation of such disagreements, use the field-data and lab-data guide before concluding that one result is wrong.
Prioritize insights by the metric they can explain
Open the insights and diagnostics relevant to the failing metric. Names and grouping can change with Lighthouse releases, but the central questions stay practical: what delayed discovery, transfer or rendering, what blocked the main thread, and what changed layout unexpectedly?
For LCP, follow the identified element through the request waterfall. A large image is not always the entire problem. It may be discovered late, start late because another request has priority, or finish downloading before the browser is free to render it. Choose a fix for the dominant stage.
For render-blocking resources, inspect which styles and scripts are needed for the initial page. Moving everything later can produce unstyled content or broken dependencies. The render-blocking resources guide explains how to make that decision with the rendering path in view.
Estimated savings are model outputs for the tested scenario, not guaranteed savings for every visitor. Overlapping recommendations can address the same bottleneck, so do not add all the estimates into a promised total. Choose one defensible change, then retest to establish its actual effect.
Turn a finding into a reproducible work item
A useful ticket names the page, device, metric, evidence and proposed component change. Include the relevant request or script rather than pasting the entire report and asking someone to “make it green.” Add a functional check so the optimization cannot pass by removing the feature the visitor needs.
For example, an image-related ticket might ask the team to make the initial content image discoverable in HTML and verify the selected responsive resource. The acceptance check should include the resulting LCP and correct image rendering at representative widths. This is a workflow example, not a claim that your page has that defect.
Prioritize shared components when the evidence supports them. A header script affecting many templates can be more consequential than a unique decorative asset, but verify the common cause rather than inferring it from similar colors in several reports. Keep a rollback path for changes that affect rendering or application behavior.
Treat missing data as a limitation with several causes
A URL can lack field data because it has too few eligible observations, is new, or does not meet public-discoverability requirements. An origin fallback can provide context, but it does not fill the missing URL-level record. Authentication and nonpublic applications need different monitoring approaches.
An API integration can also fail to supply field data because of response changes, configuration or service errors. Distinguish “no CrUX record” from “the request failed” and from “this integration does not provide field data.” Those states should not share a red failure badge.
Continue using appropriate lab tests while the evidence is missing. If you operate the site, consider privacy-aware RUM for the questions the public dataset cannot answer. Do not manufacture a percentile from one run or present a missing value as a pass.
Use the API with explicit strategy and error handling
The PageSpeed Insights v5 API provides a programmatic Lighthouse analysis. The following shell command requests the performance category for an illustrative public URL and saves the JSON response. It needs a shell with curl; service access, quotas and any required project configuration still apply.
curl --fail-with-body --get \
'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
--data-urlencode 'url=https://example.com/' \
--data-urlencode 'strategy=mobile' \
--data-urlencode 'category=performance' \
--output pagespeed-mobile.jsonFor managed use, configure an API key and quota controls according to Google's documentation. Do not expose unrestricted credentials in a public browser bundle. Check the HTTP result and JSON error fields before reading lighthouseResult; retain the fetch time, final URL, Lighthouse version and relevant settings.
Google's getting-started documentation announces plans to discontinue real-world CrUX data in the PSI API and recommends the CrUX API or CrUX History API. Do not build a new field-monitoring system that assumes loadingExperience and originLoadingExperience will remain available. Keep lab and field retrieval separate and handle missing fields explicitly.
An API result is not a substitute for permission to test private or sensitive URLs. Avoid submitting URLs containing tokens or personal data. For a public analysis service, validate requested destinations and manage abuse prevention on the server.
Retest after a meaningful change, then monitor the trend
Repeat comparable lab runs after a targeted change and retain the individual metrics. Test the affected feature as well as the original navigation. Frequent reruns without a code change mostly reveal variability; they do not create new real-user experiences for the rolling field window.
Check fresh visitor measurements when available, then follow the public field trend as new visits enter the 28-day window. Note release dates and other changes that might affect the audience. A stable result across representative scenarios is more useful than one unusually favorable run.
Open the PageSpeed analyzer when enabled to inspect a public page, then use the page-speed guides for the specific cause you identified. Finish the review with a measurable next action, an owner and a retest condition, not a list of unexplained warnings.
