Skip to main content
Metrics type: Supporting Metrics • Category: Website Performance

​
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.

​
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. What the gap analysis is telling us:
  1. 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.
  2. 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 requestIdleCallback so it doesn’t block the next interaction
    • Estimated post-fix: collection mobile INP drops from 720ms → 250-300ms; gap closes from 440ms → 60-80ms.
  3. 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.
  4. 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.
  5. 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.
The diagnostic flow:
  1. Identify worst-gap interactions. Lab TBT measurement per template surfaces them.
  2. Profile in DevTools with CPU throttling at 4x to approximate mobile conditions.
  3. Apply mobile-aware JS patterns: yield, debounce, virtualise, defer.
Rapid-response playbook:

​
Sibling cards merchants should reference together

​
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.
Why the Vortex IQ INP gap may differ from external views: Cross-connector reconciliation: primarily internal (with 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.

​
Known limitations / merchant FAQs

Why is mobile INP so much slower than desktop? CPU difference. Lighthouse mobile applies 4x CPU slowdown emulating mid-tier Android; desktop is unthrottled. The same JavaScript code takes 4x longer to execute on the mobile profile. Can I make mobile INP match desktop INP? Not exactly; the CPU difference is structural. Target: mobile INP under 200ms (Google’s good threshold), accepting a 100-300ms gap to desktop. Pushing past 100ms gap requires architectural-level work. My collection page mobile INP is 720ms. What now? Refactor the filter widget. Apply: debounce rapid clicks; virtualise product grid; defer analytics; yield to main thread between heavy work. Each pattern saves 50-150ms. Is mobile INP harder to fix than mobile LCP? Yes, generally. Mobile LCP fixes are mostly mechanical (image format, responsive variants). Mobile INP fixes require code changes: refactor heavy widgets, restructure JS, defer non-critical handlers. A 4-week INP recovery cycle is typical; LCP recovery completes in 1-2 weeks. Should I migrate to Catalyst for mobile INP? Catalyst (Next.js) has structurally better mobile INP than Stencil because of better state-management defaults and code-splitting. Typical Catalyst mobile INP: 200-300ms. Typical Stencil mobile INP: 400-600ms. Migration is one of the strongest mobile INP wins.

​
Tracked live in Vortex IQ Nerve Centre

Responsiveness: Mobile vs Desktop 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 or book a demo to see this metric running on your own data.