Definition
A performance budget is a set of agreed limits on metrics that affect site performance — page weight, load time, request count, Core Web Vitals — used as a hard constraint during design and development to prevent performance regression.
Performance budgets work like financial budgets: by setting an explicit ceiling and tracking against it, the team can't accidentally drift over time. Without a budget, performance degrades steadily — each feature adds 100KB here, 200KB there, and a year later the page is twice as heavy with no single decision to blame.
Useful performance budgets are specific and enforced in CI. 'The page should be fast' is not a budget. 'JS bundle under 200KB gzipped, LCP under 2.0s on 4G, no more than 60 requests' is a budget — and the CI pipeline can refuse to ship code that violates it.
Origin
Performance budgets as a formal discipline were popularised by Tim Kadlec and other web-performance practitioners in the mid-2010s. Tooling support (Lighthouse CI, bundle analysers) matured through the late 2010s and early 2020s.
How it works
- Establish a baseline from current performance.
- Set targets for: JS bundle size, CSS size, image weight, total requests, LCP, INP, CLS.
- Document the budget; get team sign-off.
- Enforce in CI — break the build if budget is exceeded.
- Review quarterly; tighten budgets as performance improves.
When to use it
Use when
- Before any major site or app rebuild.
- When performance has degraded over time.
- For any project where speed is a competitive moat.
Skip when
- For very small projects where performance isn't a meaningful concern.
- When the team won't actually enforce the budget — performative budgets are worse than none.
Key metrics
- % of pages within budget
- Budget adherence over time
- Performance regression catches in CI
- Real-world LCP/INP/CLS trends
Examples
- Our performance budget caught the developer who tried to ship a 1.4MB hero image. Three lines of YAML.
- We set a 200KB JS budget and got better at code-splitting overnight — necessity is invention.
- The budget gets reviewed every quarter. Tightening it has compounded into a noticeably faster product.
In practice at Makreate
Makreate website-development engagements include performance budgets as part of the project standard — codified in CI and enforced on every deploy. The budgets are tight (JS under 100KB for most pages, LCP under 2.0s on real-device conditions) and we don't ship code that breaks them. Clients who inherit our builds keep the budgets in place and have told us months later that they're catching regressions early without thinking about it.
Website Development →Common mistakes
- Setting a budget but not enforcing it in CI.
- Budgets too loose to be meaningful.
- Budgets too tight to be achievable without quality tradeoffs.
- Not tracking field data alongside lab data.
- Reviewing the budget too rarely — it gets stale.
Frequently asked
What metrics should I set a budget for?
At minimum: total page weight, JS bundle size, LCP, INP, CLS. Add CSS size, image weight, and request count for more granular control.
How do I enforce a performance budget?
Lighthouse CI, bundlesize, webpack-bundle-analyzer, and similar tools integrate with most CI/CD pipelines. They fail the build if budgets are exceeded.
What if a feature legitimately needs more weight?
Raise the budget consciously and document why. Or remove other weight to make room. The point isn't never to spend; it's never to spend without realising.