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 |
- 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
- 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.
- 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.
- 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.
- 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.
-
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
-
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.
requestIdleCallbackfor 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.
-
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.
- 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.
- Read the Poor% slice. That’s where users are abandoning interactions.
- Profile the worst interaction in DevTools Performance panel with CPU throttle.
- Identify the long-running task (typically a third-party script’s synchronous init or a filter widget’s expensive query).
- Apply pattern-based fixes: defer, code-split, yield to scheduler.
- Re-measure 28 days post-ship.
| 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 | INP p75; this card decomposes by zone. |
crux_lcp_distribution | LCP distribution; same Good/NI/Poor view for LCP. |
crux_cls_distribution | CLS distribution; same Good/NI/Poor view for CLS. |
crux_inp_trend | INP trend over time; complements distribution snapshot. |
psi_js_execution | Lab JS execution time; root cause of poor INP. |
psi_lab_tbt | Lab Total Blocking Time; lab proxy for INP. |
psi_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. |