Checkout on a Mid-Range Android: The Device Your Averages Hide
Your checkout timing report says the page is fine. It says that because it is an average, and averages hide the device doing the suffering. The median shopper in most stores is not on a flagship phone on office wifi. They are on a two or three year old Android with a mid-range chip, on a connection that varies street by street. That device parses JavaScript several times slower than the phone your developers test on, and checkout is the most script-heavy page you own. The page your report calls fast and the page that shopper waits for are not the same page.
The gap shows up as behaviour, not errors. Nothing crashes. The payment fields just take long enough to feel broken, the page shifts as late elements land, an address lookup resolves after the shopper has started typing over it. Each delay is short. Stacked across a four step checkout they read as a store that does not quite work, and the shopper leaves quietly, which is why the device split matters more than the site average.
Find your real median device before you measure
Pull the device breakdown for checkout sessions, not for the whole site. Marketing traffic and checkout traffic have different mixes, and the people who reach checkout skew to whatever device your buyers actually own. Note the most common Android model family and the browser share, then get hold of that class of hardware or throttle a desktop browser to its CPU level, which most dev tools can do with a multiplier. Test on that profile, cold cache, over a throttled connection that drops and recovers, because that is the session your average is made of.
Time three things separately: how long until the first checkout field can be typed in, how long until the payment section is usable, and whether anything moves after the shopper starts entering details. The first two are speed. The third is trust. A page that shifts while someone types a card number does damage no timing graph shows, because the shopper's conclusion is not that the page is slow. It is that the page is unsafe.
What usually makes checkout heavy on cheap hardware
It is rarely the platform core. It is the accumulation around it: app embeds that load their full libraries to render one widget, tag containers carrying pixels for campaigns that ended last year, consent tooling, review badges, protection toggles, address services, each individually small and collectively the difference between a second and five seconds of main thread work on a mid-range chip. Desktop testing forgives all of it. A flagship phone forgives most of it. The median device forgives none of it, and it is the one paying you.
Audit by subtraction. Disable the non-essential embeds on a staging checkout and re-time the three checkpoints. Add them back one at a time and note which ones cost real time on the throttled profile rather than in theory. Most stores find one or two offenders doing most of the damage and a long tail that is genuinely cheap. Fix the offenders, keep the tail, and re-run the test after every app install, because the install is the moment the weight arrives and nobody re-measures a checkout that still loads fine on the office phone.
Report the split, not the average
Change the standing report. Checkout timing and completion rate, split by device class, reviewed on the same cadence as revenue. When the mid-range Android line moves, someone should be able to say which change moved it. Averages will keep telling you the page is fine while the shoppers with the least patience for failure, and often the least money to waste on a bad experience, quietly take the lesson your report averaged away.
Related reading: Make the Phone Field Optional Unless Delivery Actually Needs It, Make the Phone Field Optional Unless Delivery Actually Needs It, Postcode Lookup at Checkout: Fast When It Works, Brutal When It Does Not.
Frequently asked questions
Why does my checkout test fast but still lose mobile shoppers?
Because the test device is not the median device. A mid-range Android parses checkout JavaScript several times slower than a flagship, and delays stack across steps. Nothing errors, it just feels broken, so shoppers leave without a trace in your error logs.
How do I test checkout the way real shoppers experience it?
Take the most common device class from your checkout sessions, throttle CPU and network to match it in dev tools, use a cold cache, and time when fields become usable rather than when the page technically loads.
What makes checkout slow on cheaper phones?
Accumulated embeds: app widgets loading full libraries, stale marketing pixels, consent and badge scripts, address services. Each is small alone. Together they are seconds of main thread work on a mid-range chip.
What should a checkout performance report show?
Timing and completion split by device class, not a single site average. The split is where a regression from a new app install shows up. The average hides it until the revenue line moves.