A booking site sets a JavaScript budget. Six months later it is exceeded on every page. What was missing?

Why budgets erode

Nothing blocked the change that exceeded it. Each individual addition was small and justified — an analytics tag, a support widget, a personalisation library, one more dependency. No single change was unreasonable and the aggregate is far over.

Performance regresses through accumulation, not through a decision. A budget that is a target rather than a gate cannot resist accumulation, because there is never a moment at which someone is choosing to exceed it.

What enforcement requires

• A build-time check that fails the pipeline, so the conversation happens at the change rather than at a quarterly review.
• Attribution per change, showing which dependency added what, so the trade is visible to the person making it.
• A budget per route, not per site, since routes have genuinely different requirements and one global number is wrong everywhere.
• Third-party scripts inside the budget. These are frequently the largest contributor and the least scrutinised, because they arrive through a tag manager rather than through code review.
• An exception process with an expiry, so exceeding it is possible when justified and does not silently become permanent.

The field measurement that keeps it honest

Real user monitoring, segmented by device class and network. A budget met in a lab on a fast device and missed in the field for half the users is a budget measuring the wrong population. The segments that matter are the slowest devices and networks in the actual user base, since the median hides them completely.

The organisational piece

A named owner for the number. Budgets with no owner are everyone's responsibility and therefore nobody's, and the pipeline check is what gives that owner leverage rather than opinions.