Jonas repairs bikes in Ghent and has just launched a booking page. He tests it himself from the workshop: picks Thursday, types his name, presses Book repair.
Nothing happens. The button just sits there.
He presses it again. And once more, harder, as if that helps. Two seconds later the page jumps to “Thanks!” and that evening his inbox holds three identical bookings for Thursday. If he did that, his customers will too.
The server was not even slow. It took under two seconds. What failed was the half-second before anything changed on screen.
Jonas and his workshop are imagined. The research, the figures and the standards below are real.
Speed has two halves. One is how fast your page actually loads and responds, which you measure with tools like Core Web Vitals (covered in the Core Web Vitals chapter). The other is how fast it feels, which depends largely on feedback: whether the interface acknowledges people immediately and keeps them informed. This chapter is about that second half, and about the research numbers that get quoted, often loosely, to justify both.
0.1, 1 and 10 seconds
If you read anything about response times, you will meet three numbers. Jakob Nielsen set them out in his 1993 book Usability Engineering, and his consultancy has repeated them ever since:
- 0.1 second is about the limit for feeling that the system reacts instantaneously. No special feedback is needed beyond showing the result.
- 1 second is about the limit for the user's flow of thought to stay uninterrupted. They notice the delay, but stay with you.
- 10 seconds is about the limit for keeping attention on the task. Beyond that, people want to know when it will be done, and start doing something else.
Nielsen grounded these in two older sources: a 1968 conference paper by Robert B. Miller of IBM, and a 1991 paper by Stuart Card, George Robertson and Jock Mackinlay at Xerox PARC, who used the same orders of magnitude while designing an interactive visualization system.
These are useful rules of thumb. They are also less scientific than their round numbers suggest. In a 2018 essay for the Web Performance Calendar, Gilles Dubuc of the Wikimedia Foundation's performance team went back to Miller's paper and described it as a largely subjective essay: its time limits came from reasoned judgment about conversation-like interaction, not from experiments. Miller even recommended waiting two to four seconds before showing some error messages, because interrupting someone mid-thought is, as he put it, rude.
So treat the three limits as orders of magnitude that match a lot of experience, not as laws of physics. The direction is reliable: under a tenth of a second feels like cause and effect, around a second feels like a pause, and beyond several seconds people drift.
Rules of thumb for how delay feels, not results of a single experiment. Their practical message is about feedback, not just speed: acknowledge every action within about 0.1 second, explain anything that takes longer than about a second, and show progress for anything near 10 seconds.
What to do: time the main actions on your site with a stopwatch app: pressing the main button, submitting the form, opening the menu. Put each one in a band of Figure 1 and check that what appears on screen matches the band.
The Doherty threshold, checked
The most quoted speed “law” in design circles is the Doherty threshold. The popular Laws of UX site states it as: productivity soars when computer and user interact at a pace under 400 milliseconds, so neither has to wait on the other. It credits a 1982 paper by Walter Doherty and Ahrvind Thadani of IBM, saying it replaced an earlier 2-second standard with 400 milliseconds.
The paper exists. It is an IBM report called “The Economic Value of Rapid Response Time” (November 1982), republished online with IBM's permission. It is worth reading what it actually contains, because it is not quite what the law says.
It is a business case for faster mainframe systems, built from a handful of studies inside IBM and its customers. The best known draws on data from Arvind Thadhani of IBM's San Jose laboratory (the name is spelled both ways in the paper): with a system response time of 3 seconds, a programmer completed about 180 transactions an hour. At 0.3 seconds, about 371, roughly double.
Other examples in the report are similar in kind: engineers doing card-wiring design in four IBM laboratories finished tasks faster as response time dropped toward 0.25 seconds; a programming project at Portsmouth ran faster and with fewer defects after response time fell from 2.3 to 0.84 seconds. The authors' argument was that each second of system delay also slows the person, because they lose the sequence of actions they were holding in mind. They contrast this with the earlier view, associated with Miller, that up to two seconds was fine because people were thinking anyway.
Here is the surprise. In the republished text, the number 400 milliseconds does not appear. The report argues for sub-second response and cites figures between 0.25 and 0.84 seconds. Where the precise 400 ms threshold entered the story is unclear; it is attached to the paper in later retellings.
That does not make the idea wrong. It makes it a reasonable inference from old, small, workplace studies, rather than a measured threshold for websites. The honest summary: people work and decide faster when the system keeps up with them, and the gains continue below one second.
What to do: stop debating whether your target is 400 or 500 milliseconds. Aim for an immediate visible reaction to every press, and as little waiting as you can manage after that.
Feel the thresholds
Numbers on a page do not convey what a delay feels like. Your thumb does. Each button below “books a repair” after a fixed delay. First try them with feedback switched off, then on.
With feedback off, the button gives no sign until the result appears, and extra presses are counted as duplicate bookings. With feedback on, the button reacts at once, says what it is doing, and ignores repeat presses. No network request is made; the delays are simulated. Without JavaScript the buttons do nothing.
Most people find the 100 ms button indistinguishable from instant in both modes. The 400 ms button feels slightly sluggish without feedback and fine with it. The 1,500 ms button is where the difference is stark: without feedback, many people press again before it answers. That is exactly how Jonas booked himself three times.
Notice also what feedback does not do. It does not make the 1,500 ms button fast. It makes the wait legible, and it prevents the mistakes that impatience causes.
What to do: try your own submit button on a slow connection. In Chrome's developer tools you can throttle the network. Count how many times you instinctively press it.
Always say what is happening
In 1994, Jakob Nielsen published his ten usability heuristics, refined from a factor analysis of 249 usability problems. The first one is about exactly this: visibility of system status. The design should keep users informed about what is going on, through appropriate feedback within a reasonable time.
For a small business site, almost all of this comes down to the life of one button.
A few details carry most of the value:
- React within a tenth of a second. A pressed style or a label change, even before the server is contacted.
- Say what it is doing. “Sending…” or “Booking…” beats a spinner alone, because it tells people what is being waited for.
- Block duplicates. Ignore repeat presses while the request is in flight, and make the server tolerant of duplicates too.
- End clearly. Confirm what succeeded (the thank-you pages chapter covers what comes next), or explain the error and keep the data.
There is a further technique, popular in apps: optimistic UI. The interface shows the result immediately, assuming the request will succeed, and quietly reconciles with the server afterwards. A “like” turns solid at once; a to-do item appears in the list before it is saved. It feels instantaneous because, visually, it is.
Optimistic UI is a design practice, not a researched law, and it has a clear boundary. Use it for small, reversible, low-stakes actions that almost always succeed. Do not use it for bookings, payments, orders or anything someone will act on, such as cycling to the workshop. If an optimistic action fails, the interface must say so visibly and undo the change; silently reverting is worse than a spinner.
What to do: list every button that sends something on your site. For each, check the five states in Figure 3. Most small sites have Idle and Done, and nothing in between.
The psychology of waiting
Some waits cannot be removed: a payment provider, an availability check, an upload. For those, the best guide is still a 1985 essay by the service-management writer David Maister, “The Psychology of Waiting Lines”. Written about banks, restaurants and theme parks, its eight propositions read like a checklist for loading states:
- Occupied time feels shorter than unoccupied time.
- People want to get started.
- Anxiety makes waits seem longer.
- Uncertain waits are longer than known, finite waits.
- Unexplained waits are longer than explained waits.
- Unfair waits are longer than equitable waits.
- The more valuable the service, the longer people will wait.
- Solo waits feel longer than group waits.
Maister's propositions are based on observation, not controlled experiments, so they are hypotheses rather than findings. Several have since been echoed in research. Ryan Buell and Michael Norton's 2011 experiments on the “labor illusion” found that people could prefer a simulated travel or dating website that visibly showed its work over one that returned identical results instantly. Explaining a wait can add value, not just reduce annoyance.
In web terms: say what is happening (“Checking Thursday's slots…”), say roughly how long, and let people start on something useful in the meantime. Do not invent fake “work” animations to look busy; the labor illusion works because the effort is real.
What to do: for every wait over a second on your site, rewrite the loading text so it names the task being performed. “Loading…” describes the software. “Finding times for Thursday” describes the customer's goal.
Progress bars and skeleton screens
For longer waits, the shape of the feedback matters too. In 2007, Chris Harrison, Brian Amento, Stacey Kuznetsov and Robert Bell published “Rethinking the Progress Bar” at the UIST conference. 22 participants compared pairs of progress bars that all took exactly 5.5 seconds but moved in different ways, 990 comparisons in total.
Two findings stood out. Bars with pauses, especially near the end, were perceived as slower. Bars that accelerated toward the end were perceived as faster. The authors connected this to the peak–end rule: the last moments of a wait weigh heavily in how it is judged. They also noted that participants tended to prefer whichever bar they saw first, a reminder that perceived speed is slippery to measure.
The study is small, used short 5.5-second bars, and asked which looked faster rather than measuring abandonment. Its practical lesson is modest and useful: if you can choose the order of steps, put the slow, unpredictable work early and let the end move briskly. Never let a bar sit at 99%.
Skeleton screens, the grey placeholder blocks that mimic a page's layout while it loads, are often presented as a proven improvement. The evidence is mixed.
| Source | What it says | How strong |
|---|---|---|
| NN/g, Tankala (2023) | Use skeletons for full-page loads under about 10 seconds; spinners for single modules of roughly 2–10 seconds; progress bars beyond 10 seconds. Skeletons do not replace performance work. | Expert guidance, citing a 2018 study by Mejtoft and colleagues. |
| Viget, Faulkner & Olvera (2017) | 136 people saw a simulated load as a skeleton, spinner or blank screen. The skeleton group rated the load as slowest (perceived 2.82 s vs 2.41 s spinner, 2.29 s blank). | One small online test with animated GIFs and unequal groups. |
A reasonable reading: skeletons can help when they closely match the real layout and the wait is short, but they are not a reliable trick. The most effective skeleton is the one you no longer need because the page is fast.
What to do: for waits under a second, show nothing special. From one to ten seconds, use a clear busy state with words. Beyond ten, show real progress and a way to cancel. Test a skeleton against a simple alternative before assuming it helps.
What speed is worth
Speed statistics are some of the most repeated, and least checked, numbers in web design. Here is what we could verify.
In 2020, Deloitte published “Milliseconds Make Millions”, a study commissioned by Google. The team analysed 37 European and American brand sites and more than 30 million user sessions over four weeks, looking at how natural variation in mobile site speed related to what visitors did.
Read these carefully. The study is correlational: faster sessions were associated with better outcomes, which is not the same as proving that a 0.1-second improvement on your site will produce 8.4% more sales. Faster sessions also tend to come from better devices and connections. And the commissioning party sells speed tools. The direction is consistent with everything else in this chapter; the precise percentages are not a forecast.
Two other figures circulate widely: a 2017 Google analysis of how bounce probability rises with load time, and Akamai's 2017 retail performance report. We tried to re-open both for this chapter. Google's original page now redirects to a general marketing page, and Akamai's press release was not accessible to us, so we are not repeating their numbers here. If you cite them, cite them as company claims and link the original.
For measuring your own site properly, the field metrics Google uses (Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift) are explained in the Core Web Vitals chapter. Interaction to Next Paint is the one closest to this chapter: it measures how quickly the page visibly responds after a tap or click.
What to do: treat speed statistics as direction, not promise. Measure your own site before and after a change, on real phones, and watch your own enquiries, not someone else's averages.
The rules that apply
Feedback is not only good practice. Two WCAG success criteria apply directly, and WCAG Level AA is the benchmark most accessibility rules point to (see the accessibility chapter).
When content changes to report status, such as “Sending…”, “Booking confirmed”, “3 results” or “2 errors in the form”, the message must be marked up (for example with role="status" or role="alert") so assistive technology can announce it without moving the user's focus. Added in WCAG 2.1. The W3C's guidance recommends role="status" for results and progress, and reserves role="alert" for important, time-sensitive warnings; overusing assertive announcements is listed as a failure.
Source: W3C, Understanding WCAG 2.2, SC 4.1.3. General information, not legal advice.
For each time limit set by the content, such as a session that expires or a basket held for 15 minutes, users must be able to turn it off, adjust it to at least ten times the default, or be warned before it expires and given at least 20 seconds to extend it with a simple action, at least ten times. Exceptions cover real-time events like auctions, limits that are essential to the activity, and limits longer than 20 hours. This applies to the timers discussed in the defaults and urgency chapter whenever they limit the visitor's own task.
Source: W3C, Understanding WCAG 2.2, SC 2.2.1. Not legal advice.
The demo above follows 4.1.3: the result of each press is announced through a status region, so a screen-reader user hears “Booked” without their focus jumping around. It also disables repeat presses while busy, which helps everyone.
What to do: turn on a screen reader (VoiceOver on Mac and iPhone, TalkBack on Android, NVDA on Windows), submit your form, and listen. If nothing is announced after you press send, add a status message.
What to change tomorrow
Make every button react instantly
A pressed style and a label change within a tenth of a second, before any network request finishes.
Block double submissions
Disable the button while sending, and make the server ignore duplicates. Count your duplicate bookings this month as a baseline.
Name the wait
Replace “Loading…” with the task: “Sending your booking”, “Checking Thursday”. Add a time estimate for anything over a few seconds.
Design the error state
Keep what people typed, explain the problem in plain words, and offer a retry.
Announce status changes
Add
role="status"to the region that shows results and confirmations (WCAG 4.1.3).Then make it actually faster
Feedback makes waits bearable; speed removes them. Measure with real-user data and work through the Core Web Vitals chapter.
What the research supports
Strong in direction: faster response and immediate feedback improve how interactions feel and how efficiently people work. Weaker in detail: the 0.1 / 1 / 10 second limits are well-informed rules of thumb, Miller's 1968 figures were judgment rather than experiment, and the Doherty report argued for sub-second response from small 1980s workplace studies without stating a 400 ms threshold. Progress-bar findings come from one small study; skeleton-screen evidence is mixed. Business figures like Deloitte's are correlational and commissioned.
Sources
- Nielsen, J. (1993). Usability Engineering. Academic Press. Via Nielsen Norman Group, Response Times: The 3 Important Limits. Consulted for the three limits, their stated sources and progress-indicator guidance.
- Miller, R. B. (1968). Response time in man-computer conversational transactions. Proceedings of the AFIPS Fall Joint Computer Conference, Part I, 267–277. Cited via the sources below; not consulted in full.
- Card, S. K., Robertson, G. G. & Mackinlay, J. D. (1991). The Information Visualizer, an Information Workspace. Proceedings of CHI '91, 181–186. Cited as a source of the limits by Nielsen; not consulted in full.
- Dubuc, G. (2018). Magic numbers. Web Performance Calendar, 5 December 2018. Consulted for the critique of Miller's evidence base and his quoted error-message advice.
- Doherty, W. J. & Thadani, A. J. (1982). The Economic Value of Rapid Response Time. IBM report GE20-0752-0. Republished full text consulted, including Figure 9 and the absence of a 400 ms figure.
- Laws of UX. Doherty Threshold. Consulted for the popular formulation.
- Nielsen, J. (1994, updated). 10 Usability Heuristics for User Interface Design. Nielsen Norman Group. Heuristic 1 and its basis.
- Maister, D. H. (1985). The Psychology of Waiting Lines. In Czepiel, Solomon & Surprenant (eds.), The Service Encounter, Lexington Books. Author's republished text consulted.
- Buell, R. W. & Norton, M. I. (2011). The Labor Illusion: How Operational Transparency Increases Perceived Value. Management Science, 57(9), 1564–1579. Abstract consulted.
- Harrison, C., Amento, B., Kuznetsov, S. & Bell, R. (2007). Rethinking the Progress Bar. Proceedings of UIST '07, 115–118. Full text consulted.
- Tankala, S. (2023, reviewed 2026). Skeleton Screens 101. Nielsen Norman Group.
- Faulkner, K. & Olvera, K. (2017). A Bone to Pick with Skeleton Screens. Viget, 19 October 2017. Consulted for method and results.
- Deloitte (2020). Milliseconds Make Millions, commissioned by Google. Summary via web.dev, Milliseconds make millions, and Deloitte Ireland's report page.
- W3C. Understanding SC 4.1.3: Status Messages and Understanding SC 2.2.1: Timing Adjustable.
Sources checked 18 October 2026. Google's 2017 bounce-rate analysis and Akamai's 2017 retail performance report could not be re-opened at their original addresses on that date and are therefore not quoted. Accessibility summaries are general information, not legal advice. Jonas and his workshop are fictional; the figures are original illustrations.