Testing on the phone your customer actually owns

CPU throttling in a desktop browser is a multiplier. The engine still runs on your cores, with your cache, your memory bandwidth and your GPU, and the profiler inserts delay so the main thread looks slower. That is a fine instrument for confirming a long task you already suspect. It is not a phone.

The parts it leaves out are the parts that break sites. A phone has no fan. Run something heavy for 30 seconds and the chip drops its clocks to stay inside a thermal budget, so the second half of a long scroll is worse than the first.

Memory is the other omission. On a laptop with 32GB the browser can be careless and nobody notices. On a phone the tab competes with the camera, the mail client and whatever the OS kept warm, and loses.

iOS terminates a tab that grows past what the system will tolerate. Android discards background tabs under pressure. Neither event has a representation in device mode.

Network throttling applies a fixed bandwidth and round trip. Radio is variable by design. An idle cellular connection has to renegotiate with the tower before the first byte moves, so a request fired well after the page settles pays a startup cost the emulator never charges. Add jitter, packet loss, a handover between cells and a lift, and the waterfall stops matching yours.

Then there is the engine. Device mode runs the browser you have open, which was updated last week. On iOS, in practice, every browser renders with the system WebKit, and WebKit ships with the OS. Chrome on Android updates itself from the store, independent of the OS.

So the platforms go stale differently. An old Android usually runs a current engine on slow silicon. An iPhone past its final iOS release is frozen on both counts, and a layout feature you have had for 2 years can simply be absent.

The failure is silent by specification. CSS drops what it cannot parse, so an unsupported value takes its declaration with it and an unsupported selector takes the whole rule. The page renders a state you never designed.

Your phone is new, because you replaced it the moment it started annoying you. That is what makes it useless as a test device. Apple's long support window cuts both ways. Inside it, old hardware runs current WebKit on old silicon. Outside it, nothing moves at all.

The software state is just as far from yours. Picture a phone at 15% battery with low power mode on, which caps clocks and drops the refresh rate. Storage nearly full, so the cache is evicted and every repeat visit arrives cold.

Dozens of tabs open. An hour in a warm pocket. It is the ordinary condition of the machine your checkout runs on.

The reasonable objection is that you do not need hardware, you need field data. Your p75 by device class tells you how slow the site is for people who are not you. It answers a different question. Field data arrives as aggregates with no cause attached. It reports that the p75 got worse, never that a hover state is pinned open over the menu or that a form emptied itself.

Devices produce causes, field data produces frequencies. Buy a phone to find the failure, use the field data to decide whether it is worth fixing. The hardware half is embarrassingly cheap. A device lab for a small studio is a drawer, 2 handsets and 2 cables.

• An old iPhone, stuck on the oldest iOS you claim to support. It is there for the engine, not the chip. Bought used, no SIM needed.
• A mid-range Android from about 4 years ago, the sort of phone that sells in volume. Current Chrome on slow silicon, the opposite test.
• A cable for each, so you get Safari Web Inspector and chrome://inspect. Remote debugging gives a real console and a profile taken off real hardware.

Point them at deploy previews rather than a local tunnel, so testing on a phone is a URL you paste. Once a week, take one outside and load the site on cellular while walking. Do that for 10 minutes and you find things no throttling profile will surface. You are testing variance, and variance is what a fixed profile removes.

Some bugs are structurally invisible to emulation. The address bar collapses as you scroll, so the viewport height changes mid-gesture and a full-height hero sized in vh is taller than anyone can see. svh and lvh hold still. dvh tracks the toolbar, so anything sized in it reflows mid-scroll, which is sometimes worse than the bug it fixes.

Focus an input with a font size under 16px in Safari and the page zooms in, then stays zoomed. Tap a link with a hover style and the hover sticks, which is how a dropdown stays pinned open over the content.

Scroll-linked work is the worst offender. During a fling, iOS hands scrolling to the compositor, and anything sticky or driven by a scroll listener can fall out of step with the content. On a desktop trackpad the same animation is smooth at every throttling level.

Image decode behaves the same way. Say a hero delivered at 4000 by 3000. That is 12 megapixels, roughly 48MB of bitmap once decoded, whatever the compressed file weighed. Decode tracks pixels, not bytes, so a hero that passes a byte budget can still stall a phone near the memory ceiling.

Here is the one that costs money. A user fills in 3 fields, switches to their mail app for a verification code, and comes back 40 seconds later. The tab was discarded under memory pressure and reloaded from the network, so the form is empty. They do not report a bug, they leave, and your analytics record an abandoned checkout with no cause attached.

It lives in the gap between a throttled desktop and a phone, and reproducing it takes a minute. Half-fill the form, switch to Mail, open a few other apps, wait, come back. If the fields are blank, you found it before your customer did.