Performance is a product decision
Speed is not a final optimisation pass. It changes what a product feels like.
Teams tend to treat performance as a phase near the end — a week of profiling once the features are in. By then the interesting decisions have already been made, and what is left is shaving milliseconds off choices that should have been avoided.
Latency is a feeling, not a number
People do not experience a 400ms delay as four hundred milliseconds. They experience it as hesitation — a small doubt about whether the tap registered. Enough of those and the product feels unreliable, regardless of how correct it is.
Budgets before features
A performance budget agreed at the start is a design constraint. Agreed at the end, it is a complaint. The useful version names the numbers early and treats missing them as a scope conversation rather than a bug.
- Time from tap to first meaningful content.
- Frame consistency during the interactions people repeat most.
- Behaviour on the oldest device you intend to support.
- What happens on a slow, flaky connection — not just an absent one.
The compounding effect
Fast products get used differently. When opening something is free, people open it more often, and the product gets to be useful in situations a slower version never reached. That is a product outcome, which is why the decision belongs with the product.