Real-user performance: CrUX and Core Web Vitals

Use field and lab data for different decisions

A mobile lab run reproduces a chosen device and network condition so a change can be investigated. Real-user data reflects visits across devices, connections, locations and interactions. Neither replaces the other. Write down the URL, scope, device category and time window before comparing numbers.

Read the scope of a PageSpeed report

PageSpeed's field section uses Chrome UX Report data over a rolling 28-day period. It can show the exact URL or fall back to the origin when the URL lacks sufficient data. An origin result includes other eligible pages; do not label it as the measured result of one guide. Search Console also groups URLs with similar experiences rather than measuring every page independently.

CrUX represents eligible Chrome users and visits, not every browser or every visitor. Google does not publish a universal minimum daily visitor count for inclusion. “No data” does not prove that a page is fast, slow or unindexable. A site's own RUM can supplement coverage, with its implementation and sampling limits documented.

Judge the 75th percentile, not just the average

• Good LCP: at most 2.5 seconds for the main visible content.
• Good INP: at most 200 milliseconds for interaction responsiveness.
• Good CLS: at most 0.1 for unexpected layout movement.

For an illustrative sorted sample of eight LCP values — 1.0, 1.1, 1.3, 1.5, 1.8, 2.4, 4.0 and 5.0 seconds — the nearest-rank 75th percentile is the sixth value, 2.4 seconds. Six of eight visits meet the threshold although two are much slower. Production aggregation may use a different quantile estimator; small samples are uncertain. Keep device and page groups consistent instead of mixing unlike visits into one favorable average.

A practical measurement record

1. Choose a page group such as homepage, product or guide; separate mobile from desktop.
2. Record available CrUX URL/origin scope and the 28-day window.
3. Repeat controlled lab runs on the same URL with the same cache and device assumptions; keep all results and compare their median.
4. Record the deployment time and what changed. Check failures, layout shifts and functionality too.
5. Observe field data as new visits enter the rolling window. It will not instantly become a clean before/after experiment.

On 10 October 2026, ServerNet's homepage lab report recorded LCP 2.762 seconds while the origin's mobile field section displayed 2.6 seconds. These are different populations and windows, not conflicting measurements. The dated report gives a concrete example. A later lab improvement does not immediately establish improved field performance or Google ranking.

Collect your own RUM carefully

The official web-vitals library provides callbacks such as onLCP, onINP and onCLS. Review its supported APIs and current integration instructions. A visitor without a measured interaction may have no INP value; unsupported APIs or missing values must not be replaced with zero.

Plan aggregation around page templates, broad device categories and the metric value. Avoid full URLs with queries, account identifiers, form contents and authentication values. Follow the site's consent and retention policy, limit sampling and payload size, and document missing samples. Do not introduce a third-party collector merely to produce a chart. Lab TBT can help investigate main-thread work but is not interchangeable with real-user INP.

Turn the result into a specific fix

For LCP, inspect server response, resource discovery, transfer and render delay, including text fonts. For INP, separate input delay, event processing and presentation delay. For CLS, locate moving elements and reserve space for images or dynamic blocks. Compare like-for-like samples; there is no universal acceptable percentage gap between field and lab numbers.

Use the diagnosis guide to locate the wait and the caching guide to distinguish cold from warm visits. References: Core Web Vitals thresholds, CrUX methodology and PageSpeed data sources.