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.
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.
What the per-URL view is telling us:
- 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.
Sibling cards merchants should reference together
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.
Cross-connector reconciliation: primarily internal (with
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.