6 Turn performance goals into budgets
This chapter covers
- Translating goals into enforceable budget thresholds
- Setting budgets for memory, bundle size, response time, and startup
- Choosing thresholds and granularity that fit your team and product
- Establishing governance: who owns budgets, how exceptions are handled, and how teams coordinate
- Using constraints to drive creative solutions rather than block progress
Performance goals tell you what to aim for; performance budgets make sure you do not slip back along the way. A goal like "page loads in under 3s" gives your team direction, but it does not prevent someone from adding a feature that pushes load time to 3.5s. That requires a budget: a threshold derived from your goal, set tight enough to catch problems before users notice them.
The translation from goal to budget is not one-to-one. Goals describe what users should experience; budgets describe what code changes are allowed. If your goal is a 3s page load, your budget might cap the initial JavaScript bundle at 300KB compressed, because that is what your architecture can deliver within 3s on the devices your users actually have. The budget gives the goal a number that a CI pipeline can measure, and a pull request can check against.