At a glance
INP side-by-side mobile vs desktop, surfacing the device-specific interaction-responsiveness gap. The CPU-driven gap: mobile users have slower CPUs (mid-tier Android emulation = 4x slowdown vs unthrottled desktop). The same JavaScript handler that runs in 80ms on desktop runs 320ms on mobile. Typical healthy gap: 100-300ms (desktop faster). Larger gaps signal mobile-specific JavaScript hotspots.
| What it counts | INP measurements from CrUX field data, mobile vs desktop. Reported side-by-side with the gap. INP is the longest interaction delay during the page lifecycle. |
| Sample type | Field data sourced from CrUX. Lab approximation via psi_lab_tbt per device. |
| Why mobile INP is structurally slower | CPU difference: mid-tier Android emulation runs JavaScript 4x slower than unthrottled desktop. A filter widget that runs in 100ms on desktop runs 400ms on mobile. Different interaction patterns: mobile users interact with mobile-specific widgets (cart drawer, mobile menu, touch handlers) that desktop users don’t trigger. |
| Healthy gap interpretation | 0-100ms gap: rare for ecommerce (mobile is structurally slower). 100-300ms gap: typical. 300-500ms gap: meaningful mobile-specific JS hotspots. 500+ms gap: mobile-broken interactions; users perceive site as unresponsive. |
| Reading the gap diagnostically | Large INP gap traces to JavaScript that runs differently on mobile: heavy filter widgets, currency switchers, cart drawers, search overlays. Fix patterns: yield to main thread, virtualise lists, debounce inputs, defer non-critical handlers. |
| Currency | n/a, two milliseconds + delta. |
| Time window | 28D rolling (CrUX field) per device profile. |
| Alert trigger | gap > 400ms (mobile-specific JS hotspot). |
| Sentiment key | psi_inp |
| 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, INP per-template Wednesday 15 May 26.| Page template | Mobile INP | Desktop INP | Gap | Read |
|---|---|---|---|---|
| Collection / lighting | 720ms | 280ms | 440ms | Concerning; filter widget mobile-broken |
| Collection / furniture | 680ms | 260ms | 420ms | Same filter widget pattern |
| Homepage | 380ms | 140ms | 240ms | Typical (currency switcher) |
| PDP / dining-table | 420ms | 180ms | 240ms | Typical (cart-drawer) |
| Search overlay | 460ms | 220ms | 240ms | Typical |
| Site p75 | 520ms | 220ms | 300ms | Borderline; collection pages dragging |
- Collection pages have concerning gaps (420-440ms). The faceted-search filter widget runs heavy JavaScript: each filter checkbox click triggers re-fetch + grid re-render + analytics fire. On desktop CPUs, the cumulative work fits in 280ms. On mid-tier mobile, the same work takes 720ms. Same code, different CPU.
-
The filter widget refactor is the highest-leverage mobile INP fix:
- Debounce rapid clicks so multiple filter selections don’t queue
- Virtualise the product grid so re-render cost is proportional to viewport, not catalogue
- Defer the analytics fire to
requestIdleCallbackso it doesn’t block the next interaction - Estimated post-fix: collection mobile INP drops from 720ms → 250-300ms; gap closes from 440ms → 60-80ms.
- Homepage, PDP, search gaps in 240ms range are typical and don’t require dedicated mobile work. Same code on slower CPU; the 240ms gap is the structural CPU difference.
- Critical caveat: INP gap doesn’t have a single fix-pattern like LCP gap (image responsive variants). Each high-INP interaction needs individual JS analysis and refactoring. More invasive work than mobile LCP fixes.
- Why this matters for ranking: Google’s CWV uses mobile INP for ranking. Mobile users experiencing 720ms filter clicks bounce at higher rates; the ranking signal reflects this.
- Identify worst-gap interactions. Lab TBT measurement per template surfaces them.
- Profile in DevTools with CPU throttling at 4x to approximate mobile conditions.
- Apply mobile-aware JS patterns: yield, debounce, virtualise, defer.
| Time horizon | Action |
|---|---|
| First 1 hour | Identify worst-gap interactions. |
| First week | Refactor the highest-traffic worst-INP interaction. |
| Day 28 | Field INP via crux_inp_p75 reflects the change. |
Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
psi_mobile_vs_desktop_score | Composite score gap. |
psi_mobile_desktop_lcp | LCP gap. |
psi_mobile_desktop_cls | CLS gap. |
psi_mobile_desktop_ttfb | TTFB gap. |
crux_inp_p75 | Field INP measurement. |
psi_lab_tbt | Lab TBT, the lab proxy for INP. |
psi_worst_inp_urls | Per-URL INP ranking. |
psi_unused_js | JS bundle size affects INP. |
psi_third_party_cost | Third-party JS often dominates INP. |
Reconciling against the vendor’s own dashboard
Where to look:- GSC Core Web Vitals, INP per device profile.
- Web Vitals Chrome extension, live INP measurement; toggle CPU throttling for mobile simulation.
- Chrome DevTools Performance tab, capture interactions with CPU 4x throttling.
| Reason | Direction | What to do |
|---|---|---|
| Window timing. | Vortex IQ lags 1-2 days | Wait for refresh. |
| Sample size. Mobile and desktop need separate volume thresholds. | Some sites have null desktop INP | Use lab proxy (psi_lab_tbt). |
crux_inp_p75, psi_worst_inp_urls).
Quick rule for support tickets: large INP gaps signal mobile-specific JS hotspots. Profile in DevTools with 4x CPU throttling enabled to surface them.