Performance is a feature, not a chore
Users never ask for speed, yet they abandon anything slow. Why we budget performance like any other requirement — and how it quietly changes what we ship.
No one opens a product hoping it will be fast; they simply leave when it is slow. That asymmetry is why we treat performance as a feature with an owner and a budget, not a task we get to only if there is time left over.
A budget makes trade-offs visible
When every screen has a weight and a timing budget, adding a heavy dependency stops being invisible. The cost lands on a number someone is responsible for, and the conversation shifts from "can we add this" to "what is it worth".
- Set a byte budget per route and fail the build when it's exceeded.
- Load third-party scripts deliberately, never by default.
- Defer everything below the fold until it is actually needed.
Perceived speed is the real target
The clock the user keeps is not the one on your metrics dashboard. A skeleton that appears instantly, an optimistic update that responds before the network does — these make a product feel fast even when the underlying work takes exactly as long.
Performance is respect for the person on the other end. Budget it, defend it, and it becomes the quiet reason people prefer your product without ever quite knowing why.