Performance Budgets 101 (web.dev)
Google web.dev’s canonical primer on the performance-budget — the practice of turning “ship fewer bytes” from an aspiration into an enforced limit. This is the mechanism the wiki’s domain (“front-end byte budgets”) is named for but had no page on.
The three kinds of budget
- Quantity-based (resource limits) — total page weight, request count, max image size, JS bundle size, font count/size, number of third-party resources. Easy to set early; limitation: two equally-sized pages can perform differently depending on when critical resources load.
- Milestone timings — user-centric metrics like First Contentful Paint and Time to Interactive.
- Rule-based scores — e.g. a Lighthouse performance score threshold.
Default thresholds it recommends
Calculated against a real-world baseline device and 3G:
- < 5 s to interactive
- < 170 KB of critical-path resources (compressed)
That 170 KB critical-path figure is a useful contrast with landing-page-14kb‘s 14 KB rule: 14 KB is the first TCP round-trip (initial congestion window) for an instant first paint, while 170 KB is a whole critical-path budget to interactivity over 3G. Different scopes of the same “byte budget” idea — see synthesis.
Example budgets by page type
- Product page: < 170 KB JavaScript on mobile
- Search page: < 2 MB images on desktop
- Homepage: < 5 s load on 3G (Moto G4)
- Blog: Lighthouse performance score > 80
Enforcement
Budgets only bite if a build fails when they’re exceeded: Lighthouse CI, the bundlesize library, and Webpack’s performance hints. When over budget, teams optimize, remove, or block the new addition — making bundle-size a gated metric, not a hope.
Why this matters here
- Names and structures the wiki’s central practice; anchors the performance-budget concept.
- Connects the levers: page-weight and bundle-size are what you measure; the budget is the limit you enforce; core-web-vitals are the field outcome.