Most performance testing happens on a fast office connection, on a recent laptop, against a lab throttling profile that approximates “average mobile.” None of that is what a client’s actual customer is using in Kabul, Kampala, or most of the markets we build for. We test differently because the gap between lab-average and street-real is where most launches quietly fail.
What the network actually looks like
Real Afghan mobile-carrier conditions run around 1.6 Mbps with roughly 300ms round-trip time. That’s not a worst case, that’s a normal Tuesday. A site that scores well against an unthrottled desktop test, or even a generic “Fast 3G” lab preset, can still load unacceptably slowly on the actual network its actual users are on. The only way to know is to test against that network specifically, not a proxy for it.
Where the time actually goes
On a constrained connection, round-trip latency dominates before bandwidth does. Every additional request, a font, a tracking script, a third-party widget, costs a full round trip at 300ms before a single byte of that resource even starts downloading. A page making forty requests isn’t forty times slower than one making one request, it’s worse than that, because those round trips often can’t run in parallel past a certain point.
This is why our build process leans so hard on things that sound almost too basic to mention: self-hosted fonts instead of a third-party font CDN, images converted to AVIF or WebP and lazy-loaded below the fold, critical CSS inlined so the first paint doesn’t wait on a stylesheet request, and a hard cap on third-party scripts. None of these individually is dramatic. Together, on a 1.6 Mbps connection, they’re the difference between a page that feels instant and one that feels broken.
Testing on the network that matters
We run Lighthouse CI against a throttled profile approximating those real Kabul conditions on every deploy, and a build that scores below our target under that throttle doesn’t merge. That catches most regressions before they ship. It doesn’t catch everything a lab can’t simulate, so we also test manually on real devices, on the actual network, before a site goes live, and again in production shortly after launch.
A PageSpeed score from a data center in another country is a useful proxy. It is not the same claim as “this works for the person it’s actually built for.” We’d rather make the second claim, because it’s the one that’s actually true where it counts.