A performance budget is a set of limits the team agrees not to exceed. It stops performance from slowly getting worse as features are added.
Types of budget:
- Quantity-based: for example, at most 170 KB of compressed JavaScript on the critical path, or at most a certain number of requests.
- Timing-based: for example, LCP (when the largest content appears) under 2.5 s on a mid-range phone on a 4G profile.
- Score-based: for example, a minimum Lighthouse performance score.
How to enforce it:
- Check bundle sizes in CI (the automated build), and fail the build when a limit is exceeded.
- Run Lighthouse CI on key pages for every pull request.
- Watch field data from RUM (real user monitoring) for regressions after release.
When a feature would break the budget, the team must choose. It can optimise something else, find a lighter approach, or decide openly to raise the budget.
- A performance budget is a set of agreed limits that stops slow regressions.
- Budgets can be based on quantity, timing or score.
- Enforce budgets in CI with bundle size checks and Lighthouse CI.
- Monitor field data after release.
- Breaking the budget forces the team to make a trade-off decision.
Read more
- Web performance (MDN) (https://developer.mozilla.org/en-US/docs/Web/Performance)developer.mozilla.org
- Lighthouse overview (Chrome) (https://developer.chrome.com/docs/lighthouse/overview)developer.chrome.com