Latency is a feeling
Users don't measure milliseconds. They measure doubt.
We talk about performance as if it were a number. Time to first byte, largest contentful paint, p99. These are useful instruments, but they measure the machine. The person on the other side of the screen is measuring something else entirely: how long they were left wondering whether anything was happening.
A 300ms response that acknowledges a tap instantly feels faster than a 150ms response that gives no sign of life until it finishes. The first one is a conversation. The second is a silence that happens to end quickly. Humans are exquisitely sensitive to silence.
The budget is attention, not time
Every interface spends the user's attention. A spinner spends it. A layout shift spends it twice: once on the jolt, once on finding their place again. An optimistic update spends almost nothing, because the user's model of the world and the screen's model of the world never disagree.
This reframes the engineering question. Instead of asking how fast the server can answer, ask how soon the interface can stop being uncertain. Often the answer has nothing to do with the server. Prefetch on hover. Render the shape of the content before the content. Commit the user's intent locally and reconcile later.
Honesty still matters
There is a cheap version of this idea, where you hide slowness behind animation and hope nobody notices. People notice. Perceived performance only works when the perception is true: the action really did register, the data really is on its way. Fake progress bars train people to distrust every progress bar.
Variance is worse than slowness
A system that always takes a second is easier to live with than one that usually takes a hundred milliseconds and occasionally takes five seconds. People adapt to a steady rhythm. They build habits around it. What they cannot adapt to is unpredictability, because every interaction now carries a small question: is this one of the slow ones?
This is why tail latency matters more than averages suggest. The p50 describes the experience you designed. The p99 describes the experience your most engaged users have every day, because the people who use a product most are the ones who hit its edges most often. Optimise the median and you please the casual visitor. Tame the tail and you keep the people who depend on you.
It is also why the fix is often architectural rather than local. A slow query can be indexed. A request that fans out to six services, each with its own occasional hiccup, will inherit the worst of all six. Fewer hops, fewer dependencies in the critical path and sensible timeouts do more for the feeling of speed than any micro-optimisation inside a single function.
The best fast software is not the one with the lowest number on a dashboard. It is the one where you never once wonder whether it heard you.