Latency Shapes Experience
At what point does a delay stop being slow and start being untrustworthy?
The idea
Users perceive delay, so architecture affects behavior as well as speed.
In the real world
Immediate feedback makes a save button feel trustworthy.
Going deeper
Delay is not experienced as a number but as an interpretation. Below roughly a tenth of a second an action feels instant; up to about a second it feels connected; past a few seconds attention leaves and the interface starts to feel broken rather than slow.
What matters is that the interpretation drives behaviour, and behaviour creates correctness problems. An unacknowledged save is read as a failed save, so people click again, and now there are duplicate records that no amount of server tuning would have prevented. Acknowledging the action immediately — a spinner, a disabled button, an optimistic update — often matters more than making it faster.
Where it stops applying
Some operations are genuinely slow and cannot be made fast. The answer there is honest progress reporting rather than a faster-feeling lie, because a progress bar that stalls is worse than a slow one that moves.
Why it matters
It turns response time from an engineering metric into a behavioural one: what people do while they wait, and whether they do it twice.
Try this today
Measure the slowest step in one important workflow.
Test yourself
A save button takes two seconds and gives no feedback. Users click it repeatedly. What did the delay actually cost you?
Show the answer
Duplicate submissions and lost confidence, not two seconds. Without acknowledgement the delay reads as failure, so people retry, which is a correctness problem produced by a performance decision.
Learn this in the feed Answering from memory, then again days later, is what makes it stick.