At a glance
Lab Performance Score side-by-side mobile vs desktop, surfacing the gap between the two profiles. The “are we mobile-broken” diagnostic: mobile-first indexing means Google primarily ranks on mobile CWV, but most engineering teams develop on desktop and may miss mobile-specific issues. Typical healthy gap: 15-30 points (desktop higher). Larger gaps suggest mobile-specific problems (heavy mobile JS, mobile-only widgets, responsive image issues) that desktop development workflows don’t surface.
| What it counts | Two Lighthouse Performance Score values from the same URL, one with mobile profile (Slow 4G + mid-tier CPU emulation) and one with desktop profile (unthrottled). Reported side-by-side with the gap. |
| Sample type | Lab data from two Lighthouse audit runs (one per device profile). |
| Why this matters | Mobile-first indexing means mobile is the priority for ranking, but engineering teams develop on desktop and may not notice mobile-specific issues. The score gap surfaces this blind spot: if desktop is 90 but mobile is 40, the site is fundamentally desktop-biased and mobile users (who matter most for ranking) are getting a worse experience. |
| Typical gap interpretations | 0-15 point gap: site is well-tuned for mobile; structural emulation differences explain the gap. 15-30 point gap: typical for ecommerce; mobile-specific optimisation work would help but isn’t critical. 30-50 point gap: meaningful mobile-only issues; investigate mobile-specific JS, image variants, viewport handling. 50+ point gap: mobile-broken; ranking-impact territory; urgent fix work needed. |
| Why the gap exists structurally | (1) Slow 4G emulation vs unthrottled desktop network = 5-10x bandwidth difference. (2) Mid-tier CPU emulation vs unthrottled desktop CPU = 4x JS execution time difference. (3) Smaller viewport selects different LCP elements (mobile may select hero image where desktop selects header text). (4) Mobile-specific widgets (cart drawer, mobile menu, touch handlers) add JS only on mobile. |
| Reading the gap diagnostically | If LCP gap is large but other metrics’ gaps are small → mobile image/network issue. If TBT gap is large → mobile-specific JS or third-party cost. If CLS gap is large → mobile-specific late-loading widgets. Each gap pattern points to a different fix focus. |
| Currency | n/a, two 0-100 scores. |
| Time window | T/7D |
| Alert trigger | gap > 40 points (mobile-broken signal). |
| Sentiment key | null (comparison view). |
| Roles | owner, marketing, 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 UK-based BigCommerce fashion store, lab measurements per template Wednesday 15 May 26.| Page template | Mobile score | Desktop score | Gap | Read |
|---|---|---|---|---|
| Homepage | 42 | 76 | 34 points | Concerning gap; mobile-specific issues |
| Product detail page | 58 | 82 | 24 points | Typical gap |
| Collection page | 48 | 79 | 31 points | Concerning; collection-page filter widget JS-heavy on mobile |
| Cart | 62 | 88 | 26 points | Typical |
| Checkout | 71 | 92 | 21 points | Typical |
| Site-weighted average | 51 | 81 | 30 points | Borderline; mobile-side work would help |
- Site-wide gap of 30 points sits at the borderline between “typical” and “concerning”. Desktop is healthy; mobile is dragging the overall picture. This is the textbook pattern for ecommerce sites built without dedicated mobile performance discipline.
- The homepage and collection pages have the largest gaps (34 and 31 points). Both pages have mobile-specific friction: the homepage hero carousel renders differently on mobile (4 unoptimised PNGs that are oversized for mobile viewport); the collection page’s filter widget runs heavy JS that mid-tier mobile CPUs struggle with.
- PDPs and checkout have typical gaps (24 and 21 points), suggesting mobile-specific work isn’t urgently needed there. The work to do concentrates on homepage + collection.
-
The fix isn’t to “make desktop slower”, it’s to lift mobile to closer parity. Recommended optimisation focus:
- Homepage: image responsive variants via
srcset(saves 1.5-2MB on mobile); defer hero video carousel for mobile - Collection page: virtualise filter-widget grid on mobile; debounce filter clicks; defer non-critical JS
- Estimated post-fix mobile score uplift: homepage 42 → 65, collection 48 → 70
- Homepage: image responsive variants via
- Why this matters for ranking: Google’s mobile-first indexing primarily uses mobile CWV. A 30-point mobile-vs-desktop gap signals mobile is the priority work; closing it lifts ranking impact.
- Compare to industry: brands that follow strict mobile-first development discipline operate at 5-15 point gaps. Brands like Shopify, Catalyst-on-BigCommerce, and modern Next.js sites often operate at <10 point gaps because their frameworks default to mobile-friendly patterns. Stencil-themed BC sites typically run 25-40 point gaps because Stencil defaults aren’t aggressively mobile-optimised.
- Read the gap; classify (0-15 healthy, 15-30 typical, 30-50 concerning, 50+ urgent).
- For concerning/urgent gaps, decompose by sub-metric: which CWV has the biggest mobile-vs-desktop gap?
- Apply mobile-specific fix patterns: responsive images, mobile-aware widget loading, mobile-specific JS deferral.
- Re-audit to confirm the gap closes.
| Time horizon | Action |
|---|---|
| First 1 hour | Decompose gap by sub-metric. |
| First 24 hours | Apply highest-leverage mobile fix (typically image responsive variants). |
| Day 7 | Re-audit; confirm mobile score improvement. |
| Day 28 | Field metrics confirm via crux_mobile_pass. |
Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
psi_mobile_score_compare | Per-template mobile/desktop comparison. |
psi_mobile_desktop_lcp | LCP-specific device gap. |
psi_mobile_desktop_inp | INP-specific device gap. |
psi_mobile_desktop_cls | CLS-specific device gap. |
psi_mobile_desktop_ttfb | TTFB-specific device gap. |
crux_mobile_pass | Mobile-only field pass rate. |
crux_desktop_pass | Desktop-only field pass rate. |
psi_perf_score_summary | Composite score (mobile by default). |
psi_image_optimisation | Common mobile-specific fix lever. |
Reconciling against the vendor’s own dashboard
Where to look:- PageSpeed Insights, toggle between Mobile and Desktop tabs at the top of the report.
- Chrome DevTools → Lighthouse panel, choose Mobile or Desktop device profile.
- WebPageTest, supports custom device emulation including the same mobile/desktop split.
| Reason | Direction | What to do |
|---|---|---|
| Run-to-run variance. Each device profile has independent variance. | Either direction | Use 7-day rolling for trend reads. |
| Default profile differences. PSI uses Google’s standard mobile/desktop profiles; some Lighthouse implementations use slightly different throttling. | Small | Confirm both views use canonical Lighthouse profiles. |