The mobile performance gap.
The same page runs markedly slower on mobile devices than on desktop, and the reason is not the network but processor power.
Performance testing mostly happens on the developer’s own machine, and that machine sits at the best end of real users’ device distribution. The result is a systematically optimistic picture and a lab score that keeps diverging from the field data.
The gap shows most in JavaScript. A script’s download time depends on the network, and mobile networks are sometimes faster than desktop ones; but that script’s parse, compile and execution time depends on the processor — and a mid-range phone trails a laptop by multiples.
Same bytes, different cost
This asymmetry also explains why byte-based budgets are not enough. A hundred-kilobyte image carries roughly the same cost on every device — it downloads and decodes. A hundred-kilobyte script produces costs that differ by multiples between devices.
The practical consequence: mobile performance work should focus on JavaScript, not images. Shrinking images yields similar gains on every device; shrinking scripts yields disproportionate gains on weak devices.
The second consequence concerns the test device: testing on the newest phone differs little from testing on the newest laptop. A meaningful test happens on a mid- or low-segment device — or is simulated with the CPU throttling setting in the browser tools.
- Four-times throttling — a simulation close to a mid-segment device.
- Six-times throttling — a low-segment device. Google’s own mobile test sits around here.
- Network throttling is separate — to be used together with CPU throttling; the two catch different things.
- A real device — the simulation does not replace it; test at least once on a real phone.
- Field data — the final referee. A simulation is an estimate; field data is a measurement.
Viewport and layout
There is a second mobile difference, and it gets missed: the same content produces a much longer page on a narrow screen. That changes the number of elements in the viewport — and can therefore change which element is the LCP element.
Where the hero image is the LCP element on desktop, on mobile it can be a heading text. The two demand entirely different treatments — one image optimization, the other font loading behavior. The LCP element must therefore be identified separately per breakpoint.
The same split applies to touch targets and layout shift: a grid narrowing at the mobile breakpoint can push targets that are fine on desktop below the threshold, and late-arriving content produces a larger shift on a narrow screen.
On this site the verification suite measures the mobile breakpoint as a separate block: at 390 pixels wide, the page flow, touch targets, text clipping and article page measures are audited one by one. The assumption that the desktop measurement covers mobile is never made.
Nothing measured on desktop says anything about mobile; the two are measured separately.
Network variability
The processor gap is the largest factor but not the only one; the variability of mobile networks is a design constraint too. Unlike a fixed line, a mobile connection changes speed and latency as the user moves — and at some moments cuts out entirely.
That demands resilience. A failed request is not an exception but an expected state, and what the interface does then must be designed. A form failing silently loses the user’s data.
On this site the contact form is built on that principle: if the server does not respond, the flow hands over to an e-mail link. The channel never fully closes, and the verification suite measures that fallback behavior separately.
- A slow connection — content should arrive progressively; show a skeleton, not a blank screen.
- An intermittent connection — when a request fails, the user must be told what happened.
- A metered data plan — with the data saver preference reported, heavy resources should not load.
- High latency — the request count should drop; every round trip is expensive.
- A fallback path — critical flows must not depend on a single technology.
The last item is an architectural principle reaching beyond mobile: a flow that is the single conversion path must not depend on one technology working. That is as much reliability as performance — and here the two point to the same solution.
A practical checklist
Turning this page into an audit step, here is what to check for mobile performance. The list is kept short because long lists do not get walked; six items fit in one sitting.
- Was the test run with a throttled CPU?
- Was it tried at least once on a real mid-segment device?
- Is the LCP element different on mobile — it must be identified separately from desktop.
- Are the touch targets above the threshold at the mobile breakpoint?
- What does the interface do on a network cut?
- Was the field data read separately for mobile and desktop?
The third item is the most overlooked: where the hero image is the LCP element on desktop, on mobile it can be a heading text — and the two demand entirely different treatments.
Nothing measured on desktop says anything about mobile.
A priority frame to close: on most sites more than half the traffic comes from mobile, and performance work is still done desktop-first. That inverted priority means the problems affecting the most users get handled last.
The fix is a change of habit: start measuring from mobile, pick a mid-segment test device, and read the field data at the mobile breakpoint. None of the three adds cost — they only change which number gets looked at first. And on this site the suite measures the mobile breakpoint as a separate block; the assumption that the desktop measurement covers mobile is never made.
A measurement reminder to close: mobile field data usually comes out markedly worse than desktop, and that is normal. The problem is not seeing that gap and saying “there is much to improve on mobile” — the problem is merging the two datasets, looking at the average, and never seeing the gap at all. Two numbers read separately give a diagnosis; one merged number gives only a feeling.