Web Performance Budget
An enforced limit on payload size, resource counts or timing metrics, checked automatically so regressions fail the build rather than accumulating.
Performance degrades by accretion. No single addition is unreasonable — an analytics tag, a chat widget, a font, a carousel library — and the cumulative effect over a year is a site that is twice as heavy with nobody responsible.
A budget converts performance from an aspiration into a constraint with a gate. It is expressed as whatever the team can act on: total JavaScript transferred per route, number of blocking requests, Largest Contentful Paint on a throttled mobile profile, or third-party script weight as a separate line.
Two implementation details decide whether it survives. Measure on a representative device and network profile, since a budget checked on unthrottled desktop is not a budget. And report the regression in the pull request with the specific delta and its cause, because a nightly dashboard finds the regression after it has shipped and lost the connection to the change that caused it.
The political dimension is unavoidable and worth planning for: budgets are usually broken by requests from marketing or analytics, not by engineering. A budget with a documented exception process and a named approver survives that conversation. One without it gets ignored the first time a tag manager script is business-critical.