The Performance Inequality Gap
As long as we continue to build only for wealthy users, the dream of a web for everyone will continue to recede before our eyes, leaving a once vibrant ecosystem a ghost-town. Creating a better web starts with respecting the limits of the hardware and networks that most of the world's users carry. This is a deep dive into those constraints, their progression, and what they mean for web developers and the tool vendors that support them.
TL;DR?
What we're doing now isn't working. Not by a long shot.
The Performance Inequality Gap, 2024
How much HTML, CSS, and JavaScript can we afford? More than in years past, but much less than frontend developers are burdening users with.
The Performance Inequality Gap, 2023
To serve users at the global P75 of devices and networks, we can now afford ~150KiB of HTML/CSS/fonts and ~300-350KiB of JavaScript (gzipped). This is a slight upgrade on last year's budgets, thanks to device and network improvements. Meanwhile, web developers continue to send more script than is reasonable for 80+% of the world's users, widening the gap between the haves and the have-nots. This is an ethical crisis for frontend. Meanwhile, the most popular tools and frameworks remain in stubborn denial, but reality is not moved by ignoring it: when digital is the default, slow is exclusionary.
A Management Maturity Model for Performance
Despite advances in browser tooling, automated evaluation, lab tools, guidance, and runtimes, modern teams struggle to deliver even decent performance with today's popular frameworks. This is not a technical problem per se. It's a management issue, and one that teams can conquer with the right frame of mind and support.
Towards a Unified Theory of Web Performance
Is there a generic, unform way to think about web performance? What is web performance? What's it for? A humble attempt to answer those very deep questions. [republished]
The Mobile Performance Inequality Gap, 2021
A lot has changed since 2017 we I last estimated a global baseline for total page resource limits of 120-170KiB. Thanks to progress in networks and browsers (but not devices), the new baseline is much more generous: ~100KiB of HTML/CSS/fonts and ~300-350KiB of JS. But the devil's in the footnotes, and modern web development practices push the median page well above these guidelines.
The "Developer Experience" Bait-and-Switch
We cannot continue to use as much JavaScript as is now normal and expect the web to flourish. At the same time, most developers experience no constraint on their use of JS...until it's too late. Lightweight, effective tools are here, but we're stuck in a rhetorical rut. We need to reset our conversation about 'developer experience' to factor in the asymmetric cost of JS.
Can You Afford It?: Real-world Web Performance Budgets
Performance budgets are an essential but under-appreciated part of product success and team health. Most partners we work with are not aware of the real-world operating environment and make inappropriate technology choices as a result. We set a time budget of less than 5 seconds first-load Time-to-Interactive and less than two seconds for subsequent loads. We further constrain ourselves to a baseline device and network configuration to measure progress. 2017's global baseline is a ~$200 Android device on a 400Kbps link with a 400ms round-trip-time ('RTT'). This translates to ~130-170KB of critical-path resources, depending on composition; the more JS you include, the smaller the bundle must be.