CrUX vs PageSpeed Insights

Understand why GSC field data and individual PageSpeed tests can show different results.

Additional data required Intermediate

CrUX and PageSpeed Insights are not two independent tests. The Chrome User Experience Report, or CrUX, is a public field dataset built from eligible real Chrome-user experiences. PageSpeed Insights combines a CrUX field-data view with a separate Lighthouse lab test of the URL entered.

Use field data to decide whether real users have a problem and whether a production change improved the distribution of experiences. Use the Lighthouse lab result to reproduce and diagnose likely causes under one controlled set of conditions. The numbers are allowed to disagree because their scope, population, time period, and measurement conditions differ.

This guide reflects Google's documentation on July 18, 2026.

The three views people commonly confuse

View	What it measures	Scope	Time	Best use
Search Console Core Web Vitals	CrUX field data for indexed URLs	Similar-URL group or origin group, split by mobile and desktop	Rolling previous 28 days, 75th percentile	Find widespread issues and prioritize templates
PageSpeed Insights field section	CrUX field data	Entered page when eligible; otherwise origin fallback	Rolling previous 28 days, refreshed daily	Check the real-user distribution for a page or origin
PageSpeed Insights diagnostics	Lighthouse lab data	One fetch of the entered URL in a simulated mobile or desktop environment	The current run	Reproduce, inspect, and debug performance

The PageSpeed Insights performance score belongs to the Lighthouse lab run. It is not the CrUX Core Web Vitals assessment, and it is not the Search Console group status.

What CrUX represents

CrUX aggregates anonymized experiences from a subset of Chrome users. An eligible user must have usage-statistics reporting enabled, sync browser history without a sync passphrase, and use a supported platform. The dataset currently includes desktop Chrome and Android Chrome, including Custom Tabs and WebAPKs. It does not represent Chrome on iOS, Android WebView, other Chromium browsers, or every visitor to the site.

Pages and origins must also be publicly discoverable and sufficiently popular. Google does not disclose the traffic threshold. A page or origin can enter or leave the dataset as eligibility changes, and there is no submission process that forces inclusion.

CrUX is therefore real-user evidence, but it is not a census of every browser, visit, customer segment, or page view. First-party real-user monitoring can cover a site's chosen population and attach dimensions such as template, release, geography, account state, and LCP element that the public dataset does not expose at page-view level.

What PageSpeed Insights actually shows

PageSpeed Insights has two conceptually separate sections.

Discover what your real users are experiencing

This is CrUX field data. It reports the previous 28 days of eligible experiences and shows distributions and 75th-percentile values for LCP, INP, CLS, FCP, and experimental TTFB where data exists.

Check the scope label before reading the values:

This URL means the entered page has sufficient page-level CrUX data.
Origin means page-level data was unavailable and PSI is showing aggregated experiences for pages across the origin.
No data means neither the page nor the origin has sufficient eligible CrUX data.

Origin data is not a performance result for the entered page. It can be directionally useful, but a fast homepage, a slow application, and many ordinary content pages can all contribute to the same origin distribution.

Diagnose performance issues

This is a new Lighthouse lab run. It loads the entered URL in a Google data center using a simulated mobile or desktop setup and reports diagnostics, audits, lab metrics, and a weighted performance score.

The lab run can work when CrUX says “No data” because it does not need a population of real visits. It is fast and repeatable enough for development, regression testing, and trace analysis, but it represents one device model, network setup, location, cache state, viewport, page state, and execution.

Why Search Console and PSI field data can differ

Both use CrUX, but Google applies different presentation and grouping rules.

Search Console reports groups, PSI usually reports a page

The Core Web Vitals report groups similar URLs that Google expects to share a framework and underlying performance causes. Its metric and status apply to the group for one device type. The example URL is a representative, not the only measured page.

PSI generally shows the entered page's CrUX data when enough observations exist. One page can be faster or slower than the Search Console group. Testing only the representative URL cannot prove that all group members behave the same way.

Either product can show a broader origin scope

When a Search Console URL group lacks enough data, Google can create an origin group. When PSI lacks page-level data, it can fall back to origin-level field data. In both cases, the broader aggregation can conceal template and page outliers.

Search Console only shows example URLs that belong to the property, but the origin aggregation can contain experiences for URLs across the entire protocol, host, and port origin. Read the group details rather than assuming that every observation came from the visible examples.

Parameter handling is not identical

Google's Search Console documentation says its Core Web Vitals report includes URL parameters when distinguishing pages. PSI strips parameter data and assigns the CrUX results to the bare URL.

This matters when parameters change the actual experience—for example, product identifiers, filters, campaign variants, experiments, or application state. PSI can combine those visits while Search Console distinguishes affected URLs in its reporting layer.

The visible sample is not a page inventory

Only indexed URLs can appear in Search Console's report, and the report is not a comprehensive list of all indexed URLs. The issue-example table is limited to 200 rows. PSI can run a lab test for a public URL even when it is absent from the Search Console sample or CrUX dataset.

Why PSI field and lab data can differ

The field panel is a distribution of eligible real experiences over 28 days. The lab panel is one simulated visit now. A difference is expected rather than evidence that one panel is broken.

