Nobody Designs for 2G. Here's What Building in Kenya Taught Me About "Fast" Websites
Most performance advice online assumes a baseline that doesn't exist for most of the world. Fast wifi, a recent phone, a stable connection. Lighthouse scores optimized for conditions half the planet doesn't have. I build web products for businesses in Kenya. A meaningful share of my users are on 3G, sometimes 2G, often on a budget Android phone with limited storage and a browser that hasn't seen an update in a year. Here's what that actually changes about how you build.
Your bundle size is a business decision, not a dev preference
A 2MB JS bundle that loads instantly on your MacBook can take 15 to 20 seconds on a real 3G connection. That's not a slow load, that's a user who left before your app finished parsing. I've watched analytics confirm this directly, drop-off spikes exactly where bundle size peaks.
Skeleton screens matter more than animations
Every extra animated transition is more work for a weak CPU to render. I stripped most micro-interactions out of a recent build and page-perceived speed improved more than any code-splitting change I made that month. Motion is a luxury feature for people with headroom to spare.
Offline isn't an edge case, it's Tuesday
Connections drop mid-session constantly, not from bad code, just from the actual infrastructure. If your app throws away form state on a dropped connection, you're actively costing your users. Basic local persistence before submission became a non-negotiable for me after watching real users lose an entire booking form to a 4 second network blip.
Images are still the biggest offender in 2026
Everyone optimized images years ago and moved on. They didn't. I still regularly find production sites shipping unoptimized hero images at 3 to 4MB. On a fast connection that's invisible. On the connections a huge share of the world actually uses, that single image can be the whole page load.
The real point
"Fast" isn't a Lighthouse score. It's whether the app actually works for the person holding the phone it's meant for. A lot of what gets called premature optimization in tutorials is just basic respect for users outside wealthy, high bandwidth markets, which is most of the world's internet users, not a minority case.
What's the worst assumption you've seen baked into "best practice" web performance advice that falls apart the moment you leave ideal network conditions?
Comments
No comments yet. Start the discussion.