Performance is accessibility

AikaLabs · · 5 min read

In 2012 a YouTube engineer named Chris Zacharias rebuilt the video watch page to be as small as he could make it. The normal page was about 1.2 MB and pulled in dozens of requests. His version, which he called Feather, was 98 KB across fourteen requests. He shipped it as an experiment and watched the latency graphs, waiting for them to drop.

They went up.

For about a week the numbers made no sense. The page was a tenth of the size and the average load time had somehow gotten worse. Then someone looked at the geography. Feather had quietly opened YouTube to places that could never really load it before: parts of Southeast Asia, South America, Africa, Siberia. Those users were showing up in the data for the first time, and even on the featherweight page they were waiting two minutes. On the old page they would have waited more than twenty. "This meant that a regular video page, at over a megabyte, was taking more than TWENTY MINUTES to load," Zacharias wrote. The heavy page had not been slow for those people. It had been invisible.

That story is more than a decade old, and the web has spent the decade going the other way. The median mobile page is now around 2.6 MB, up from 845 KB in 2015. Most of the weight is images and JavaScript: roughly a megabyte of pictures and 700 KB of script on a typical page, before the reader has seen a single word. We have spent ten years raising the floor.

Who is standing on that floor

Here is the part that gets left out of most performance conversations. A large share of the world is not on the connection you tested with. Around 2.5 billion mobile connections were still 2G at the end of 2023. India alone has on the order of 700 million 2G users, and most rural mobile users there are on it. The cheapest feature phone costs about ten dollars; the cheapest smartphone, sixty. For a lot of people the choice is not which phone, it is whether.

Now do the arithmetic. A real 2G data connection moves somewhere between 20 and 50 kilobits per second on GPRS, maybe 150 to 200 on a good EDGE signal (the numbers are well documented). Take the median 2.6 MB page and push it through 50 kbps. That is about seven minutes of pure transfer, and transfer is the optimistic part of the estimate. It ignores latency, the round trips, the connections that stall and retry on a weak signal. The page Zacharias clocked at twenty minutes was 1.2 MB. The ones we ship now are twice that.

An accessibility problem that never files a complaint

We already have a word for the distance between what we build and what people can actually use. We call it accessibility, and most teams have learned to take it seriously: alt text, keyboard navigation, contrast ratios, labels a screen reader can announce. Weight belongs on that list. A page nobody can load is not accessible, however clean its markup is.

Performance is the accessibility failure that does not show up in the audit, because the people it shuts out never arrive to be counted. They are not in your analytics. They bounced before the first byte, or they never tried, because last time the page just spun. The absence is the symptom.

Alex Russell has spent years measuring this as the performance inequality gap. He sets his baseline at a cheap Android and the 75th percentile of devices and networks, which is to say a full quarter of the world is having a worse time than his test. Even at that line the budget is tight: a couple of megabytes total and only a few hundred kilobytes of JavaScript for a page that loads in three seconds. Most sites spend that on the framework before they write any of their own code. He does not soften the conclusion. "This is a technical and business challenge, but also an ethical crisis," he writes. The web "increasingly punishes the poor for their bad luck."

The slowest user sets the bar

None of this is a hard technical problem. We know how to make pages small. Ship less JavaScript, and treat every dependency as weight that someone on a metered plan pays for in real money. Send images in modern formats at the size they actually render. Defer what is below the fold. Measure on a cheap phone over a throttled connection instead of a laptop on office wifi, because the laptop will lie to you every time. None of it is exotic. The hard part is not knowing how. It is deciding that the slowest user is the one who sets the bar.

A performance budget is just a number you refuse to cross, the same way you refuse to ship a button you cannot reach with the keyboard. It only works if you are willing to say no to something you wanted, late, when the number says no. That is the whole discipline.

If you are building for people who are just coming online, on the first phone and the cheapest data and one bar of signal, weight is not a metric on a dashboard. It is the entire conversation. A page that loads in a second on a 2G connection is a harder thing to make than a beautiful one that loads in twenty. It is also the only version that exists for the person on the other end.

The fastest page is the one that is actually there.

References and further reading