Mobile conversion: the gap between your traffic and your revenue

Every store we audit has the same chart and the same reaction to it. Mobile is the majority of sessions — Shopify’s own performance documentation notes that mobile devices account for the majority of Shopify storefront traffic — and the conversion rate beside it is the lower of the two. The instinct is to conclude the mobile experience is broken. Sometimes it is. Often a large share of the gap was never a usability problem at all.

Cross-device journeys. Somebody finds you on a phone during the commute, thinks about it, and buys on a laptop at lunchtime. Unless they were logged in on both, that is two sessions on two devices with one order, and analytics assigns the whole credit to the laptop. The phone session is recorded as a non-converting mobile visit. For considered purchases — furniture, anything over a couple of hundred pounds, anything requiring measurements — this is not a rounding error.

Traffic mix. Paid social, influencer links and organic discovery arrive overwhelmingly on mobile, and they arrive earlier in the decision. Branded search and email arrive with intent, and email in particular is often opened on a phone but acted on later. If your mobile traffic is structurally further from a purchase than your desktop traffic, comparing the two conversion rates measures your channel mix, not your store.

In-app browsers. A tap from Instagram or TikTok opens inside that app’s own browser, which behaves differently from Safari or Chrome — different storage rules, different handling of some payment flows, occasionally different script behaviour. Sessions that begin there can look broken in ways that have nothing to do with your theme.

None of this is an argument for complacency. It is an argument for segmenting. Compare mobile and desktop *within the same channel*, ideally within the same campaign, and the residual difference is the one your theme is responsible for. That number is usually smaller than the headline gap and far more actionable, because you can actually go and find its causes.

Speed is the most over-claimed and under-measured lever in ecommerce, so it is worth being precise about what the targets are. The Core Web Vitals thresholds for “good” are 2.5 seconds or less for Largest Contentful Paint, 200 milliseconds or less for Interaction to Next Paint and 0.1 or less for Cumulative Layout Shift. Critically, those are assessed at the 75th percentile of page loads, segmented across mobile and desktop — which is to say they are explicitly a measure of your worse sessions, not your median one.

That percentile is the reason your internal testing disagrees with your field data. The lab test on a fast device is somewhere near your best case. The 75th percentile is the customer on a three-year-old handset on a train.

Shopify publishes a floor rather than a target: a theme must have a minimum average Lighthouse performance score of 60 across the home page, product page and collection page to be listed in the Theme Store. Read that as the entry requirement it is. Your live store carries apps, pixels and merchandising the demo store did not, and starting from a fast theme is not the same as staying fast.

Shopify’s own theme performance guidance is unusually direct about where the cost goes: audit all scripts, including apps, tracking pixels and theme code, and remove anything that is not earning its performance cost. In practice that one sentence is most of the work. We routinely find four analytics tools where one is used, two review apps where one was replaced but never uninstalled, and a personalisation script for a campaign that ended last year.

The specific technical points Shopify documents are worth applying literally, because they are the ones themes get wrong most often: never lazy-load the LCP image, load images visible in the initial viewport eagerly, apply fetchpriority="high" to the LCP image, always include width and height attributes on <img> tags — or use image_tag, which adds them automatically — and use defer and async on non-critical scripts, loading heavier JavaScript on user interaction via dynamic import(). Then, as Shopify puts it, test with realistic throttling and representative devices.

By the time someone reaches checkout on a phone they have already done the hard part, so the return on removing friction here is disproportionate. The single biggest lever is that express wallets skip address and card entry entirely — typing a card number on a phone is the slowest thing you will ever ask a customer to do, and the wallet already knows the answer. That is worth doing on its own merits, and worth being sceptical about when a vendor quotes you an uplift figure for it.

Beyond that, the mobile-specific checks are small: make sure address autofill works rather than being defeated by custom field names, make sure the discount code field does not send people off to a browser tab hunting for a code they were never going to find, and make sure error messages appear where the customer is looking rather than at the top of a scrolled page.

Pick the segment first. One channel, one device class, one page type. Then measure the step, not the sale: if you changed the variant picker, the number that should move is the add-to-cart rate on that page from that traffic, and it should move before revenue does. Revenue is too noisy at most stores’ volumes to attribute a product-page change to within any sensible timeframe.

Watch field data rather than lab scores for performance work. A Lighthouse run is a diagnostic, not a result; the 75th-percentile field numbers are what Google is assessing and what your customers experienced. And record what else changed that month, because a promotion, a channel-mix shift or a seasonal swing will happily take credit for your work, or take the blame for it.

If you want an honest before-and-after, the cheapest instrument is still watching recordings of ten mobile sessions on the page you are about to change. It is not statistically valid and it will tell you more in twenty minutes than a fortnight of dashboards.

A separate mobile site. It doubles the maintenance, splits the analytics, and solves a problem responsive layout solved years ago.

A redesign as the first move. Most mobile gaps we measure are a handful of specific defects in an otherwise reasonable theme, and a redesign replaces the defects you have identified with a new set you have not.

And any optimisation tool that works by injecting JavaScript into a page you are trying to make faster. Client-side testing and personalisation platforms are not free, they cost most on exactly the slow devices where your conversion problem lives, and the flicker they introduce is visible to the customer. If the whole programme is one or two decisions, make them properly and skip the tooling.

• Shopify conversion rate optimisation
• Shop Pay, express checkout and the conversion you are leaving
• Image delivery: formats, sizing and the CDN you already have