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
- 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.
- Each URL's metrics are categorised as Good, Needs improvement, or Poor against the thresholds above.
- The distribution shows the share of measured URLs in each band per metric, on mobile and desktop.
Scenarios you'll see
75%+ of URLs in Good across all three metrics on mobile. The CWV ranking signal is firmly in your favour.
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.
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.
Heavy JS, especially on tap. Audit long tasks, third-party tag managers, and event handlers. INP is the metric most sites still struggle with.
Desktop is green; mobile is red. The most impactful split — Google primarily uses the mobile signal for ranking. Prioritise mobile.
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
- Read the mobile distribution first; it's the ranking-relevant one.
- 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.
- 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
- PSI Overview — lab-data scores per URL.
- PSI History — trend over time.
- Device Breakdown — to validate whether mobile-side CWV problems are translating into ranking gaps.