Ask around any web team and you’ll find the same mobile testing setup: a developer on a MacBook, Chrome’s device toolbar open, office Wi-Fi humming along in the background. It catches layout bugs fine. Everything else slips past.

Because the people actually buying stuff aren’t on office Wi-Fi. They’re on a bus, in a supermarket queue, or stuck on one bar of 4G at a festival, and that’s where a page that “loads fast” can quietly take eight seconds.

Office Wi-Fi tells you very little

Phone connections are all over the place. Towers hand off, cells fill up at 5 pm, latency goes from 30 ms to well over 120 ms, and a 2 MB product page that flew at 100 Mbps starts crawling at 8 with the hero image half loaded.

Then there’s the IP address, which gets ignored way too often. CDNs, bot filters and geo rules look at carrier IPs differently than home or office ones, so somebody in Lyon on Orange can get a different price or a surprise CAPTCHA that your QA person has literally never seen during testing.

A VPN doesn’t help much here (VPN exits live in datacenters, and lots of sites block them anyway). If you want the real view, get mobile proxies and run your test sessions through live 4G and 5G connections in the countries you actually sell in.

Expect a few surprises in the first week. Usually it’s something dumb, like a consent banner that only breaks for French phones, or a fraud rule that’s been turning away real orders since the last deploy.

Throttling is fine, just don’t stop there

Start with simulation anyway, since it costs nothing. Chrome DevTools lets you make custom throttling profiles with whatever download speed, upload speed, latency and packet loss you want, and you can calibrate CPU throttling to cheap and mid-range phones too.

The problem is it’s too polite. Every request gets the exact same delay, but real 4G cuts out for a second and then dumps everything at once (which is precisely what breaks lazy-loaded images and flaky checkout scripts).

BrowserStack, Sauce Labs and AWS Device Farm give you real Pixels and Galaxies to poke at. Good for hardware bugs, honestly. Most of those phones sit on datacenter internet though, so the network side is still missing.

Mobile Networks

Shared carrier IPs make for weird bugs

Carriers don’t give every phone its own public IP. They use carrier-grade NAT, which crams a bunch of subscribers behind a small pool of addresses because IPv4 ran out years ago.

So your WAF blocks one sketchy IP and, oops, a few hundred real customers on the same address go with it. That’s the story behind a lot of “mobile sales in Spain tanked and nobody knows why” Slack threads.

Testing from carrier IPs finds this stuff before support does. It’s also the quickest way to check localised pricing and language redirects actually work on phones.

Making it a habit

Don’t guess which countries to test. Open Google Analytics 4, sort mobile revenue by country, and take the top three to five; there’s no point testing Chile if almost all your orders come from Germany and Poland.

Then script the flows that make money (home, search, cart, checkout) in Playwright or Puppeteer and run them over mobile connections on a schedule. Hook up Lighthouse CI to log Core Web Vitals while you’re at it, and aim for LCP under 2.5 s, INP under 200 ms and CLS under 0.1.

Weekly is enough for most sites. Before Black Friday, go daily, because someone in marketing will add a tag on a Friday and mobile load times will be two seconds slower by Monday.

Once a month, check your lab numbers against real-user data in the Chrome UX Report. If they don’t match, your setup still isn’t realistic enough, and it’s worth figuring out why.

Where it’s heading

5G standalone and network slicing are going to make things patchier, not smoother, since carriers can now prioritise some traffic over the rest. Your site might fly in central Berlin and still drag on rural 4G an hour outside town.

Teams that test on real networks every week will notice that long before teams who only check at launch. And since 53% of mobile visits get abandoned when a page takes over three seconds to load, noticing early pays off.