Latency budgets are a love letter to your users
How thinking in milliseconds-per-feature reshaped how I design APIs and UIs.
Every product I’ve shipped lived or died on a budget I didn’t write down for years: the latency budget. It’s the silent contract you make with your user.
The 100ms threshold
There’s an old number from the Nielsen Norman Group: 100ms feels instant. Anything below that, a user perceives as direct manipulation. Above it, they start to feel a system in between them and their intent.
When you start designing with this in mind, every architectural decision sharpens.
Decomposing the budget
For a “view dashboard” interaction, the budget might look like:
- DNS + TLS: 20ms
- TTFB: 80ms
- Critical CSS + render: 100ms
- First meaningful paint: 200ms
You can’t fit a 300ms database query in a 80ms TTFB budget. So either the query gets faster, or the architecture changes — caching, materialized views, pre-aggregation.
The shift
Once you assign budgets, optimization stops being heroic and starts being mundane. You don’t ship the feature until it fits the budget. That’s it.
It also makes tradeoffs legible to non-engineers:
“We can add this filter, but it costs 40ms on first paint. Are we okay with that?”
That’s a product conversation, not a technical one. And it’s the conversation that ships better software.