At a glance
Per-URL ranking of pages with the worst Interaction to Next Paint, sorted descending. Surfaces individual URLs with their INP value, traffic share, and the dominant slow interaction (filter widget, sort dropdown, cart-drawer mount, etc.). Completes the per-URL CWV trio alongsidepsi_slowest_lcp_urlsandpsi_worst_cls_urls. INP is the most JavaScript-driven of the three CWVs, so per-URL ranking surfaces interactive widgets that need engineering attention.
| What it counts | List of audited URLs with their p75 INP value, traffic share, the worst interaction type captured during audit (or via field-data CrUX URL-level), and recommended fix. Sorted descending by INP. |
| Sample type | Mixed: Lab Total Blocking Time (lab approximation of INP) for synthetic measurement, plus field INP from CrUX URL-level dataset where available. |
| Why per-URL matters for INP | INP is interaction-driven; specific widgets on specific URLs fail it. Collection pages with filter widgets fail differently than PDPs with cart-drawer mounts. Per-URL ranking lets the merchant target specific widget refactors rather than treating INP as site-wide. |
| INP × traffic ranking | Same logic as LCP and CLS cards: commercial impact = INP × traffic share. The card surfaces both dimensions. |
| Common dominant slow interactions | (1) Collection page: filter checkbox click → faceted-search re-fetch + grid re-render. (2) PDP: “Add to cart” button → cart-drawer mount + analytics fire. (3) Currency switcher: page-wide price recalculation. (4) Search overlay: modal mount + product-search fetch. (5) Sort dropdown: change handler + grid re-render. (6) Mobile menu: drawer animation + JS state management. |
| Currency | n/a, list with millisecond annotations. |
| Time window | T (current state) for lab; 28D for field measurements where available. |
| Alert trigger | top URL > 500ms INP (any single URL in the poor band). |
| Sentiment key | null |
| 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 US-based BigCommerce home goods store, 30-URL audit, mobile, Wednesday 15 May 26.| Rank | URL | p75 INP | Traffic share | Dominant slow interaction | INP × traffic |
|---|---|---|---|---|---|
| 1 | /collections/lighting | 720ms | 8.4% | Filter checkbox click (612ms) + sort dropdown (484ms) | 60.5 |
| 2 | /collections/furniture | 680ms | 6.8% | Same filter widget pattern | 46.2 |
| 3 | /collections/all-products | 612ms | 5.4% | Same filter widget pattern | 33.0 |
| 4 | / (homepage) | 380ms | 22.0% | Currency switcher (720ms when used) | 83.6 |
| 5 | /collections/sale | 540ms | 7.8% | Filter widget | 42.1 |
| 6 | /products/dining-table-large | 420ms | 4.2% | Cart-drawer mount (cart-add interaction) | 17.6 |
| 7 | /collections/decor | 480ms | 5.6% | Filter widget | 26.9 |
| 8 | /products/floor-lamp-modern | 380ms | 3.8% | Cart-drawer mount | 14.4 |
| 9 | /search | 460ms | 2.4% | Search-result render after type | 11.0 |
| 10 | /cart | 220ms | 12.0% | Quantity update interaction | 26.4 |
- The homepage at INP 380ms ranks #4 by absolute but #1 by INP × traffic (83.6 weighted score). Despite faster absolute INP than collection pages, the 22 percent traffic share dominates. The currency switcher is the slow interaction, page-wide price recalculation triggered when users switch from USD to GBP/EUR/CAD. The homepage currency switcher is the highest-leverage INP fix.
- Collection pages cluster at INP 480-720ms with the same dominant interaction: the filter checkbox click. The faceted-search filter widget re-fetches and re-renders the product grid synchronously. One template-level fix (debounce + virtualise + defer analytics) improves all 12 collection pages simultaneously. Estimated post-fix: collection p75 INP drops to 200-280ms.
- PDPs (ranks 6, 8) have INP 380-420ms with cart-drawer mount as the dominant interaction. The drawer mount triggers a JS-heavy component that causes a long task before paint. Refactor cart-drawer to use CSS-driven slide animation with progressive enhancement; estimated post-fix: PDP p75 INP drops to 150-200ms.
- The cart page at INP 220ms is healthy but high-traffic (12 percent share), making it #4 by INP × traffic ranking. Don’t optimise; monitor for regression.
- Search page (rank 9) has INP 460ms, search-result rendering is the slow interaction. Lower priority due to low traffic share but worth a refactor when bandwidth allows.
-
The recommended fix sequence by INP × traffic:
- Week 1: Homepage currency switcher refactor. Single biggest weighted impact.
- Week 2: Collection page filter widget refactor. Affects 12 pages simultaneously.
- Week 3: PDP cart-drawer mount refactor. Affects 78 PDPs simultaneously.
- Week 4: Search-result rendering. Lower-priority polish.
-
Cumulative impact estimation: completing the four refactors above drops site-wide weighted INP by 60-75 percent. Mobile origin p75 INP drops from 520ms (current per
crux_inp_p75earlier example) toward 220-280ms, moving from “poor” band into “good” band. CWV pass rate impact: INP portion lifts 6-10 percentage points toward all-three pass rate.
- Sort by INP × traffic. The absolute-slowest URL may not be the highest commercial impact.
- Identify shared dominant interactions. When the same widget pattern (filter, sort, cart-drawer) appears across multiple URLs, a template-level refactor is more efficient.
- Profile the slow interaction in DevTools Performance tab. Capture a real interaction; identify the JS handler causing the long task.
- Apply optimisation patterns: yield to main thread, debounce, virtualise lists, defer non-critical work.
| Time horizon | Action |
|---|---|
| First 1 hour | Identify top 3 by INP × traffic; identify dominant interaction per URL. |
| First 24 hours | Profile the worst interaction in DevTools; plan the refactor. |
| First 7 days | Implement and ship the highest-leverage refactor. |
| First 30 days | Field INP fully reflects fix; re-rank. |
Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
crux_inp_p75 | Origin-level INP; this card decomposes by URL. |
psi_slowest_lcp_urls | Per-URL ranking for LCP. |
psi_worst_cls_urls | Per-URL ranking for CLS. |
psi_all_cwv_pass | Per-URL all-three CWV pass status. |
psi_biggest_regression | URLs with biggest INP regression vs prior period. |
psi_lab_tbt | Lab Total Blocking Time, the lab approximation of INP. |
psi_unused_js | JS bundle size correlates with INP; reducing unused JS reduces interaction cost. |
psi_third_party_cost | Third-party scripts often contribute to interaction slowness. |
psi_js_execution | Total JS execution time. |
crux_inp_distribution | Distribution of INP values across users. |
psi_perf_score_summary | Composite score; TBT (lab INP proxy) is 30 percent of the weight. |
Reconciling against the vendor’s own dashboard
Where to look:- Web Vitals Chrome extension, measures INP per-interaction live; the most useful diagnostic tool.
- Chrome DevTools → Performance tab, capture interactions; long tasks visible in Bottom-Up view.
- Chrome DevTools → Performance Insights tab, surfaces INP for specific interactions during recording.
- CrUX URL-level dataset, for high-traffic URLs, field INP per URL.
| Reason | Direction | What to do |
|---|---|---|
| Lab vs field. Lab uses TBT as a proxy for INP; field measures actual interactions. | Different metric basis | Confirm with field-data CrUX URL-level when available. |
| Interaction selection. The audit captures specific interactions; real users may interact with different elements. | Either direction | Add manual interaction profiling for critical user paths. |
| Device profile. Lab uses mid-tier mobile; some users have faster or slower devices. | Either direction | The mid-tier emulation represents the average; field shows the distribution. |
crux_inp_p75, psi_lab_tbt, psi_third_party_cost).
Quick rule for support tickets: if a merchant says “my collection page feels fast but you say INP is 720ms”, the merchant is likely on a faster device than mid-tier emulation. Use Chrome DevTools’ CPU throttling (4x slowdown) to approximate the real-user experience.
Known limitations / merchant FAQs
My top INP URL is a high-traffic page but I can’t change the framework. What can I do? Most INP fixes don’t require framework changes. Common patterns: (1) Debounce rapid input (filter checkboxes, search-as-you-type); (2) Yield to the main thread between heavy work usingsetTimeout(fn, 0) or scheduler.postTask; (3) Defer analytics tracking to requestIdleCallback; (4) Virtualise long lists so re-render cost is bounded by viewport. None of these require switching frameworks.
Why does the homepage have a 720ms INP when I rarely touch the currency switcher?
INP is reported as the longest interaction during the session. If a single user happens to use the currency switcher, that 720ms gets reported even though most users never touch it. Field INP includes the worst case, not just typical. The fix: optimise the worst-case interaction even if it’s used by few users.
Can Vortex IQ tell me exactly which JS function is slow?
Indirectly. The card identifies the dominant interaction; profiling in DevTools Performance tab surfaces the specific function. Lighthouse’s audit JSON includes the script URL where the long task occurred but not the function name (without source maps).
Should I refactor the filter widget or replace it entirely?
Depends on engineering bandwidth. Refactor (1-2 weeks): debounce, virtualise, defer analytics. Typically saves 60-70 percent of the interaction cost. Replace (4-8 weeks): switch from JS-driven filter to URL-driven filter (each filter click is a new page navigation rather than client-side re-render). Slightly slower per-click but architecturally simpler and indexable. The right choice depends on the brand’s stage and engineering team.
My BC site uses Catalyst not Stencil. Does this still apply?
Yes, with different patterns. Catalyst sites typically have lower baseline INP (better state management, automatic code-splitting); the worst-INP URLs tend to be search results and complex PDPs with many configurable options. The card surfaces them; the fix patterns (yield to main thread, virtualise lists) apply equivalently.
Can Vortex IQ refactor the widget for me?
Read-only by design. Vortex IQ identifies issues; engineering implements.