Performance budget
A performance budget is a set of enforced limits on metrics that affect site speed — the mechanism that turns “ship fewer bytes” into a gate the build can fail. It is the practical hinge of this wiki’s domain (“front-end byte budgets”): page-weight and bundle-size are what you measure; the budget is the line you refuse to cross.
Three kinds (performance-budgets-101)
- Quantity-based — total page weight, request count, JS bundle size, max image/font size, number of third-party-resources. Simple, byte-oriented; but doesn’t capture when resources load.
- Milestone timings — FCP, Time to Interactive, and similar.
- Rule-based scores — e.g. a Lighthouse performance score floor.
Default targets
web.dev’s baseline (real device, 3G): < 5 s to interactive and < 170 KB compressed critical-path resources. That 170 KB sits between landing-page-14kb‘s 14 KB first-RTT rule and the 2,652 KB median (page-weight) — a pragmatic middle, scoped to the critical path rather than the first packet.
Enforcement
A budget only works if exceeding it breaks CI: Lighthouse CI, the bundlesize library, Webpack performance hints. Over budget → optimize, remove, or block the addition.
Place in the wiki
The budget is the active counterpart to the wiki’s descriptive concepts: it operates on page-weight/bundle-size, constrains third-party-resources, and aims at good core-web-vitals. See synthesis — minimalism becomes a discipline (a budget), not just a one-off feat (the 14 KB page).