Skip to main content
Card class: Non-HeroCategory: Website Performance

At a glance

TTFB side-by-side mobile vs desktop, surfacing the device-specific server-response gap. Network-driven gap: mobile networks have higher latency than fixed broadband. Even the same edge POP serving the same content responds faster to broadband desktop users than 4G mobile users. Typical healthy gap: 200-500ms (desktop faster). Larger gaps signal mobile-network-specific issues or geographic distribution skew.
What it countsTTFB measurements from CrUX field data, mobile vs desktop. Reported side-by-side with the gap.
Sample typeField data sourced from CrUX. Lab equivalent (per-device): psi_server_response.
Why mobile TTFB is structurally slower(1) Mobile network latency: 4G/5G mobile typically adds 50-150ms to RTT vs broadband. (2) Mobile users in worse network conditions: signal strength variability, network congestion, edge-of-coverage. (3) Mobile geographic mix: mobile users are more frequently on the move and may hit different edge POPs than desktop users from fixed locations.
Healthy gap interpretation0-200ms gap: server is fast enough that mobile network latency is the only structural difference. 200-500ms gap: typical. 500-1,000ms gap: meaningful mobile network or routing issues. 1,000+ms gap: indicates major mobile-vs-desktop infrastructure difference (CDN POPs not optimised for mobile RTT, origin response time variable).
Reading the gap diagnosticallyTTFB gap is mostly determined by network and CDN factors, not by site code changes. Common causes of large gaps: (a) CDN POPs serving mobile traffic from distant edges; (b) mobile users on poor-quality networks (some carriers have higher RTT); (c) CDN cache-miss rate higher for mobile (different caching keys, mobile-specific URLs).
Currencyn/a, two milliseconds + delta.
Time window28D rolling (CrUX field) per device profile.
Alert triggergap > 800ms (mobile-network or routing issue).
Sentiment keypsi_ttfb
Rolesowner, 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, TTFB per-template Wednesday 15 May 26.
Page templateMobile TTFBDesktop TTFBGapRead
Homepage1,180ms720ms460msTypical
Product detail page1,420ms880ms540msTypical
Collection page1,680ms1,040ms640msBorderline
Cart380ms240ms140msHealthy
Checkout540ms320ms220msTypical
Site p751,180ms720ms460msTypical gap
What the gap analysis is telling us:
  1. Site-wide TTFB gap of 460ms is in the typical band. Mobile users pay a 460ms penalty over desktop users for the same content; this is mostly mobile network RTT and is largely structural. Not a primary optimisation target, fixing TTFB overall (covered in psi_caching_opportunities) lifts both mobile and desktop together.
  2. Collection page gap of 640ms is borderline concerning. Could indicate the page has more cache-miss visitors on mobile (mobile users hitting different edge POPs) or some mobile-specific routing issue. Worth investigating CDN dashboard for cache hit rate per device.
  3. Cart and checkout gaps are very small because these pages are uncached (session-specific) on both devices; the structural CDN-cache difference disappears.
  4. The cumulative TTFB gap is mostly accepted as structural. Closing it from 460ms to 200ms requires aggressive mobile-edge-caching work that most CDNs handle automatically; further closing requires mobile-specific edge configurations rarely justified.
  5. The headline takeaway: mobile TTFB optimisation work is the same as overall TTFB optimisation work (CDN cache hit rate, origin response time). No mobile-specific TTFB fixes beyond ensuring CDN edge POPs are well-distributed near mobile user geographies.
The diagnostic flow:
  1. Confirm gap is in typical band. 200-500ms is acceptable.
  2. For concerning gaps, check CDN cache hit rate per device.
  3. Apply general TTFB fixes (cache configuration, origin optimisation), these benefit both devices.
Rapid-response playbook:
Time horizonAction
First 1 hourConfirm gap classification.
First 24 hoursIf concerning, investigate CDN cache hit rate per device.
Day 28Field TTFB per device reflects any infrastructure changes.

Sibling cards merchants should reference together

CardWhy merchants reach for it
psi_mobile_vs_desktop_scoreComposite score gap.
psi_mobile_desktop_lcpLCP gap.
psi_mobile_desktop_inpINP gap.
psi_mobile_desktop_clsCLS gap.
crux_ttfb_p75Field TTFB.
psi_server_responseLab TTFB.
psi_caching_opportunitiesCDN caching, the primary TTFB lever.

Reconciling against the vendor’s own dashboard

Where to look:
  • CDN dashboard, origin response time + cache hit rate per device.
  • CrUX BigQuery, TTFB per device.
Why the Vortex IQ TTFB gap may differ from CDN dashboard:
ReasonDirectionWhat to do
TTFB definition. CrUX includes DNS + TCP + TLS + server time; CDN dashboards measure server-only.CrUX higherUse CrUX for user-perception decisions.
Window timing.Vortex IQ lagsWait for refresh.
Cross-connector reconciliation: primarily internal (with crux_ttfb_p75, psi_caching_opportunities). Quick rule for support tickets: TTFB gaps under 500ms are structural mobile-network differences. Larger gaps suggest CDN cache hit rate or routing issues per device.

Known limitations / merchant FAQs

Why is mobile TTFB structurally slower? Mobile networks have higher latency (50-150ms) than fixed broadband. Even the same edge POP serving the same content responds slower to mobile clients. Most of the gap is structural and not directly fixable. Should I optimise mobile TTFB separately from desktop TTFB? No, generally. CDN caching and origin response improvements help both devices simultaneously. No mobile-specific TTFB fixes beyond ensuring CDN edge POPs are well-distributed near mobile user geographies. My mobile TTFB is 1,000ms higher than desktop. Is something broken? Possible. Investigate: (a) CDN cache hit rate per device in CDN dashboard; (b) whether mobile users hit different edge POPs than desktop; (c) whether origin has mobile-specific routing or response logic. Will HTTP/3 help mobile TTFB? Yes, modestly. HTTP/3 (QUIC) handles connection migration and packet loss better than HTTP/2, which benefits mobile users on lossy networks. Typical mobile TTFB improvement: 50-150ms.

Tracked live in Vortex IQ Nerve Centre

Server Speed: 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.