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 budget in <strong>time</strong> of <= 5 seconds first-load <a href='https://developers.google.com/web/tools/lighthouse/audits/time-to-interactive'>Time-to-Interactive</a> and <= 2s for subsequent loads. We constrain ourselves to a real-world baseline device + network configuration to measure progress. The default global baseline is a ~$200 Android device on a 400Kbps link with a 400ms round-trip-time ('RTT'). This translates into a budget of ~130-170KB of critical-path resources, depending on composition -- the more JS you include, the smaller the bundle must be.
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.
What we're doing now isn't working. Not by a long shot.
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.