4 ms·
The 400 ms threshold cited for the Doherty threshold is from a 1982 research paper. I imagine that in 1982, 400 ms response times felt pretty darn good. Also,
by wtracy 6y ago
The 400 ms threshold cited for the Doherty threshold is from a 1982 research paper. I imagine that in 1982, 400 ms response times felt pretty darn good.
Also, the nature of the tasks that users performed in 1982 may have meant that there was no benefit to <400ms response times. (If it takes twenty seconds to read and understand the output, and another ten to key in your next command, then a 400 ms delay is not a meaningful productivity drag.)
Today, I would guess that the threshold is closer to 50 ms.
(Also, "time spent by the computer waiting for the user" makes sense in the context of a 1982 research paper. That has changed in the last 28 years, to say the least.)
All of this is a long way off saying that if you are making UX decisions based on 28 year old research, you are on shaky ground!
- FridgeSeal 6y agoI agree, 400ms is a long time. I’d be over the moon if most websites did things within 50ms, even 100ms would be a significant and welcome improvement. Anecdotally, when I’m working on the database at work, the olap database (Clickhouse) feels amazingly snappy because it’ll respond in around 30-60ms, but SQL server feels like molasses, even when doing queries each dB is designed for.
- kazinator 6y ago1982 was 38 years ago, not 28. The microcomputers I used in 1982 had instantaneous response time. Most of the software was developed by assembly language die-hards. 400 ms is more acceptable if there is no jitter in it, in comparison to unpredictable response time.