Doherty threshold

Start with the number, because the number is wrong. Doherty and Thadhani's “The Economic Value of Rapid Response Time” (1982) is a customer-facing IBM brief, not the peer-reviewed article it is usually credited to, and it never mentions 400 milliseconds. It argues for “sub-second” response; its fastest reported data point is 0.3 seconds and its card-wiring tests bottom out at 0.25 seconds. The popular formulation, that productivity soars under 400 ms, was added later by people summarising it. So there is no line to pass or fail, and a response-time budget written against one is fiction.

The brief's own content is IBM field observations, and they are large. A programmer completed about 180 transactions per hour at three-second system response and 371 per hour at 0.3 seconds, a 106% increase. At the National Institutes of Health computer centre, as simultaneous users grew to almost 400 and average response degraded to four seconds, the time to complete an average task rose 50%, from 32 to 48 minutes, costing an estimated 22,500 extra terminal hours and $900,000 a month. None of it had a control group, and the organisation publishing it sold processor upgrades. The mechanism Doherty and Kelisky proposed in 1979 is quoted in the brief: people “seem to have a sequence of actions in mind, contained in a short-term mental memory buffer”, and delay “seem[s] to disrupt the thought processes”. That is an argument for protecting a user mid-sequence, not for a uniform speed target across a product.

Shneiderman audited this literature in 1984 and the audit is more useful than the brief. He confirms the interaction-rate findings — a circuit designer in Smith's 1983 study went from 800 interactions per hour at 1.5 seconds to 4,300 at 0.4 seconds — then says the quiet part: “these results are strong, but they only measure interactions per hour, not productivity.” Part of the gain is that users simply pick up the pace of the system; Boies found user think time rising from about 15 to 24 seconds as response went from 1 to 10 seconds. One study's faster group also each had their own terminal while controls shared one between 1.8 people. And the effect is not universal: Dannenbring found that moving response time from 0 to 5 to 10 seconds changed neither performance time nor satisfaction for novice or experienced programmers debugging a short BASIC program. Counting actions per hour will flatter a speed-up that produced no extra work.

Speed also buys errors. Barber and Lucas studied 100 professional circuit-layout clerks and found a U-shaped error curve: 49 errors out of 287 transactions at a four-second response, 16 out of 222 at twelve seconds, and 70 out of 151 at twenty-four seconds. The lowest error rate was at twelve seconds — faster responses produced hasty decisions, slower ones burdened short-term memory. Productive transactions, total minus errors, still rose almost linearly as response fell, so faster was still better overall, but Shneiderman concludes there is “little evidence to support the claim that fewer errors are made with very short response times (under 1 second).” On an irreversible path, a faster interface mostly produces faster mistakes.

The modern evidence is where this principle earns its place, and it prices latency rather than thresholding it. Brutlag injected server-side delay into Google web search: a 50 ms pre-header delay produced no measurable change in daily searches per user, 100 ms produced −0.20%, a 200 ms post-header delay −0.29%, and 400 ms −0.59% over six weeks. The damage grew with exposure — the 400 ms group was down 0.44% in the first three weeks and 0.74% in the second three — and persisted at −0.21% across the five weeks after the delay was removed. At Bing, Kohavi and colleagues slowed 10% of users by 100 ms and another 10% by 250 ms and concluded that every 100 ms of speedup improves revenue by 0.6%, with a linear approximation holding across slowdown magnitudes. Neither dataset has a knee at 400 ms, so the useful artefact is your own slope per 100 ms, not a target to clear.

The same Bing work shows where latency is free: delaying the right-pane elements of the results page by 250 ms had no detectable impact on key metrics across almost 20 million users. What costs money is delay in front of the thing the user came for — which is also why window.onload is a poor proxy. The authors note an Amazon page rendering above the fold in 2.0 seconds while onload fires at 5.2, and Gmail firing onload at 3.3 seconds when only the progress bar is visible.

The two patterns usually prescribed for this principle have almost no evidence behind them. The best public test of skeleton screens is Viget's: 136 participants saw loading animations of identical length, and the skeleton did worst on every measure, with a mean perceived wait of 2.82 seconds against 2.41 for a spinner and 2.29 for a blank screen. No significance tests were reported, the samples are small and the stimuli were simulated GIFs, so this does not show that skeletons hurt; it shows that nobody has shown they help. Optimistic UI has no published controlled evidence at all. Grade the two halves separately: that responsiveness pays, roughly in proportion to milliseconds, rests on large field experiments; the 400 ms threshold and the widgets sold with it do not.