Important causes include:

real users have varied devices, CPU load, networks, locations, screen sizes, cache states, and browser behavior;
the lab uses one simulated device, network, viewport, and data-center location;
field users may be signed in, personalized, included in an experiment, or shown consent and ad experiences not reproduced in the lab;
repeat visitors can use cached assets, while Lighthouse commonly performs a cold load;
back/forward-cache restorations and platform preloading can improve field experiences;
real users scroll, click, type, navigate, and keep pages open for different lengths of time;
the 28-day field window still contains pre-release visits after a deployment;
lab variability can occur between runs even with similar settings.

Compare trends and distributions, not a field percentile with one lab observation as though they were the same statistic.

Metric-specific traps

LCP can use a different element

The largest visible element depends on viewport, personalization, fonts, experiments, cookie banners, and when the user interacts. A lab run might identify a text block while many field users see a hero image as LCP. Redirect, connection, server, and uncached delays can also make field LCP differ from the current test.

Lighthouse does not measure INP

INP depends on interactions throughout an actual page visit. A standard Lighthouse page load has no representative population of user clicks, taps, and key presses, so it cannot produce an INP measurement.

Lighthouse reports Total Blocking Time as a lab diagnostic that can reveal main-thread risk. TBT is not INP and cannot establish that field INP passes. Use CrUX or first-party field data for the outcome, then reproduce slow interactions with Chrome DevTools and controlled interaction tests.

Lab CLS can miss later shifts

Field CLS includes unexpected shifts across the page's lived experience, including shifts triggered as users scroll or as late content, ads, embeds, or interface states appear. A load-only lab run can miss behavior that occurs farther down the page or after interaction.

Use the right result for the decision

Question	Primary evidence
Are real users meeting Core Web Vitals?	CrUX field data or well-implemented first-party RUM
Which sitewide template or group needs attention?	Search Console Core Web Vitals
Does this specific page have enough public field data?	PSI field panel, with its URL/origin label
What probably caused slow LCP or load-time CLS?	Lighthouse and Chrome DevTools diagnostics
Which real interaction caused poor INP?	First-party RUM attribution plus DevTools reproduction
Did a fix improve the real-user distribution?	Post-release RUM, followed by the rolling CrUX trend
Can a pre-production change be tested?	Lab testing; CrUX cannot measure users who have not received it

Field data identifies the outcome and lab data helps explain the mechanism. Neither alone provides every answer.

A reliable comparison workflow

In Search Console, record the device, issue, group value, affected count, examples, and whether it is a similar-URL or origin group.
Open several representative and outlier group members in PSI.
Select the matching mobile or desktop view.
In the field section, confirm whether PSI is showing URL or origin data.
Compare the same Core Web Vital and 75th-percentile scope; do not compare the Lighthouse score with a field status.
Use the Lighthouse diagnostics to generate causes to investigate, not to overrule the field evidence.
Reproduce across templates, content variants, logged-in states, consent states, ads, and important interactions.
Use first-party RUM when available to segment the problem and attribute LCP elements, layout shifts, and slow interactions.
Deploy the fix across the affected group and annotate the release.
Watch RUM first, then allow the rolling CrUX window to replace older visits before judging field recovery.

When field and lab disagree, first reconcile device, scope, URL, parameter treatment, time window, and page state. Only then investigate measurement or implementation defects.

What “No data” means

No CrUX field data does not mean a page is fast, slow, broken, or unimportant. Common explanations are:

the page or origin has too few eligible visits;
the page is new;
it is not publicly discoverable under CrUX eligibility rules;
the Search Console property is new and existing CrUX data has not yet been processed into the report;
the selected device type lacks sufficient data;
filtering or statistical-quality rules excluded the aggregation.

You cannot request CrUX inclusion. Run lab tests immediately, implement first-party RUM for future visits, and use other business evidence to decide priority.

Automation boundary

Search Console's API does not expose the aggregate Core Web Vitals report. The CrUX API can retrieve current field distributions for eligible URLs and origins, and the PageSpeed Insights API can return PSI results. CrUX BigQuery provides historical origin-level datasets on a monthly release schedule; PSI field data is refreshed daily over a trailing 28-day period.

Automate scope labels, device selection, repeated representative tests, release annotations, and field-trend alerts. Do not collapse field percentiles and Lighthouse scores into a single unlabeled number.

SearchConsole.ai cannot retrieve the Core Web Vitals report from Search Console. Provide issue exports, example URLs, PSI or CrUX results, and first-party RUM when asking it to prioritize a performance problem.

Common mistakes

Calling the PSI Lighthouse score a Core Web Vitals score.
Treating PSI field data and CrUX as independent datasets.
Reading origin fallback as proof about one page.
Comparing a Search Console group with a PSI page without sampling group members.
Ignoring mobile versus desktop.
Comparing a 28-day field percentile with one current lab run.
Expecting an immediate field change after deployment.
Treating green lab data as proof that validation will pass.
Treating a red lab run as proof that most users fail.
Using TBT as if it were INP.
Assuming “No data” means “Good.”
Forgetting that CrUX covers an eligible subset of Chrome users, not all visitors.