Doherty Threshold

What is it?

The Doherty Threshold states that computer system productivity increases dramatically when response times fall below 400 milliseconds. First published by Walter J. Doherty and Ahrvind J. Thadani in an IBM Systems Journal paper in 1982, it identifies 400ms as the threshold below which users experience a system as instantly responsive and enter a state of flow.

Why it matters

Above 400ms, users begin to feel a system is slow. Above 1 second, they notice a delay. Above 10 seconds, they disengage entirely. Web performance has a direct, measurable impact on conversion rates, engagement, and retention. Amazon found that every 100ms of latency cost them 1% in sales. Google found a 0.5-second delay reduced searches by 20%.

Best Practices

• Target < 400ms for all interactive responses — clicks, form submissions, navigation.
• Use optimistic UI updates: show the result immediately, then confirm with the server. Linear and Superhuman use this pattern for every action.
• Implement skeleton screens for content that takes > 300ms to load — perceived load time is lower than actual load time.
• Lazy load below-the-fold content. Prioritize what appears in the viewport first.
• Use content delivery networks (CDNs) to reduce geographical latency.
• Prefetch likely next routes — hovering over a link can pre-load the destination page.
• Cache aggressively. Returning users should never wait for data they've already seen.
• Show progress for any operation > 1 second. Users tolerate delays better when they see progress.
• Compress images and assets. A 4MB hero image is a Doherty violation.
• Measure Core Web Vitals (FCP, LCP, CLS, INP) — Google's performance metrics are grounded in Doherty principles.

Common Mistakes

• No loading indicators for operations over 1 second — users assume the app has crashed.
• Unoptimized images (4K images displayed at 200px width) adding unnecessary load time.
• No skeleton screens — blank space while data loads creates "jank" that breaks flow.
• Blocking renders on non-critical JavaScript.
• No optimistic UI updates — every action waits for server confirmation before the UI changes.
• Not measuring performance on real devices and real connections (testing only on fast developer machines).

Checklist

Research & Theory

Real-World Examples