Mobile conversion is 40% below desktop. Product blames the design; analytics shows users leaving before the page is usable. How do you investigate?

Get field data before touching anything

A laboratory run on a developer machine measures one configuration, usually the fastest one anyone uses. Real traffic includes older devices, congested networks and cold caches, and the field distribution has a long tail — the 75^th percentile is frequently several times the laboratory figure.

Segment it: device class, connection type, geography, and new versus returning visitor. The answer is normally concentrated in one segment rather than spread evenly, which changes what is worth fixing.

The three likely findings

A time-to-interactive gap. Server-rendered markup appears quickly, JavaScript has not finished executing, and taps do nothing. Users tap again, then leave. This is the worst variant because the interface actively invites interaction it cannot service, and it is worst on exactly the mid-range devices where the conversion gap shows.

Layout shift. Something arrives late with no space reserved — an image without dimensions, a consent banner above the content, a personalised region — and the user reaching for a button taps something else. Field data catches this where a fast laboratory connection does not.

Payload weight. A bundle sized for a laptop takes many seconds to download and parse on a mid-range phone over a congested connection.

Fixes, in order of return

Reduce the bundle: split by route, remove or defer third-party scripts, and audit what each dependency is actually for. Reserve space for everything that arrives asynchronously. Consider partial hydration so behaviour attaches to interactive regions rather than the whole page, which is the structural fix for the gap rather than a mitigation.

Then prevent the recurrence

A performance budget enforced in the build, measured as compressed transfer size and as a timing metric on a throttled reference configuration. Front-end performance degrades by accretion — no single change is responsible — so without a per-change signal you are back here in six months with no commit to point at.

Give it a documented override path, or it will be deleted the first time it blocks a launch.

What to tell product

The design may also be a factor and it is not the first thing to change. Fix the measurable performance problem, re-measure conversion by segment, and then discuss design with a clean signal.