By the time a build reaches a performance pass, the expensive decisions are already made: the hero video, the four typefaces, the animation library imported for one transition. Optimisation at that stage is trimming around the edges of a choice made months earlier.
The alternative is a budget agreed at kickoff, in numbers everyone understands, enforced automatically.
A budget people can actually hold
One megabyte on the initial view. Largest contentful paint under 1.5 seconds on a mid-range Android over 4G. No third-party script without a named owner and a stated reason.
These are not aspirations in a document. They run in CI, and a pull request that breaks them fails the same way a broken test fails.
A performance budget that is not enforced in CI is a wish.
It changes the design conversation
Once a budget exists, the conversation stops being 'is this fast enough' and becomes 'what is this worth'. A hero video costs 800kb. Is it worth more than everything else you might spend that on? Sometimes the answer is genuinely yes, and now it is a decision rather than an accident.
Northline's article weight fell from fourteen megabytes to just over one. Almost none of that came from clever compression. It came from deciding, early, what the pages were allowed to cost.
Working on something where this applies? I take on three or four substantial engagements a year. Start a conversation. It costs nothing and usually clarifies more than it takes.
