Performance optimisation without a budget is just guessing. Here's how to set meaningful limits and stick to them.
What's a Performance Budget?
A performance budget is a limit on metrics that affect user experience. Not a target—a ceiling you won't exceed.
Example: Main bundle under 200KB. Time to interactive under 3 seconds on 4G. No more than 50 requests on initial load.
Why Budgets Work
Budgets create accountability. "We need to keep the bundle under 200KB" is actionable. "We should improve performance" is not.
Budgets prevent regression. That new library looks nice—but does it fit the budget?
Budgets force trade-offs. When you can't have everything, you prioritise what matters.
Setting Meaningful Budgets
Start with user research. What devices and connections do your users have? Budget for your actual audience, not your dev machines.
Benchmark competitors. If competitors load in 2 seconds and you take 5, you're losing users.
Use real metrics. Core Web Vitals (LCP, FID, CLS) map to user experience better than raw transfer size.
Enforcing Budgets
Build-time checks. Fail the build if bundle size exceeds limits. webpack-bundle-analyzer, bundlesize, size-limit.
CI integration. Lighthouse CI can fail builds that miss performance targets.
Monitoring. Track real user metrics. Synthetic tests don't catch everything.
Budget Examples
JavaScript: Total JS under 300KB compressed. Main bundle under 150KB.
Images: Largest image under 200KB. Prefer modern formats (WebP, AVIF).
Fonts: Maximum 2 font families. Subset to needed characters.
Third parties: Total third-party scripts under 100KB. Audit regularly.
When to Exceed the Budget
Sometimes you must. But make it explicit. "We're exceeding the JS budget by 50KB for feature X. Here's the justification."
Document the decision. Future you will want to know why.
At Logic Leap, we help teams establish performance cultures that stick. Need help setting and maintaining performance standards? Let's talk.
What performance budgets have worked for your team?
Top comments (0)