Performance budgets: the questions we get asked most

Most teams know this matters. Fewer have decided who owns it. The questions about performance budgets that come up most often on our calls.

Performance work is mostly subtraction, which makes it unpopular and effective. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

Do we need to care about this?

A number in writing stops slow creep. Getting it slightly wrong is survivable. Ignoring it entirely is not. Assume whoever inherits this will have half your context and none of your patience.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. Getting it slightly wrong is survivable. Ignoring it entirely is not.

How do we know it is working?

Enforce it automatically or it gets ignored. None of that requires a large budget, only a decision and someone to own it. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

The short version

Speed is a feature people notice only in its absence, and then they leave rather than complain. Three things worth confirming about performance budgets before you move on:

• Someone can say what the current setup is without going to look
• Budget for total page weight and script size — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If any of that sounds like a description of your current setup, it is fixable.