Why Mobile Conversion Lags and How to Close the Gap

If you split your conversion rate by device, you’ll almost certainly find that mobile trails desktop, and the standard reaction is a shrug: mobile just converts worse, everyone knows that. The shrug bothers me, because it bundles together two very different things. Part of the gap is structural, baked into how people use phones, and you can’t fix it. But part of it is self-inflicted, a tax you’re paying through decisions someone on your team made, and the shrug lets the self-inflicted part hide behind the structural part. The useful work is prying them apart.

The structural part is real, so let’s grant it. People on phones are often in a different mode: earlier in their research, half-distracted, standing in line somewhere. A phone is where you discover things; a desktop is where you commit to them. Some purchases genuinely migrate — found on the phone at night, bought at the desk the next morning — and a per-device conversion number records that as a mobile failure and a desktop success when it was actually one person doing something sensible. Typing is worse on glass, high-stakes decisions feel better on big screens, and none of that is your fault. If this were the whole story, the shrug would be right.

But then try actually buying something from your own site on your own phone, with one thumb, in a hurry, and the self-inflicted part introduces itself immediately. The form that was mildly tedious on desktop is punishing on mobile, and worse, it’s often punishing in ways that are pure configuration. An email field that doesn’t declare itself as an email input gets the wrong keyboard, so the visitor hunts for the at-sign on the symbols layer. A numeric field that could have summoned the number pad didn’t. Autofill, which exists precisely to rescue mobile forms, gets defeated because nobody set the autocomplete hints that let the browser fill a name, address, and card in two taps. On desktop these are papercuts. On a phone they compound, and each one is a moment when the other tabs win.

Then there’s touch itself. A cursor is a precision instrument; a thumb is not. Links set close together, buttons that are visually large but have small tappable areas, controls parked near the screen edges where a thumb can’t comfortably reach — every mis-tap is friction, and worse, it makes the visitor feel clumsy, and people leave situations that make them feel clumsy. Accessibility guidance suggests touch targets of at least around 44 by 44 CSS pixels, and it’s a floor worth respecting for everyone, because on mobile every user is, in effect, motor-impaired relative to a mouse.

Speed deserves its own paragraph, because it’s the largest invisible tax. Your team tests the site on new phones over office wi-fi. Your visitors are on mid-range hardware over cellular connections that fluctuate. A page that ships megabytes of JavaScript and desktop-sized images doesn’t feel broken to you; it feels broken to them, and they don’t file a bug report, they just leave. This is why GazeSite captures a HAR file — a record of every network request the page makes — alongside its screenshots: page weight is invisible in a design review and glaring in the network log. The same scan renders every page in a mobile viewport, and the mobile screenshots regularly look like a different, worse product than the desktop ones: the hero image crowding out the headline, the call to action pushed below three screens of navigation, an overlay that can’t be dismissed with a thumb. Nobody decided the mobile experience should be worse. It’s just that everyone who built the page did so on a desktop, so desktop is what got seen.

That’s the real root cause, I think. Mobile conversion lags partly because mobile users differ, but largely because mobile is where sites are used most and inspected least. The gap between usage and inspection fills up with neglect. So the practical program is short. Measure the gap by device so you know its size. Fix the mechanical things first — input types, autocomplete, touch targets, page weight — because they’re cheap and nobody defends them once they’re pointed out. Then do the harder thing: make the primary action lighter on mobile, because asking a thumb on a train to do what a mouse at a desk would do is asking too much. Let the phone visitor start the thing — save the cart, send themselves the link, get the report by email — and let the commitment complete wherever they’re comfortable.

You won’t close the gap to zero, and you shouldn’t expect to; the structural part is real. But most teams have never separated the part they can’t fix from the part they haven’t looked at. The first is an excuse. The second is a to-do list, and it’s usually longer than the excuse suggests.