> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Load Speed Distribution, Website Performance (PageSpeed + CrUX) > Load Speed Distribution for Website Performance (PageSpeed + CrUX) stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how ... **Metrics type:** [Supporting Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Website Performance](/nerve-centre/connectors#connectors-by-type) ## 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** | Headline metrics: * **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) What the distribution is telling us: 1. **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. 2. **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). 3. **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. 4. **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.** 5. **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 6. **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 7. **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. 8. **Why this card is the most actionable LCP card.** `crux_lcp_p75` tells you whether you pass; `crux_lcp_distribution` tells 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. The diagnostic flow: 1. **Read the Poor% slice.** That's the revenue leak. 2. **Identify the long-tail driver** (slow connection, low-end device, cold cache, distant edge). 3. **Apply targeted remediation** for the specific driver. 4. **Re-measure 28 days post-ship** to confirm the slice has shrunk. Rapid-response playbook: | 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`](/nerve-centre/kpi-cards/website-performance/page-load-speed) | LCP p75; this card decomposes by zone. | | [`crux_inp_distribution`](/nerve-centre/kpi-cards/website-performance/responsiveness-distribution) | INP distribution; same Good/NI/Poor view for INP. | | [`crux_cls_distribution`](/nerve-centre/kpi-cards/website-performance/layout-shift-distribution) | CLS distribution; same Good/NI/Poor view for CLS. | | [`crux_lcp_trend`](/nerve-centre/kpi-cards/website-performance/load-speed-over-time) | LCP trend over time; complements distribution snapshot. | | [`psi_slowest_lcp_urls`](/nerve-centre/kpi-cards/website-performance/slowest-lcp-urls) | Worst LCP URLs (lab); identifies likely contributors to Poor%. | | [`psi_lab_lcp`](/nerve-centre/kpi-cards/website-performance/lab-load-speed) | 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. **Why the Vortex IQ distribution may differ from manual checks:** | 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. | **Cross-connector reconciliation:** complements `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. Use `psi_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. *** ### Tracked live in Vortex IQ Nerve Centre *Load Speed Distribution* is one of hundreds of KPI pulses Vortex IQ tracks across Website Performance (PageSpeed + CrUX) and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.