Unstable delay is harder to accept than stably slow
Aliases: latency variance · delay jitter · tail latency
What it is
Two clicks, one back in 80 ms, one in 400 ms, hurt more than every click at 200 ms. What people hate is not slowness. It is not being able to guess how long the next one will take. That is latency jitter: high variance on the same action costs more subjectively than a higher mean with near-zero variance. A system with a pretty mean and a long tail loses, experientially, to one that is slightly slower and the same every time.
Why it happens
Perception builds an expectation from the last few intervals. The next sample inside that expectation is coded “normal”; a sudden stretch is coded “this one broke”. The broken one outweighs nine normal ones — negative peaks stick harder than averages. Stable slowness can become a tempo: people click on a 200 ms beat. Jitter has no beat, so every trial reopens the decision “wait more, or click again”. The decision itself costs more than an extra hundred milliseconds.
Games and AV have measured this cleanly: frame-time variance predicts “stutter” complaints better than mean frame time. Clicks in UI are the same pathway at a lower sampling rate.
Studying it
Run two delay distributions: low mean, high variance (e.g. uniform 50–400 ms) versus slightly higher mean, near-zero variance (e.g. fixed 180 ms). Compare preference, completion time and premature retries on the same task.
Independent variables: mean and variance of delay (orthogonal if possible), dropped frames. Dependent variables: forced-choice preference, retry rate, rate of describing the system as “stuttering” rather than “slow”.
Do not report only the mean. P95, P99 and variance are the visible part of jitter. Labs that always clear cache, or always take one hot path, will measure away the jitter that only shows up in the field.
Where it stops holding
Rare operations treated as a new dialogue each time (a tax page opened once a year) give people no chance to form an expectation; jitter is not worse than the mean, because there is no “next time”. In high-stakes submits (payment) people will wait for confirmation anyway; a single stretch with wait feedback is not necessarily worse than jitter — but a pay button that is instant sometimes and stuck sometimes still triggers “did it take”. Real-time control (driving, surgery, instruments) has zero tolerance for jitter; stably slow is also unacceptable there, but jitter condemns the system first.
Applying it
- Budget both mean and tail: P95 / P99 pass with P50, not the average alone.
- For repeated actions on the same control (save, send, tab switch), cut variance first: cache, connection reuse, no occasional full recompute.
- User words “stutter / hitch” are a jitter lead; user words “slow” are a mean lead.
- How to check: tap the same button ten times and plot the ten durations. A spread that starts double-taps means jitter is already in the way more than the mean. Pull all ten onto a slightly slower but almost flat line; double-taps should drop.