Web Performance Budgets: Setting Them and Actually Enforcing Them
We've watched performance budgets get adopted enthusiastically and then quietly ignored on more than one client project, usually the first time a feature deadline collides with a budget limit. A number on a dashboard nobody's required to look at doesn't hold up against a sprint deadline. What actually changed behavior was moving the budget check into CI, where a pull request fails the build if it exceeds the budget, the same way a failing test would.
We set budgets per route rather than a single site-wide number, since a marketing homepage and an authenticated dashboard have different reasonable weights. Using Lighthouse CI, we set a JavaScript bundle budget of 180KB gzipped for the homepage and 350KB for the dashboard, plus an LCP budget of 2.0s and 2.8s respectively, based on what our Core Web Vitals audits had shown was achievable for each page's actual content needs.
The first month after enforcement, we got real pushback — a developer added a date-picker library that alone blew the homepage JS budget by 40KB, and the PR was blocked. That's exactly the friction the budget is supposed to create; the resolution was swapping to a lighter date-picker rather than requesting a budget exception, which is the outcome we want the system to produce by default.
Budget exceptions do need to exist, because sometimes a feature genuinely requires the weight — we allow a documented override with a comment explaining why, reviewed by a senior engineer, rather than a silent bypass. Without that escape hatch, teams route around the budget system entirely rather than working within it, which defeats the purpose.
Eighteen months in on the client where we first implemented this, median JS payload across their top ten pages is still within 10% of the original budget targets, versus a comparable client without CI enforcement where bundle size crept up nearly 60% over the same period through ordinary feature work. The budget itself was never the hard part — enforcing it automatically, so it didn't depend on anyone remembering to check, was.
