At a glance
LCP distribution across the Good / Needs Improvement / Poor zones from real users (CrUX field data), shows the percentage of page loads in each LCP zone over the 28-day rolling window. The distribution reveals the long tail that the 75th-percentile metric can hide: a site can pass at the p75 threshold while still serving a poor experience to 22% of visits. The Poor% slice is where revenue-killing slow loads happen, every percentage point reduction in Poor% is real money for merchants with material mobile traffic.
| What it counts | The percentage of real-user page loads that fall in each of three CWV LCP zones, computed across the 28-day rolling window: Good (LCP ≤ 2.5s), Needs Improvement (2.5s < LCP ≤ 4.0s), Poor (LCP > 4.0s). Distribution sums to 100% and is reported per origin (or per URL when available). |
| Sample type | Field data from Chrome User Experience Report; aggregated across all real users on Chrome who opted into anonymous metrics syncing. |
| Why distribution matters more than p75 alone | The p75 LCP value tells you the threshold below which 75% of loads sit. The distribution tells you what’s happening to the other 25%: are they barely-poor (3.0s) or catastrophically-poor (8s)? Two sites can have identical p75 of 2.4s but radically different Poor%, one with 5% Poor (excellent overall), one with 22% Poor (a fraction of users are abandoning regularly). |
| Reading the distribution | (1) Healthy ecommerce target: Good 75%+, NI 15-20%, Poor below 10%. (2) Anything above 15% Poor is a meaningful revenue drag. (3) Compare against crux_lcp_p75, distribution explains why p75 sits where it does. (4) Cross-reference crux_origin_vs_url to see if the Poor% is concentrated on specific templates. |
| Currency | percent (Good %, NI %, Poor %). |
| Time window | 28D (CrUX rolling window). |
| Alert trigger | Poor% > 15% (long-tail of slow loads is materially affecting users). |
| Sentiment key | lower-is-better for Poor%; higher-is-better for Good%. |
| Roles | owner, operations |
Calculation
Calculated automatically from your Website Performance (PageSpeed + CrUX) data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A UK-based BigCommerce fashion store, mobile LCP distribution as of Wednesday 15 May 26 (28-day window).| Zone | LCP range | % of page loads | Sentiment | Status |
|---|---|---|---|---|
| Good | ≤ 2.5s | 62% | Healthy | Below 75% target |
| Needs Improvement | 2.5s - 4.0s | 21% | Watch | Within typical range |
| Poor | > 4.0s | 17% | Concerning | Above 15% alert threshold |
- p75 LCP: 2.9s (in NI zone, fails the CWV threshold)
- Good %: 62% (target is 75%+)
- Poor %: 17% (alert threshold is 15%)
- 28-day sample: ~410,000 page loads (sufficient sample for stability)
- Site fails CWV LCP threshold. p75 of 2.9s sits in NI; Google’s pass criterion requires p75 ≤ 2.5s. Search rankings are impacted; AI Overview citation is reduced.
- Poor% at 17% means roughly 70,000 page loads in the past 28 days were severely slow. Every one of those loads is a candidate for abandonment. At a 2-3% conversion rate baseline and a £75 AOV, even modestly recovering half of the abandoned Poor% sessions translates to material revenue (roughly £20,000-50,000 monthly recovery on this traffic profile).
- The 17% Poor slice is the actionable target, not the 38% non-Good slice. Moving the NI segment from 21% to 18% wins barely-noticeable user experience improvements. Moving Poor from 17% to 7% recovers the worst experiences, the ones most likely to bounce, abandon, or churn.
- Why distribution diverges from p75. The site’s 62% Good slice anchors the p75 at 2.9s, strong enough that p75 is “almost passing.” But the 17% long-tail of catastrophic loads (likely product images > 1MB on slow 3G connections, or heavy JavaScript on low-end Android devices) is invisible at p75. The distribution exposes the hidden revenue leak.
-
Likely drivers of the Poor% slice:
- Slow connection users (3G, edge-of-coverage 4G) struggling with hero image weight
- Low-end Android devices (Lighthouse 4× CPU throttle territory) blocked by JS execution
- First-time visitors hitting cold cache without service worker pre-warming
- International visitors served from origin-far CDN POPs
-
Targeted fixes for the Poor% slice:
- Adaptive image serving: detect connection.effectiveType and serve smaller images on 3G (saves 60-70% LCP on slow connections)
- JS deferral on low-end devices: detect
deviceMemory< 4GB or hardwareConcurrency ≤ 2 and skip non-critical scripts - Service worker warm-cache: pre-cache hero images on install so repeat visits skip network entirely
- Edge-network expansion: Cloudflare/Fastly POPs in regions with current poor coverage
-
Recommended ship sequence:
- Week 1: Adaptive image serving by connection type. Saves Poor% from 17% → 12%.
- Week 2: Conditional script loading on low-spec devices. Saves Poor% from 12% → 9%.
- Week 3: Service worker pre-cache. Saves Poor% from 9% → 7%.
- Re-audit at 28 days post-ship: Poor% in 6-8% range. p75 lifts to under 2.5s. CWV LCP passes.
-
Why this card is the most actionable LCP card.
crux_lcp_p75tells you whether you pass;crux_lcp_distributiontells you who’s failing and how badly. The distribution is what merchants need to plan a sprint that recovers revenue rather than just nudging a threshold.
- Read the Poor% slice. That’s the revenue leak.
- Identify the long-tail driver (slow connection, low-end device, cold cache, distant edge).
- Apply targeted remediation for the specific driver.
- Re-measure 28 days post-ship to confirm the slice has shrunk.
| Time horizon | Action |
|---|---|
| First 1 hour | Read distribution. Identify Poor% magnitude. |
| First day | Cross-reference per-template, per-device, per-connection. |
| First week | Apply highest-leverage targeted fix. |
| Day 28 | Re-measure CrUX distribution; confirm Poor% has shrunk. |
Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
crux_lcp_p75 | LCP p75; this card decomposes by zone. |
crux_inp_distribution | INP distribution; same Good/NI/Poor view for INP. |
crux_cls_distribution | CLS distribution; same Good/NI/Poor view for CLS. |
crux_lcp_trend | LCP trend over time; complements distribution snapshot. |
psi_slowest_lcp_urls | Worst LCP URLs (lab); identifies likely contributors to Poor%. |
psi_lab_lcp | Lab LCP; compare against field distribution. |
Reconciling against the vendor’s own dashboard
Where to look:- PageSpeed Insights → Field Data section, bar chart showing Good/NI/Poor distribution for LCP, FID/INP, CLS for the audited URL.
- Chrome DevTools → Lighthouse → Diagnostics, links to CrUX field data when available.
- CrUX BigQuery dataset, full historical distribution data for any origin in the public CrUX dataset, queryable via SQL.
- CrUX API, programmatic access to current distribution per origin/URL (key required, free tier sufficient for monitoring).
- Search Console → Page Experience report, Google’s authoritative view of CWV pass/fail status site-wide, with per-template grouping.
| Reason | Direction | What to do |
|---|---|---|
| Sample size threshold. CrUX requires sufficient sample to publish; low-traffic origins/URLs may be omitted from field data entirely. | Vortex IQ may show “not enough data” | Use origin-level data when URL-level isn’t available. |
| Origin vs URL aggregation. Origin = whole site average; URL = single page. PSI defaults to URL when sufficient sample exists, otherwise falls back to origin. | Variable | Confirm whether the comparison is origin or URL. |
| Rolling window timing. CrUX is a 28-day window; updates daily. A run today vs yesterday may show different distributions. | Either direction | Use 7-day rolling for stable comparison. |
| Chrome-only sample. CrUX samples only Chrome users who opted in. If your audience is heavily Safari/Firefox (e.g., iOS-heavy luxury), the CrUX distribution may not represent the full user base. | Variable | Combine with first-party RUM (Real User Monitoring) for cross-browser truth. |
google_search_console Page Experience report. Both surface CrUX-derived field data; Search Console’s view is authoritative for ranking impact, this card’s view is more granular for operational planning.
Quick rule for support tickets: when a merchant disputes the Poor% figure, run their PSI URL and compare directly. If the merchant has first-party RUM (Datadog RUM, New Relic Browser, SpeedCurve), compare against that, true cross-browser numbers may differ from Chrome-only CrUX.
Known limitations / merchant FAQs
Q: Our p75 LCP passed (under 2.5s) but the Poor% is 14%. Are we okay? You pass the CWV threshold for ranking purposes, but 14% Poor still represents tens of thousands of users monthly experiencing very slow loads on a typical mid-size ecommerce site. You don’t have a ranking problem; you have a revenue problem. Treat passing-but-with-high-Poor as a “fix the long tail” priority, not a “we’re done” status. Q: Why does CrUX use 75th percentile instead of average? The 75th percentile is robust to outliers and represents a realistic worst-case for the typical user. An average can be skewed by a small number of catastrophically-slow loads or by a long tail of very-fast loads, neither of which represents what a “normal” user experiences. p75 says “75% of your users have an experience at least this good”, operationally meaningful for capacity planning. Q: Our Poor% is 22% but we can’t reproduce slow loads in testing. Why? Lab tests run on developer hardware over fast networks; field data captures real users on real devices over real networks. The Poor% population is typically: (a) low-end Android devices, (b) congested mobile networks (3G or edge-of-coverage 4G), (c) international users hitting distant CDN POPs, (d) cold-cache first-time visitors. None of these reproduce in standard lab testing; you need either WebPageTest with throttled profiles or first-party RUM segmented by device class and connection. Q: Should we worry about NI% or just Poor%? Focus on Poor% first, it’s where revenue loss concentrates. NI% (LCP between 2.5s and 4.0s) is users having a “slightly sluggish” experience but typically still completing their tasks. Poor% (LCP > 4.0s) is users actively waiting and at risk of bouncing. A site with 5% Poor and 30% NI is healthier than one with 15% Poor and 10% NI, the median experience matters less than the worst experience. Q: How fast can we move the distribution? CrUX has a 28-day rolling window, so changes blend in gradually. After a Day 0 fix, expect to see ~25% of the impact reflected in CrUX after 7 days, ~50% after 14 days, and full reflection after 28 days. Don’t panic if the distribution doesn’t move on Day 7, wait the full window before declaring a fix successful or failed. Q: Our origin distribution looks fine but a specific URL has 30% Poor. Why? Origin is a weighted average across all URLs that get traffic; a single bad URL gets diluted by the bulk of traffic. URL-level analysis surfaces the bad pages, typically image-heavy collection pages, rich-media PDPs, or high-traffic blog posts with poor optimisation. Usepsi_slowest_lcp_urls for the URL-level view.
Q: Can we segment Poor% by device, country, or browser?
CrUX provides limited segmentation: phone vs desktop vs tablet form factor, and 3G/4G effective connection type when sample size permits. For richer segmentation (specific device models, geographies, browsers), you need first-party RUM. Many merchants run Vortex IQ + Datadog/New Relic RUM together: Vortex IQ for the canonical SEO/ranking view, RUM for the segmentation drill-down.
Q: Why does my lab LCP (Lighthouse) say 4.5s but my field LCP p75 (CrUX) says 2.6s?
Lab tests run with deliberate throttling (4× CPU, slow 4G) to simulate a slower-than-typical mobile experience. Field data reflects the actual mix of devices and networks your real users have, which on average is better than the lab profile (more 5G/WiFi, more high-end devices). Divergence is expected; lab is a worst-case-engineering target, field is reality. If the lab is much worse than the field, you’re conservatively over-engineered (good).
Q: How does this card differ from crux_lcp_p75?
crux_lcp_p75 is a single number, the threshold below which 75% of loads sit. This card decomposes the same data into Good/NI/Poor zones, exposing the long tail. Use p75 for the “do we pass CWV” headline; use distribution for “where’s the revenue leak” diagnosis. Both sit on the same dashboard.