Performance budgets are a design decision

Here is the position: a performance budget belongs at the start of the design process, stated in kilobytes and milliseconds, agreed before anyone opens a design tool. Set there, it shapes what gets designed. Set anywhere later, it becomes a cleanup exercise that always loses to the calendar.

Why “optimize it later” structurally fails

By the time a slow site reaches an engineer with instructions to make it fast, the expensive decisions are already embedded: the design language needs four font weights, the hero concept is a video, the analytics suite was promised to marketing. Optimization at that stage is negotiating each decision backwards against people who have already shipped their part. You win small concessions and lose the war.

A budget agreed up front inverts this. “The article page ships under 200 KB” is a sentence a designer can work inside, the same way they work inside a brand palette. The four-weight typography concept never gets designed, because it never fit. Nobody has to be the villain later.

A budget with teeth

Numbers vary by product; the structure does not. Mine, for this site:

Resource	Budget
HTML, gzipped	~15 KB
CSS, gzipped	~12 KB
JavaScript on an article page	< 15 KB
Hero image	~80 KB
Fonts, total	~40 KB
Whole page	< 200 KB

Two properties make a budget real rather than aspirational. First, it is per-resource, so an overrun points at a culprit instead of a vague total. Second, it is enforced by a machine: continuous integration runs Lighthouse with the thresholds set as errors, and a pull request that busts the budget does not merge. The build failing is the feature. A budget that relies on someone remembering to check is, as I argued in measuring Core Web Vitals without fooling yourself, a number that drifts until it is fiction.

Budgets generate better design, not less of it

The predictable objection is that budgets constrain creativity. The observable reality is the opposite — constraint is where the craft shows up:

• Typography gets sharper. Two font files force a real decision about what the type system is doing, and a considered type system beats a sprawling one on identity as well as bytes.
• Imagery gets intentional. When a hero image costs a third of the page budget, it has to earn its place. Decoration dies; meaning survives.
• Features justify themselves. Every embedded widget arrives with its cost printed on the box. Most of them, examined this way, were never worth it — the same conclusion the discipline of removing things reaches from the aesthetic side.

None of this produces austere pages. It produces pages where everything present was chosen.

The reader is the reason

It is worth keeping the human stakes in view. A 3 MB page on an unlimited fibre connection is an abstraction problem. The same page on metered mobile data is a small tax, levied on the reader, for the privilege of reading you — and on a mid-range phone it is also seconds of parse and layout time before the first word renders. Readers do not file complaints about this. They leave.

A budget is the design process taking those readers seriously from the first sketch. Set one number for the whole page, split it across resources, wire it into CI so it cannot erode quietly, and let it push back on ideas while they are still cheap to change. Speed is not a phase of the project. It is a property of the design, and properties are decided at the start.