Help & Documentation
Browse the full documentation index · Press Esc to close
PageSpeed

Core Web Vitals Distribution

Core Web Vitals Distribution shows the field-data distribution of LCP, CLS and INP across your measured URLs — the percentage of real users who experience each metric in the Good / Needs improvement / Poor band. Where PSI Overview is a lab simulation, this report is the truth: it's what your actual visitors experienced over the last 28 days, and it's the data Google uses for the Core Web Vitals ranking signal.

What it measures

  • LCP (Largest Contentful Paint) — when the main content of a page is visible. Good: ≤ 2.5s. Poor: > 4.0s.
  • CLS (Cumulative Layout Shift) — how much the page jumps around as it loads. Good: ≤ 0.10. Poor: > 0.25.
  • INP (Interaction to Next Paint) — responsiveness to clicks/taps. Good: ≤ 200ms. Poor: > 500ms. (Replaced FID in March 2024.)

How we compute it

  1. For each tracked URL, we capture the field-data Core Web Vitals reported by the PSI API, which sources from the Chrome User Experience Report (CrUX) — a rolling 28-day window of real Chrome users.
  2. Each URL's metrics are categorised as Good, Needs improvement, or Poor against the thresholds above.
  3. The distribution shows the share of measured URLs in each band per metric, on mobile and desktop.

Scenarios you'll see

All-green site

75%+ of URLs in Good across all three metrics on mobile. The CWV ranking signal is firmly in your favour.

LCP problem

CLS and INP fine but LCP has a long Poor tail. Hero image, web font loading order, server response time. Preload the LCP image and audit the critical request chain.

CLS problem

A meaningful Poor share for CLS. Almost always: late-loading ads, embeds, or images without explicit dimensions. Fix layout reservation and CLS scores improve quickly.

INP problem

Heavy JS, especially on tap. Audit long tasks, third-party tag managers, and event handlers. INP is the metric most sites still struggle with.

Mobile-only fail

Desktop is green; mobile is red. The most impactful split — Google primarily uses the mobile signal for ranking. Prioritise mobile.

Insufficient field data

URLs with too little real-user traffic for CrUX to report. Use PSI Overview's lab data as a proxy; speed-optimise based on Lighthouse opportunities.

What to do with it

  1. Read the mobile distribution first; it's the ranking-relevant one.
  2. Pick the metric with the largest Poor share and treat it as the primary engineering target. Fixing one metric is far more tractable than fixing all three at once.
  3. Re-measure 4–6 weeks after a release; the 28-day field-data window means the report lags deployment.

Caveats & limits

  • Field data has a 28-day reporting lag; if you fixed something today, expect the report to improve in the following weeks.
  • URLs with too few visitors don't have field data and won't appear in the distribution. Use the origin-level reading instead in those cases.
  • Google's CWV thresholds occasionally change; we update bands when Google publishes new thresholds.

Related reports