Why PageSpeed Insights and Search Console Show Different Results
Understand why PageSpeed Insights and Search Console disagree by separating Lighthouse lab tests from CrUX field data, URL groups, devices, and time windows.
PageSpeed’s lab run is a controlled diagnosis, while Search Console summarizes eligible real-user data over time and groups similar URLs. Use field data for outcomes and lab traces for debugging.
PageSpeed Insights can show a strong Lighthouse result while Search Console reports poor Core Web Vitals—or the reverse. The tools are not measuring the same population, time window, URL set, or environment.
The difference is usually expected. The useful question is not “which score is correct?” but “which dataset answers the decision I am making?”
Separate lab data from field data
PageSpeed Insights can show two kinds of data:
- Lab data: a Lighthouse test run under a controlled device and network profile at test time.
- Field data: Chrome User Experience Report (CrUX) measurements collected from eligible real users when enough data is available.
Search Console’s Core Web Vitals report uses field data. It describes real-world visits rather than a fresh test from Google’s lab environment.
Lab data is reproducible enough for debugging a request waterfall, main-thread work, render-blocking resources, and layout shifts. Field data captures the diversity of actual devices, networks, cache states, locations, sessions, and user interactions.
A perfect lab run cannot erase slow real-user visits already present in a rolling field-data window.
Account for the 28-day window
Search Console evaluates grouped field data over the most recent 28 days and reports the 75th percentile for Core Web Vitals. A production improvement today gradually changes that window as older visits leave and new visits enter.
Lighthouse responds immediately because it is a new run. Search Console can therefore remain “Poor” after a successful release even when current lab traces look much better.
Do not repeatedly change the implementation while waiting for field data unless monitoring shows a real regression. Record release dates and compare daily field trends, not isolated refreshes.
Understand URL and origin data
PageSpeed Insights prefers URL-level field data when the exact URL has enough samples. It may fall back to origin-level data, which combines pages across the same origin. Read the label above the metrics before assuming the numbers describe only the tested page.
Search Console groups URLs with similar experience. A representative example can look fast in a lab while another popular page in the same group is slow. The group’s status applies to the group, not only the example you clicked.
Google’s documentation also notes URL handling differences: Search Console distinguishes URLs with parameters in its grouping, while PageSpeed Insights strips parameter data for CrUX reporting. Redirects, canonicalization, mobile variants, and logged-in experiences can add further differences.
Match the device and page state
Search Console splits Mobile and Desktop reports. Compare mobile field data with PageSpeed’s mobile view, not a desktop Lighthouse run.
Then check:
- Cold versus warm cache.
- Geographic distance to the origin.
- Consent banners and regional scripts.
- Logged-in versus anonymous markup.
- A/B tests and personalization.
- Ads, chat widgets, tag managers, and other third parties.
- Slow backend conditions that a single lab run did not encounter.
Field LCP includes navigation and connection delays such as redirects and TTFB. Real users on slower devices and networks can experience a bottleneck absent from your local machine.
Read pass or fail at the 75th percentile
Core Web Vitals use the 75th percentile, segmented by mobile and desktop. That means at least 75% of visits should meet the “good” threshold for each metric.
An average can look healthy while the 75th percentile fails. A PageSpeed performance score is also a weighted Lighthouse score, not the same value as LCP, INP, or CLS. Do not use the overall score as a substitute for the individual field metrics.
Search Console assigns a URL group the status of its worst Core Web Vital. Good LCP does not make the group good if INP or CLS is poor.
Use each tool for the right job
Use Search Console and CrUX-compatible real-user monitoring to answer:
- Are real users meeting Core Web Vitals?
- Which device class and URL group has the broadest problem?
- Is the 28-day trend improving after releases?
Use PageSpeed Insights, Lighthouse, DevTools, and a waterfall tool to answer:
- Which resource is the LCP element?
- Why does its request start late?
- Which code blocks rendering or interaction?
- What shifts and which element moved?
The field dataset identifies the outcome. The lab trace generates and tests hypotheses.
A practical investigation workflow
- In Search Console, select Mobile or Desktop and note the failing metric and URL group.
- Open several real URLs from that group, not only the representative example.
- In PageSpeed Insights, identify whether field data is URL-level or origin-level.
- Run repeated lab tests on representative templates and geographic conditions.
- Measure the metric breakdown, not only the total.
- Fix one common bottleneck at the template or infrastructure layer.
- Deploy with a release marker and watch your own real-user monitoring immediately.
- Allow the Search Console window time to reflect the changed traffic.
For LCP, separate TTFB, resource load delay, resource load duration, and element render delay. The WordPress LCP guide applies that model to common WordPress bottlenecks.
Common interpretation mistakes
Avoid:
- Comparing a desktop lab run to mobile field data.
- Treating the Lighthouse score as a Core Web Vitals verdict.
- Ignoring whether PageSpeed shows URL or origin field data.
- Testing only the Search Console example instead of the URL group.
- Expecting a 28-day dataset to reset after deployment.
- Optimizing a lab audit that is unrelated to the failing field metric.
Build a small performance budget and test it continuously. The Astro performance budget guide shows how to turn the measurement into release constraints instead of occasional score chasing.
Frequently asked questions
Which result should guide Core Web Vitals work?
Use field data to judge the user outcome and lab data to diagnose and test fixes. Neither should be ignored; they answer different parts of the investigation.
Why does PageSpeed Insights say “No data”?
The exact URL or origin may not have enough eligible CrUX samples. You can still use Lighthouse lab data and your own real-user monitoring while field coverage grows.
Official references
Have a question about this guide or an idea for a technical collaboration? Contact Bakry through the Dev Hub.
End of field note.