At a glance
LCP side-by-side mobile vs desktop, surfacing the device-specific load-speed gap. The LCP gap is the largest contributor to the overall mobile-vs-desktop score gap because LCP is heavily network-dependent and mobile networks are slower. Typical healthy gap: 1,000-2,500ms (desktop faster). Larger gaps signal mobile-specific image / network issues; smaller gaps suggest a well-optimised mobile experience.
| What it counts | Two LCP measurements from the same URL, one per device profile. Reported side-by-side with the gap. Each measurement is a single Lighthouse audit run per device. |
| Sample type | Lab data from two Lighthouse runs. Field equivalents available via crux_lcp_p75 (mobile + desktop separately). |
| Why mobile LCP is structurally slower | (1) Slow 4G throttling (1.6 Mbps down vs unthrottled desktop), for a 2.8MB hero image, mobile takes ~14 seconds to download vs ~0.5 seconds on desktop. (2) Different LCP element selection: smaller mobile viewport may select a different “largest” element (often the hero image where desktop selects the header text). (3) Less browser cache benefit: mobile users more often hit cold cache. |
| Healthy gap interpretation | 0-800ms gap: site is well-tuned for mobile; structural emulation differences explain the gap. 800-2,500ms gap: typical for ecommerce. 2,500-4,000ms gap: meaningful mobile-specific issues (oversized images served to mobile). 4,000+ms gap: mobile-broken; mobile users experience seriously degraded load times. |
| Reading the gap diagnostically | Large LCP gap usually traces to image-related issues: hero images served at desktop resolution to mobile viewports, missing srcset responsive variants, no loading="eager" + <link rel="preload"> for the LCP element. Fix is mostly mechanical: image format conversion + responsive variants closes the gap dramatically. |
| Currency | n/a, two milliseconds + delta. |
| Time window | T/7D |
| Alert trigger | gap > 3,000ms (mobile-broken signal). |
| Sentiment key | psi_lcp |
| 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 LCP per template Wednesday 15 May 26.| Page template | Mobile LCP | Desktop LCP | Gap | Read |
|---|---|---|---|---|
| Homepage | 4,820ms | 1,920ms | 2,900ms | Concerning; hero image not served at mobile size |
| Product detail page | 3,640ms | 1,540ms | 2,100ms | Typical |
| Collection page | 4,210ms | 1,840ms | 2,370ms | Borderline |
| Cart | 2,180ms | 1,420ms | 760ms | Healthy |
| Checkout | 1,940ms | 1,180ms | 760ms | Healthy |
| Site-weighted average | 3,920ms | 1,720ms | 2,200ms | Typical-to-borderline |
-
Homepage gap of 2,900ms is the dominant problem. The hero PNG carousel (4 images at 2.8MB total) downloads quickly on desktop wifi but takes 12+ seconds on slow 4G mobile. The fix: responsive variants via
srcsetso mobile downloads 400KB-sized variants instead of 2.8MB full-resolution. Estimated post-fix mobile LCP: 2,400-2,800ms; gap closes to 800-1,000ms. - PDP and collection gaps in 2,100-2,400ms range are typical-to-borderline. Same fix-pattern: image format + responsive variants. Combined fix lifts mobile LCP across all three high-traffic templates.
- Cart and checkout have healthy 760ms gaps. No mobile-specific work needed; transactional pages are already lean.
- The aggregate gap of 2,200ms is right at the borderline between “typical” and “concerning”. The high-traffic templates (homepage, PDP, collection) drive the gap; the lighter pages (cart, checkout) don’t contribute meaningfully.
- Recovery target: close the gap to 800-1,200ms across all templates. Combined fix-cycle: image responsive variants on hero + product + collection images. Estimated 2-3 weeks of focused work; lifts mobile LCP from 3,920ms toward 2,200-2,400ms (good band).
- Identify templates with concerning gaps (>2,500ms or >3,000ms). Concentrate there.
- Decompose by LCP element type. Hero image gap = image fix; hero text gap (rare) = render-blocking fix.
- Apply mobile-specific image work: responsive variants via
srcset,loading="eager"on LCP image,<link rel="preload">.
| Time horizon | Action |
|---|---|
| First 1 hour | Identify worst-gap templates. |
| First 24 hours | Add srcset responsive variants to hero images. |
| First 7 days | Mobile LCP improvement visible in lab. |
| Day 28 | Field LCP via crux_lcp_p75 reflects the change. |
Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
psi_mobile_vs_desktop_score | Composite score device gap. |
psi_mobile_desktop_inp | INP device gap. |
psi_mobile_desktop_cls | CLS device gap. |
psi_mobile_desktop_ttfb | TTFB device gap. |
crux_lcp_p75 | LCP field measurement (mobile by default). |
psi_image_optimisation | Image responsive-variants is the dominant LCP gap fix. |
psi_lab_lcp | Lab LCP measurement. |
Reconciling against the vendor’s own dashboard
Where to look:- PageSpeed Insights, toggle Mobile / Desktop tabs; LCP appears in field section.
- Chrome DevTools → Lighthouse panel, choose device profile.
| Reason | Direction | What to do |
|---|---|---|
| Run-to-run variance. Each profile has independent variance ±10-20%. | Either direction | Use 7-day rolling. |
| Throttling profile differences. Lighthouse uses canonical profiles; some local audits use custom throttling. | Small | Confirm canonical profiles in use. |
psi_mobile_vs_desktop_score, crux_lcp_p75).
Quick rule for support tickets: if a merchant says “my LCP gap is 4 seconds, what now?”, the answer is responsive image variants via srcset. The gap is almost always image-driven on ecommerce sites.
Known limitations / merchant FAQs
Why is my mobile LCP 4 seconds slower than desktop? Mobile-specific image issue, almost always. Hero images served at desktop resolution (1920px wide) take 14+ seconds to download on slow 4G. Addsrcset responsive variants so mobile downloads 400-800px-wide versions instead.
Will responsive variants fix this?
Yes, dramatically. Typical mobile LCP improvement from srcset implementation: 1,500-2,500ms. The gap to desktop closes from 3,000ms+ to 800-1,200ms.
My BC Stencil theme says it handles responsive images. Is that enough?
Verify in DevTools Network. Theme defaults sometimes don’t include enough breakpoint variants for modern device sizes. Check: are there variants at 400px, 600px, 800px, 1200px widths? If only 1920px exists, mobile gets the desktop image.
Should I optimise mobile LCP to match desktop LCP?
Approximately. Target mobile LCP under 2,500ms (Google’s good threshold). The gap to desktop’s typical 1,500ms is structural and acceptable. Closing past 1,000ms gap requires architectural-level work usually not justified.
Can image-CDN handle this automatically?
Yes, if configured. Cloudinary, imgix, BC’s image CDN handle format negotiation + responsive resizing automatically when the theme HTML uses appropriate srcset. The merchant’s responsibility: ensure the theme HTML opts in.