the network customers actually have

in metro india the median mobile connection is 4g or 5g. forty kilometres out of guwahati it is not. the assam tea garden manager checking your homestay listing on the way back from work is on a 2g cell tower, sometimes a 3g one if the weather is right. her phone is two or three years old, the battery is at twenty percent, and your site has half a second to look like it is working.

this is the customer base for a tea brand going direct, a tourism operator selling lodge stays, a healthcare clinic in a tier-three town. if the site works on the network they have, the business works on the customers it has.

what 2g design forces you to do

the constraints are simple and they hold. the homepage critical path fits in under 100 kilobytes. images are responsive and lazy. javascript bundles ship per route, not as one big file. fonts subset to the characters actually on the page. analytics and chat widgets load after the first paint, not before.

every one of these decisions makes the site faster on every connection. a homepage that lands in under a second on 2g lands in under 200 milliseconds on 5g. designing for the slowest network makes the fastest one faster too.

how we test it

chrome devtools has a throttling preset called 'slow 3g' that approximates 400 kbps with a 400 millisecond round-trip. we run every page on that preset, then on a real three-year-old android over a real cellular connection at least once, then through the lighthouse mobile audit on every commit.

the bar is the same every time: largest contentful paint under two seconds, total blocking time under 200 milliseconds, page interactive before the user has finished reading the headline. if a feature would push us past that bar, we either find a lighter way to ship it or we cut it.