Set the performance budget before the design, not after the complaints

Almost every team says performance matters. Almost every team also schedules it as a phase near the end, where it competes with shipping and loses.

The teams that end up with fast products do something different, and it is not heroic optimisation. They decide what "fast enough" means before anyone opens a design tool, and then treat that number the way they treat a browser support matrix: as a constraint, not a goal.

Why "we will optimise later" fails

Three reasons, and the third is the one that gets you.

1. Nothing forces the trade-off. Every individual feature is worth its cost in isolation. Without a budget, nothing ever says no, and the sum is slow.
2. The cheap fixes run out. Compression, caching and image formats buy you a fixed, modest amount. After that you are into architecture.
3. The expensive causes are architectural. An over-fetching data layer, a render path that blocks on the network, a third-party script in the critical path. These are decided early and cost enormously to undo late.

By the time you measure, the decisions that determined the outcome are months old.

What a budget looks like

A budget is a small number of specific limits that a build can pass or fail. Ours for KoiSpeak's lookup, as an example:

Two properties make a budget real rather than decorative:

• It is a number, not an adjective. "Fast" cannot fail a build. 150 ms can.
• It is measured on a device your users have. A budget measured on the developer's laptop over office wifi is measuring nothing.

Test on the hardware that actually exists

This is where most performance work goes wrong before it starts.

Development happens on fast machines on fast connections. Your users are on mid-range Android phones, several years old, on mobile data, with a dozen apps in the background. The gap between those two experiences is not 20%. It is routinely 5 to 10 times on CPU-bound work.

Practical minimums:

• Keep one genuinely mid-range device on the desk and use it weekly.
• Use CPU throttling in dev tools by default, not as a special exercise.
• Collect field data from real sessions, not just lab numbers. Lab tells you what changed; field tells you what users got.

How a budget changes decisions

The value is not in the measuring. It is in the arguments it settles early, cheaply, before anything is built.

• A font family becomes a cost. Four weights and two families is a real fraction of a mobile budget. You choose two weights instead, at design time, without drama.
• An animation library needs to justify itself against the CSS you would otherwise write.
• Analytics and chat widgets get counted. Third-party scripts are frequently the single largest item, and nobody notices because nobody on the team wrote them.
• Data shape follows the budget. If first result must land in 150 ms, you cannot fetch a large payload and filter it client-side. That pushes you toward a prefix index, which is the right answer anyway.

That last one is the pattern. A budget does not slow you down; it makes the correct architecture obvious sooner.

Performance work done after launch is a rescue operation. Performance treated as a constraint from the start is just design.

Enforcing it without ceremony

A budget nobody checks is a wish. Keep enforcement cheap:

• Fail the build on bundle size. One line of CI config, catches most regressions, costs nothing to maintain.
• Run a synthetic audit per pull request on the two or three routes that matter most.
• Alert on field metrics weekly, not per commit. Real-user data is noisy; look at trends.
• Review the budget when the product changes. Budgets are not sacred. Raising one deliberately, with a reason, is fine. Drifting past one silently is not.

Where to spend the budget you have

Budgets are about allocation, not minimalism. Some things are worth their weight:

• The critical path. Whatever the user came for must be first, and the rest can wait. On a dictionary, the search box and result. On a shop, the product image and price.
• Perceived speed over measured speed. Showing a result skeleton immediately often beats making the response 40 ms faster.
• Instant feedback on input. A response to a keystroke within about 100 ms reads as instant. Beyond roughly 300 ms, people notice.

The uncomfortable part

A real budget means saying no to things that are individually good. That is what makes it work, and also why teams quietly abandon budgets: the first time one blocks a feature somebody wants, the easy move is to raise it.

The discipline is not in setting the number. It is in the meeting where you keep it.