> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Responsiveness: Mobile vs Desktop, Website Performance (PageSpeed + CrUX) > Responsiveness: Mobile vs Desktop for Website Performance (PageSpeed + CrUX) stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters... **Metrics type:** [Supporting Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Website Performance](/nerve-centre/connectors#connectors-by-type) ## 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`](/nerve-centre/kpi-cards/website-performance/page-freeze-time) 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** | 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: | 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`](/nerve-centre/kpi-cards/website-performance/click-responsiveness) reflects the change. | ## Sibling cards merchants should reference together | Card | Why merchants reach for it | | ---------------------------------------------------------------------------------------------------------- | ----------------------------------- | | [`psi_mobile_vs_desktop_score`](/nerve-centre/kpi-cards/website-performance/mobile-vs-desktop-score) | Composite score gap. | | [`psi_mobile_desktop_lcp`](/nerve-centre/kpi-cards/website-performance/load-speed-mobile-vs-desktop) | LCP gap. | | [`psi_mobile_desktop_cls`](/nerve-centre/kpi-cards/website-performance/layout-stability-mobile-vs-desktop) | CLS gap. | | [`psi_mobile_desktop_ttfb`](/nerve-centre/kpi-cards/website-performance/server-speed-mobile-vs-desktop) | TTFB gap. | | [`crux_inp_p75`](/nerve-centre/kpi-cards/website-performance/click-responsiveness) | Field INP measurement. | | [`psi_lab_tbt`](/nerve-centre/kpi-cards/website-performance/page-freeze-time) | Lab TBT, the lab proxy for INP. | | [`psi_worst_inp_urls`](/nerve-centre/kpi-cards/website-performance/worst-inp-urls) | Per-URL INP ranking. | | [`psi_unused_js`](/nerve-centre/kpi-cards/website-performance/unused-javascript) | JS bundle size affects INP. | | [`psi_third_party_cost`](/nerve-centre/kpi-cards/website-performance/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. **Why the Vortex IQ INP gap may differ from external views:** | 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`](/nerve-centre/kpi-cards/website-performance/page-freeze-time)). | **Cross-connector reconciliation:** primarily internal (with [`crux_inp_p75`](/nerve-centre/kpi-cards/website-performance/click-responsiveness), [`psi_worst_inp_urls`](/nerve-centre/kpi-cards/website-performance/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](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.