Most performance budgets die the same death. They are agreed in a kickoff, written into a document, and never mentioned again until somebody complains the site feels slow.
Budget the thing, not the score
A single composite score is a poor budget because it hides what changed. Two hundred kilobytes of new JavaScript and a badly sized hero image can move the same number, and they need completely different conversations.
Budget the raw quantities instead:
- Total JavaScript delivered on the busiest route.
- Largest image, in bytes, above the fold.
- Number of third-party origins contacted before first paint.
- Font files loaded before text is readable.
Each of these has an obvious owner and an obvious fix, which is the entire point.
Put the number where the work happens
A budget in a wiki is a wish. A budget that appears in the review of the change that broke it is a decision. The mechanism matters less than the placement: it has to interrupt the person who can still act on it, at the moment they can still act.
If exceeding the budget is invisible, the budget has already been exceeded.
Leave room for the exception
Rigid budgets get disabled. Build the escape hatch on purpose: exceeding it is allowed, but it requires a sentence explaining why and a name attached. Almost nobody wants to write that sentence for a carousel, which turns out to be the most effective performance tool ever invented.
Review it quarterly
Budgets should move. Traffic shifts to mobile, a market with slower networks becomes important, a route becomes central to the business. A budget set once and never revisited is measuring a product you no longer have.
