Why mobile shoppers leave before they buy

Almost every storefront is designed, reviewed and signed off on a fast desktop with a wired connection, in an office, by people who already know where everything is. The people who buy from it are outside, on a mid-range phone, on a congested network, with a dozen other apps competing for memory. Nothing about the first environment predicts the second. A hero image that appears instantly on a laptop takes four seconds over mobile data. A menu animation that feels crisp on a recent chip stutters on a budget processor from two years ago. This is not a design failure and the design may be excellent — it is a delivery failure. It stays invisible because everyone on the team checks the site the same comfortable way, and comfortable checking always agrees with itself.

Before spending anything, spend an afternoon reproducing the real conditions. Chrome DevTools can throttle both CPU and network so a desktop simulates a mid-range phone, and that alone tends to change what you believe about your own site. Better still, buy a cheap Android handset of the kind your customers actually own and make it the device the store is judged on. Then keep the two kinds of measurement separate: lab tools such as Lighthouse give you a repeatable score under fixed conditions, while field data from the Chrome User Experience Report — which the free speed check reports for any URL — shows what real visitors on real devices went through over the past month. Lab tools explain why something is slow. Field data tells you whether it is hurting anyone. If you want a second reading on your own numbers, a free speed audit runs the same exercise across your templates.

• Throttle CPU and network before trusting any impression
• Keep one cheap Android phone as the device that decides
• Read field data for what happened, lab scores for why
• Test the pages that carry revenue, not the homepage

Core Web Vitals sound like an acronym problem and are really three plain questions. Does the main thing on the screen show up quickly — Google's published threshold is 2.5 seconds for the largest element to appear. Does the page answer when you touch it — the responsiveness metric asks for interactions handled within 200 milliseconds, roughly the point where a tap stops feeling connected to the finger. And does the layout stay still, or do things jump as late content lands. That third question is the most infuriating on a phone, because the thumb is already travelling toward a target when the target moves. Those thresholds come from Google's Core Web Vitals guidance and are scored on real mobile visits, not on your laptop. The engineering behind each of the three deserves its own read; for deciding whether you have a problem, the framing is enough: loads, responds, holds still.

The specific offenders repeat from store to store. Images exported at desktop resolution and shipped to a 390-pixel screen, so one category page pulls several megabytes over mobile data. Layout that shifts because images and promo slots have no reserved height, or because a consent banner appears after the first paint and pushes everything down. Tap targets built for a mouse pointer — Google's mobile usability guidance points at roughly 48 pixels as a comfortable minimum, and plenty of theme buttons and filter checkboxes are half that. Sticky headers and floating chat bubbles that between them cover the add-to-cart button on a small screen. None of this surfaces in a design review; all of it surfaces on a phone. A good share is fixable inside the current theme, which is where speed optimization normally starts before anything bigger is discussed.

• Desktop-sized images sent to a 390-pixel screen
• No reserved space, so content jumps while loading
• Buttons and checkboxes smaller than a thumb
• Sticky bars and chat bubbles covering the buy action

Then there is the furniture added deliberately. A cookie wall that covers the screen and cannot be dismissed in one tap. A newsletter modal that opens before the visitor has seen a single product — Google has demoted intrusive mobile interstitials in search since 2017, so this one costs twice. An app install prompt on a page somebody reached from a search result. And filtering: a sidebar designed for a desktop column, squeezed into a drawer that reloads the whole page every time a box is ticked, on a catalogue where filtering is the only realistic way to find anything. On a small screen product filtering is not a secondary feature. For a large catalogue it is the product, and treating it as decoration is how a browsing session ends.

Desktop checkout is a form. Mobile checkout is typing an address with your thumbs while the on-screen keyboard hides half the fields. The small decisions settle it: input types that summon a numeric keypad for postcode and card number rather than a full keyboard, autocomplete attributes so the browser can fill name, address and payment details from what it already holds, labels that stay readable when a field is focused, and validation errors shown next to the field instead of at the top of a page that has already scrolled away. Baymard Institute's long-running checkout usability research keeps finding the same category of defect across large stores — not exotic bugs, but ordinary form handling nobody tested with a thumb. Each fix is cheap, and each one removes a reason to abandon.

When the fix outgrows the theme, the useful thing to understand is how little of the business moves. WooCommerce keeps running the store: products and variations, stock, prices, coupons, tax and shipping rules, orders, refunds, and the plugins your operations depend on. Your team logs into the same WordPress admin and does the same job in the same place. What gets rebuilt is only the layer a shopper touches — category, product, cart and the path into checkout — as a Next.js storefront that reads from WooCommerce and renders quickly on a weak device. Checkout itself can stay native, so payment and tax plugins behave exactly as they do today. The technical version of this page goes deeper into how that split works, and engagement sizes are on pricing.

• Stays: catalogue, stock, orders, coupons, refunds
• Stays: payment, tax and shipping plugins, and the admin
• Changes: how category, product and cart render on a phone
• Changes: what downloads, and when the page becomes usable

If phone traffic already converts at a rate you are happy with, stop reading and put the budget into acquisition, margin or range instead. Plenty of stores show a lower conversion rate on phones for reasons that have nothing to do with the frontend: a phone is a browsing device, people research on the sofa and buy later on a laptop, and cross-device attribution hides the connection. Confirm that before blaming the storefront. Then check the cheap causes: one oversized hero image, one heavy plugin loading on every page, a popup somebody added for a campaign and forgot to remove. If a week of unglamorous cleanup recovers most of the gap, take the win and walk away. Hiring anyone is justified only once the cleanup is done and the phone experience is still measurably worse.