> ## 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. # Responsiveness Distribution, Website Performance (PageSpeed + CrUX) > Responsiveness Distribution for Website Performance (PageSpeed + CrUX) stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and ... **Metrics type:** [Supporting Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Website Performance](/nerve-centre/connectors#connectors-by-type) ## At a glance > **INP distribution across the Good / Needs Improvement / Poor zones from real users (CrUX field data)**, shows the percentage of user interactions falling into each INP zone over the 28-day rolling window. **INP is the most failed CWV for ecommerce as of 2026** because it captures interactivity under real-world conditions: every tap on Add-to-Cart, every filter selection, every variant swap, every checkout step contributes to INP. The distribution exposes whether interactions are sluggish for a small minority (manageable) or for a meaningful fraction of users (revenue-impacting). | | | | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | The percentage of real-user interactions that fall in each INP zone, computed across the 28-day rolling window: **Good** (INP ≤ 200ms), **Needs Improvement** (200ms \< INP ≤ 500ms), **Poor** (INP > 500ms). Distribution sums to 100% and is reported per origin (or per URL when sample permits). Replaced FID in March 2024 as the official CWV interactivity metric. | | **Sample type** | **Field data** from Chrome User Experience Report; aggregated across all real users on Chrome who opted into anonymous metrics syncing. | | **Why INP distribution is critical for ecommerce** | INP measures the worst interaction during a session. **A single janky tap on Add-to-Cart can fail the metric for the whole visit.** Ecommerce sessions involve many interactions (filtering, sorting, swatches, quantity changes, checkout steps), INP failure rates are systematically higher for ecommerce than for content sites. The distribution exposes whether the failures are concentrated on a few critical interactions (add-to-cart, checkout) or spread across the page. | | **Reading the distribution** | (1) Healthy ecommerce target: Good 75%+, NI 15-20%, Poor below 5%. (2) Anything above 10% Poor signals a main-thread bottleneck affecting many users. (3) Compare against `crux_inp_p75`, distribution explains *why* p75 sits where it does. (4) Cross-reference `psi_js_execution` and `psi_lab_tbt` for the lab-side root cause. (5) Profile the worst-offending interaction in DevTools Performance panel. | | **Currency** | percent (Good %, NI %, Poor %). | | **Time window** | `28D` (CrUX rolling window). | | **Alert trigger** | `Poor% > 10%` (significant interactivity failure rate). | | **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 INP distribution as of Wednesday 15 May 26 (28-day window). | Zone | INP range | % of interactions | Sentiment | Status | | ----------------- | ------------- | ----------------: | -------------- | ----------------------------- | | Good | ≤ 200ms | 58% | Watch | Below 75% target | | Needs Improvement | 200ms - 500ms | 28% | Watch | Above typical range | | **Poor** | **> 500ms** | **14%** | **Concerning** | **Above 10% alert threshold** | Headline metrics: * **p75 INP**: 320ms (in NI zone, fails the CWV threshold) * **Good %**: 58% (target is 75%+) * **Poor %**: 14% (alert threshold is 10%) * **28-day sample**: \~1.2M interactions What the distribution is telling us: 1. **Site fails CWV INP threshold.** p75 of 320ms sits in NI; Google's pass criterion requires p75 ≤ 200ms. Search rankings are impacted; AI Overview citation is reduced. 2. **Poor% at 14% means roughly 168,000 interactions in the past 28 days were severely sluggish.** Each Poor interaction is a moment when a user tapped, then waited a half-second or more for the page to respond. **Add-to-Cart taps, filter selections, and checkout steps in this slice are abandonment-prone**. 3. **The 14% Poor slice is the actionable target.** Moving NI from 28% to 24% delivers marginal user experience improvement. Moving Poor from 14% to 5% recovers the worst experiences, the ones most likely to result in rage-clicks, abandonment, and churn. 4. **Why distribution diverges from p75.** The site has a long-tail of slow interactions (likely on PDPs with the reviews widget or on collection pages with the filter widget). p75 only sees the threshold; the distribution sees the long tail magnitude. 5. **Likely drivers of the Poor% slice (cross-reference `psi_js_execution`):** * Heavy filter widget JS on collection pages (parsing time blocks every interaction) * Yotpo reviews widget initialisation on PDPs (steals main thread on Add-to-Cart taps near page load) * GTM container with 30+ tags firing in sequence on every page change * Hotjar / FullStory session-replay scripts running synchronously * Klaviyo onsite SDK initialisation interfering with first-tap responsiveness 6. **Targeted fixes for the Poor% slice:** * **Defer non-critical third parties until idle**, Yotpo, Klaviyo, Hotjar, GTM tags. Saves 200-400ms on first-interaction INP. * **Code-split filter widget**, load the filter JS only when the user opens the filter panel, not on page load. Saves 150-300ms on collection-page interactions. * **`requestIdleCallback` for non-critical work**, schedule analytics, retargeting, SDK init on idle frames so user interactions get priority. * **`scheduler.yield()` (or setTimeout 0) in long tasks**, break up long synchronous JS to allow input handling between chunks. * **Replace synchronous third-party scripts with async/defer + lazy initialisation**. 7. **Recommended ship sequence:** * **Week 1**: Defer Yotpo + Klaviyo + Hotjar to idle. Saves Poor% from 14% → 9%. * **Week 2**: Code-split filter widget. Saves Poor% from 9% → 6%. * **Week 3**: Audit and split long tasks > 50ms in theme bundle. Saves Poor% from 6% → 4%. * **Re-audit at 28 days post-ship**: Poor% in 3-5% range. p75 lifts to under 200ms. CWV INP passes. 8. **Why INP is harder to fix than LCP.** LCP is dominated by the single largest above-the-fold element (typically the hero image), fix that one element and LCP improves. INP captures the worst interaction across the entire session, could be anywhere in the page lifecycle. **Fixing INP requires breaking up long tasks site-wide rather than optimising one asset.** The diagnostic flow: 1. **Read the Poor% slice.** That's where users are abandoning interactions. 2. **Profile the worst interaction in DevTools Performance panel** with CPU throttle. 3. **Identify the long-running task** (typically a third-party script's synchronous init or a filter widget's expensive query). 4. **Apply pattern-based fixes**: defer, code-split, yield to scheduler. 5. **Re-measure 28 days post-ship.** Rapid-response playbook: | Time horizon | Action | | ------------ | ------------------------------------------------------- | | First 1 hour | Read distribution. Identify Poor% magnitude. | | First day | Profile worst-offending interaction in DevTools. | | First week | Defer non-critical third parties. | | Day 14 | Code-split or yield in long tasks. | | Day 28 | Re-measure CrUX distribution; confirm Poor% has shrunk. | ## Sibling cards merchants should reference together | Card | Why merchants reach for it | | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------- | | [`crux_inp_p75`](/nerve-centre/kpi-cards/website-performance/click-responsiveness) | INP p75; this card decomposes by zone. | | [`crux_lcp_distribution`](/nerve-centre/kpi-cards/website-performance/load-speed-distribution) | LCP distribution; same Good/NI/Poor view for LCP. | | [`crux_cls_distribution`](/nerve-centre/kpi-cards/website-performance/layout-shift-distribution) | CLS distribution; same Good/NI/Poor view for CLS. | | [`crux_inp_trend`](/nerve-centre/kpi-cards/website-performance/responsiveness-over-time) | INP trend over time; complements distribution snapshot. | | [`psi_js_execution`](/nerve-centre/kpi-cards/website-performance/js-execution-time) | Lab JS execution time; root cause of poor INP. | | [`psi_lab_tbt`](/nerve-centre/kpi-cards/website-performance/page-freeze-time) | Lab Total Blocking Time; lab proxy for INP. | | [`psi_third_party_cost`](/nerve-centre/kpi-cards/website-performance/third-party-cost) | Third-party tax; major contributor to Poor% INP. | ## Reconciling against the vendor's own dashboard **Where to look in Website Performance (PageSpeed + CrUX)'s own dashboard:** The Website Performance (PageSpeed + CrUX) dashboard surfaces this metric (or its components) under the relevant report section. Confirm period boundaries and filter settings match the Vortex IQ profile to reconcile cleanly. **Why the Vortex IQ value may legitimately differ:** | Reason | Direction | What to do | | ---------------------------------------------------------------------------------------------------------- | --------- | ------------------------ | | **Period boundary.** Vortex IQ uses 30-day rolling by default; vendor dashboards may use calendar periods. | Variable | Match the period range. | | **Time zone.** Vendor uses account time zone; Vortex IQ aligns to merchant reporting time zone. | Marginal | Confirm time zone match. | | **Filter scope.** Profile-level filters (channel, B2B, test orders) may narrow the Vortex IQ view. | Variable | Match filter settings. | **Cross-connector reconciliation:** complement with sibling cards in the same category for the full diagnostic picture. For divergence investigations, use Vortex Mind. ## Known limitations / merchant FAQs **Q: How often does Responsiveness Distribution update?** The card refreshes on the standard data refresh (typically every 30-60 minutes for live integrations). For real-time signals, force a manual refresh from the dashboard. **Q: Why does my Website Performance (PageSpeed + CrUX) dashboard show a different number?** The most common reasons are period-boundary differences (Vortex IQ uses 30-day rolling vs vendor's calendar months), time-zone alignment, and filter scope (profile-level vs vendor's all-account view). Match these settings before assuming a real divergence. **Q: How does Responsiveness Distribution relate to other core web vitals metrics?** Track this card alongside the siblings listed above to build a complete picture. Single-metric reads can mislead; the diagnostic value is in the cross-reference. **Q: Can I customise the alert threshold?** Yes, alert thresholds are configurable per profile in the Alert Rules tab. Adjust to match your business baseline rather than relying on the generic default. *** ### Tracked live in Vortex IQ Nerve Centre *Responsiveness 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.