A design platform's web application has grown steadily slower with no single change responsible. What mechanism prevents this, and how should it be enforced?

Why it happens

Every individual change is small and defensible. A library added for one feature, an extra request for one component, a slightly larger image, one more third-party script. No change is worth blocking, and the aggregate is a product that takes twice as long to load as it did a year ago.

This is the same structure as constraint drift: no bad decision, no responsible party, and no signal — because nothing fails when performance degrades by 3%.

The mechanism

A performance budget enforced in CI: explicit numeric limits on the metrics that matter, checked on every change, failing the build when exceeded.

Sensible budgets for a media-heavy web application:

• JavaScript bundle size per route, compressed. The most effective single budget, because bundle size is the dominant contributor to time-to-interactive and it only ever grows.
• Total requests on the critical path.
• Time to interactive on a simulated mid-range device and network — not on the developer's machine, which is the fastest device any user will ever have.
• Core web vitals thresholds, measured in the lab for the gate and in the field for truth.
• Image and font payload per page.

What makes enforcement work

1. It fails the build, not a report. A dashboard nobody is required to look at changes nothing. The budget must be a gate.

2. An explicit exception process with an owner and an expiry. Sometimes exceeding the budget is correct — a genuinely valuable feature that costs 20 KB. The exception should be granted deliberately, and the budget raised explicitly rather than silently ignored, so the new number is a decision rather than a drift.

3. Budgets per route, not global. A heavy editor route and a light marketing page have different requirements, and a single global budget is wrong for both.

4. Measured on realistic devices and networks. Testing on a fast machine on fast broadband measures nothing about the median user, and this is the most common reason budgets pass while users suffer.

5. Paired with field measurement. Lab budgets prevent regression; real user monitoring tells you the actual distribution. Both are needed — the lab gate is deterministic and unrepresentative, the field data is representative and noisy.

The organisational point

A performance budget converts performance from a periodic clean-up project into a continuous constraint. The reason it works is not that it catches large regressions — those are noticed anyway — but that it makes the accumulation of small ones visible at the moment each one is made, when the cost of the alternative is still small.