0.1 seconds, 1 second, 10 seconds

Three limits for how a wait feels

Asha is on the bus again, with Leaf and Kettle open on her phone. In the next few minutes, she does four things. Each one makes her wait:

• She taps Add tea, and waits for her cart to change.
• She searches for "mint", and waits for the results.
• She pays, and waits while the shop checks with her bank.
• She asks for a year of receipts as one file, and waits while the shop builds it.

How long can each wait be before it feels slow? People don't feel time the way a stopwatch counts it. Research has found a few lengths of wait where the feeling changes.

Here are her four waits, with example times, on a line marked at those lengths:

Lesson 1.1, What is web performance?, listed three of them in a small table: 0.1 second, 1 second and 10 seconds. This lesson takes each one apart. Where does the number come from? What changes for the person at that moment? And what does it mean for the code you write?

First, the units. Code counts time in milliseconds, or ms. A millisecond is a thousandth of a second. Here are the three limits in the units your code uses:

1const limits = [0.1, 1, 10];2 3for (const seconds of limits) {4  console.log(`${seconds} s is ${seconds * 1000} ms`);5}

• Line 1 lists the three limits, in seconds.
• Line 3 takes them one at a time.
• Line 4 multiplies each one by 1,000, because a second has 1,000 ms. It prints 0.1 s is 100 ms, 1 s is 1000 ms and 10 s is 10000 ms.

Notice that each limit is ten times the one before.

Now put the picture's example times into code. Add tea takes 80 ms, the search 400 ms, paying 3 seconds and the receipts 12 seconds. This function says how each wait feels:

1function howItFeels(ms) {2  if (ms <= 100) return "instant";3  if (ms <= 1000) return "noticed, but the flow of thought isn't broken";4  if (ms <= 10000) return "the flow breaks, but attention stays on the task";5  return "attention moves to something else";6}7 8for (const ms of [80, 400, 3000, 12000]) {9  console.log(`${ms} ms: ${howItFeels(ms)}`);10}

• Line 1 starts a function that takes one wait, in milliseconds.
• Line 2: a wait of 100 ms or less feels instant.
• Line 3: up to 1,000 ms, the person notices the wait. But their flow of thought, the line of thinking they're in the middle of, isn't broken.
• Line 4: up to 10,000 ms, that flow breaks. Their attention still stays on the task.
• Line 5: past 10,000 ms, their attention moves to something else.
• Lines 8 to 10 print one line for each of Asha's four waits.

Press Edit & run. It prints one line for each wait, from 80 ms: instant to 12000 ms: attention moves to something else. Those are the same four stretches as in the picture of Asha's screens.

Why it matters: before you make a wait shorter, ask which side of a limit it's on. Making Add tea faster than 80 ms changes little, because it already feels instant. Bringing a slow search under 1 second can save Asha's flow of thought.

Who chose these numbers? Researchers who studied people: Robert Miller in 1968, and Stuart Card's team in 1991. Jakob Nielsen summed up their advice in 1993. A faster phone doesn't change people.

Nielsen made the same point in 2014. He wrote that the limits "have been the same for 46 years now, so they are also not likely to change with whatever implementation technology comes next".

Where the limits come from

In 1993, Jakob Nielsen wrote a book called Usability Engineering. One short passage from it is still often quoted. It begins: "The basic advice regarding response times has been about the same for thirty years". A response time is how long a computer takes to answer something you did. Nielsen pointed to two papers:

• Robert B. Miller, 1968: "Response time in man-computer conversational transactions". Look at the title. Miller treated using a computer as a conversation. You say something, the computer answers, and you say the next thing.
• Stuart Card, George Robertson and Jock Mackinlay, 1991: "The Information Visualizer, an information workspace".

Card's paper names the three lengths outright. It calls them "time constants for the human". These are lengths of time that come from people, not from machines. Its table lists three:

• Perceptual processing: 0.1 second.
• Immediate response: 1 second.
• Unit task: 10 seconds.

0.1 second: it feels like you did it

Start with Nielsen's first limit. He wrote: "0.1 second is about the limit for having the user feel that the system is reacting instantaneously". Then, he adds, "no special feedback is necessary except to display the result".

In a 2014 update, he put it more simply. 0.1 second is the "Limit for users feeling that they are directly manipulating objects in the UI". The UI, or user interface, is everything on the screen that people read and touch. To directly manipulate something is to act on it yourself, like dragging a photo or ticking a box.

His example is a table you sort by clicking a column. If it sorts within 0.1 second, he wrote, "users would feel that they are sorting the table". Otherwise, they feel they are ordering the computer to sort it for them. It's the difference between a light switch and a request.

Why is the edge near 0.1 second? web.dev has an article on how the Core Web Vitals limits were chosen. It traces this one back to a researcher, Albert Michotte. In his book The Perception of Causality (1962), he studied when people see one thing cause another. He showed people two objects on a screen:

• Object A moves toward object B.
• A stops when it touches B.
• After a pause, B moves away.

Michotte changed only the pause. Then he asked people what they saw:

• With a pause of up to about 100 ms, people saw A push B.
• From about 100 to 200 ms, people were split.
• Over about 200 ms, B seemed to start moving on its own.

Now swap the objects. Your tap is A, and the change on the screen is B. web.dev sums up the research. It says feedback within about 100 ms is "perceived as being caused by an associated source, such as a user input". That's the light switch. Try Michotte's experiment yourself. Pick a pause, press Play, and watch the moment A reaches B.

1const move = [{ transform: "translateX(0)" }, { transform: `translateX(${distance}px)` }];2 3ballA.animate(move, { duration: 600, fill: "forwards" }).finished.then(() => {4  setTimeout(() => {5    ballB.animate(move, { duration: 600, fill: "forwards" });6  }, chosenDelay);7});

In the panel's code:

• Line 1 describes one move. The ball slides from where it starts to distance pixels to the right.
• Line 3 slides ball A for 600 ms. When it has finished, line 4 starts a timer.
• Line 6 gives the timer your pause. When the pause is over, line 5 slides ball B the same way.

1 second: your flow of thought keeps going

Next comes Nielsen's second limit. He wrote: "1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay".

Past 0.1 second, the light-switch feeling is gone. But up to about a second, people don't lose their place. Think of a conversation.

Card's team explained this limit with a conversation too. They wrote: "A person can make an unprepared response to some stimulus within about a second". When an answer takes longer, they noted, people fill the gap. The listener says "uh-huh", or the speaker says "uh...", to show they're still in the conversation. So the team tried to make their program report its progress at least once a second.

Miller put the edge a little later. web.dev quotes his words. Tasks "will seriously change their character if response delays are greater than two seconds, with some possible extension of another second or so".

So 1 second is a rough mark, not a sharp line. web.dev found that it stands for a range, "from roughly several hundred milliseconds to several seconds". Why it matters: some taps start a new step, like a search or a new page. For those, aim well under a second.

10 seconds: you need a reason to stay

Nielsen's third limit is about attention. He wrote: "10 seconds is about the limit for keeping the user's attention focused on the dialogue". The dialogue is the back and forth between the person and the computer: Miller's conversation again. For longer waits, Nielsen goes on, "users will want to perform other tasks while waiting for the computer to finish".

For a wait that long, what the screen shows matters. Compare two phone calls:

Nielsen's 2014 update is firm about this. He wrote: "Anything slower than 10 seconds needs a percent-done indicator as well as a clearly signposted way for the user to interrupt the operation". A percent-done indicator is a bar or a number that shows how much of the job is finished. A way to interrupt is a Cancel button. He also warns about people who come back after more than 10 seconds. They "will need to reorient themselves": they have to find their place again.

Card's team called this limit the unit task. It's one small step of a bigger job, "about the pacing of a point and click editor". They gave it as "10 sec (say, 5-30 sec)". So this mark is rough too.

Lesson 1.1's lift with a floor display made the same point. The display doesn't bring the lift sooner, but it tells you the lift is coming. Here are Nielsen's three limits together. Each row is one limit, how it feels, and what he says the page should show.

Lesson 2.2, Perceived performance, shows which kind of progress fits which wait.

100 ms to feel instant

Of the three limits, 0.1 second matters most for your code. It covers every tap, click and key press, so it's worth checking from more sides.

Miller wrote about this exact moment, and he even named the switch. In the lines web.dev quotes from his paper, he describes a "Response to control activation". It's the sign "given, ordinarily, by the movement of a key, switch or other control member that signals it has been physically activated".

That sign, he wrote, should be "perceived as a part of the mechanical action induced by the operator". His time limit for it: "No more than 0.1 second". In plain words: you press a key. The sign that it worked should feel like part of your own press. Later he gives a little more room. He wrote that "the delay between depressing a key and visual feedback should be no more than 0.1 to 0.2 seconds".

Newer research agrees. Kaaresoja and colleagues tested buttons on a touchscreen. Some buttons lit up 85 ms or less after a press. For those, people said 75% of the time that it lit up at the same moment as their press. Up to 100 ms, people rated the press highly. From 100 to 150 ms, their ratings fell. At 300 ms, ratings were very low.

Where does instant end for you? The panel lights up after a hidden pause. Tap, then say whether it felt instant:

1tapButton.addEventListener("click", () => {2  const pressed = performance.now();3  setTimeout(() => {4    light.classList.add("on");5    requestAnimationFrame(() => setTimeout(() => {6      shownAfter = performance.now() - pressed;7    }));8  }, nextDelay());9});

In the panel's code:

• Line 2 notes the time of your tap.
• Line 8 picks the next pause. When it's over, line 4 turns the light on.
• Lines 5 to 7 wait for the frame that shows the light. Line 6 measures the time from your tap to that frame. The panel shows these times at the end.

Why INP allows 200 ms

Google's Core Web Vitals are three numbers for how a page feels. They measure how fast it loads, how fast it responds, and how still it stays. The one for responding is Interaction to Next Paint, or INP.

INP times each tap, click or key press until the browser draws the next frame. A frame is one picture on the screen. It looks at a whole visit and reports one of the slowest. INP calls 200 ms or less good, and over 500 ms poor.

Wait. If the research points to 100 ms, why does INP allow 200? Because web.dev weighed a second question: can real sites meet it? It checked Chrome's records of real visits, the Chrome User Experience Report (CrUX). Two terms first:

• An origin is one website's address, such as https://completefrontend.com.
• Sort all visits from fastest to slowest. The 75th percentile is the visit three quarters of the way along. If it meets a limit, at least 3 visits in 4 did.

Each row is one candidate limit. The columns show the share of origins whose 75th percentile met it, in May 2022. One column is for phones and one is for desktops.

At 100 ms, only 12% of origins passed on phones. At 200 ms, 56% did. web.dev also looked at sites where many visits come from cheaper phones. Those backed 200 ms too. It concluded that 200 ms is "a reasonable threshold for good experiences".

Why it matters: 200 ms is the line Google grades against, not the line where people stop noticing. Where you can, aim for 100.

16.7 ms per frame at 60 Hz, 8.3 ms at 120 Hz

A tap waits for one result. Motion is different. When Asha scrolls down the list of teas, there's no single result. The screen has to keep drawing new pictures, on time, again and again.

Lesson 1.1 compared the screen to a flip book. It shows still pictures, one after another, fast enough to look like movement. Each picture is a frame. How many frames a screen shows each second is its refresh rate. It's counted in hertz (Hz), which means times per second. MDN, Mozilla's web docs, says 60 Hz is the most common, "though 75hz, 120hz, and 144hz are also widely used".

How many frames does motion need? Card's team gave an answer. They wrote: "to maintain the illusion of animation in the world, the screen must be repainted at least every .1 sec". That's 10 pictures a second, just for things to seem to move. To look smooth takes more. web.dev has a guide to the RAIL model, which comes up next. It says people see animations as smooth "so long as 60 new frames are rendered every second".

So how long does one frame last?

1const screens = [60, 90, 120, 144];2 3for (const hz of screens) {4  const frameMs = 1000 / hz;5  console.log(`${hz} Hz: a new frame every ${frameMs.toFixed(1)} ms`);6}

• Line 1 lists four refresh rates.
• Line 3 takes them one at a time.
• Line 4 divides a second, 1,000 ms, by the rate.
• Line 5 prints one line for each: 60 Hz: a new frame every 16.7 ms and 90 Hz: a new frame every 11.1 ms. Then 120 Hz: a new frame every 8.3 ms and 144 Hz: a new frame every 6.9 ms.

That time is the frame's budget: everything for the next picture has to fit inside it. If the frame isn't ready in time, the screen shows the old picture again. The motion stutters. It's the flip book with a stuck page: the picture freezes, then jumps.

Not all of the budget is yours, either. The browser has its own work to do for each frame. It works out where things go, and paints them. RAIL estimated it: "browsers need about 6 ms to render each frame, hence the guideline of 10 ms per frame".

That's at 60 Hz. At 120 Hz, the whole frame is only 8.3 ms. If the browser still needed about 6 ms there, only about 2.3 ms would be left for your code. Why it matters: code that fits easily in a 60 Hz frame can make frames late on a 120 Hz phone.

Measure your own screen. The panel counts how often your browser draws.

1const gaps = [];2let last = performance.now();3 4function onFrame(now) {5  gaps.push(now - last);6  last = now;7  if (gaps.length < 120) requestAnimationFrame(onFrame);8  else showRate(1000 / median(gaps));9}10requestAnimationFrame(onFrame);

In the panel's code:

• requestAnimationFrame asks the browser to run a function just before it draws the next frame. Line 10 asks for the first one.
• Line 5 records the gap between this frame and the last one.
• Line 7 asks for another frame, until there are 120 gaps. Then line 8 takes the middle gap and turns it into frames a second.

Lesson 6.2, The event loop and frames, shows when the browser draws a frame, and what can make one late. The stage Stability and smoothness covers animation that stays smooth.

The RAIL model and what replaced it

Before Core Web Vitals, Google's advice used a model called RAIL. It turned the limits into goals for four kinds of work. Its name is made of their first letters:

• Response: answering a tap or a click.
• Animation: drawing frames while something moves, scrolling included.
• Idle: work the page does while nobody is touching it.
• Load: showing the page in the first place.

Each row is one part of RAIL, its goal, and what to use now.

web.dev's own RAIL page now opens with a note. It says Core Web Vitals "is the recommended approach for defining performance goals over RAIL". It also says their limits are different from RAIL's. So set your goals with the Core Web Vitals, not with RAIL's numbers.

Still, two of RAIL's ideas live on:

• The 50 ms long task. A task is one piece of work the browser does from start to finish, like the code for one click. The W3C, a group that writes web standards, calls a task long when it takes more than 50 ms. While a long task runs, a tap has to wait. Exercise 5 works out where the 50 came from.
• The frame. No Core Web Vital measures smoothness. For anything that moves, the frame budget is still the target.

Lesson 6.2 shows why a long task freezes the page. Lesson 11.5, Long Tasks and Long Animation Frames, shows how to find them.

Turning limits into budgets

A limit says how long a whole wait may be. But a wait is made of parts, one after another. So it helps to split the limit and give each part its own share. That's a budget, like splitting a day's money into bus fare, lunch and tea.

Take INP's 200 ms. It covers one interaction, from Asha's tap to the next frame. It has three parts, one after the other.

• Input delay: the tap waits for the browser to finish what it was already doing.
• Processing: your event handlers run. An event handler is a function that runs when something happens, like a click.
• Presentation delay: the browser works out the new layout and draws the next frame.

Here is one way to split the 200 ms:

1const target = 200;2const inputDelay = 50;3const presentation = 17;4 5const handler = target - inputDelay - presentation;6console.log("time left for the event handler:", handler, "ms");

• Line 1 is INP's good limit, 200 ms.
• Line 2 allows 50 ms of input delay. On a page with no long tasks, a tap shouldn't wait longer than that.
• Line 3 allows 17 ms to draw the next frame, about one frame at 60 Hz.
• Line 5 takes both away from the limit. Line 6 prints time left for the event handler: 133 ms.

Why it matters: say your handler alone needs more than 200 ms. Then no saving in the other two parts can bring the tap under the limit. The work has to shrink, or wait until after the next frame.

Ring the doorbell first

Back to Asha. She taps Add tea, and the shop has to send the order to its server. The answer can take a while. Must the screen stay still until then? No. Think of a doorbell:

Nielsen gives the same advice for his sortable table. When you click a column, it should highlight within 0.1 second, so you know the click landed. If the sort itself can't be done in 0.1 second, he wrote, "it certainly has to be done in 1 second". In code, the doorbell comes first:

1const button = document.querySelector("#add");2const cart = document.querySelector("#cart");3 4button.addEventListener("click", async () => {5  button.textContent = "Adding…";6  const answer = await sendOrder("mint tea");7  cart.textContent = `Cart: ${answer.count}`;8  button.textContent = "Add tea";9});

• Lines 1 and 2 find the Add tea button and the cart's text on the page.
• Line 4 runs a function on every click of the button. The word async lets the function pause partway through.
• Line 5 is the doorbell. It changes the button's text to Adding… before anything slow happens.
• Line 6 sends the order with sendOrder, a pretend server that answers after one second. await pauses the function there until the answer comes. While it's paused, the browser is free to draw the next frame, with Adding… in it.
• Lines 7 and 8 run when the answer arrives. Line 7 shows the new count, and line 8 puts the button's text back.

Press Edit & run and click Add tea. The button changes at once. The cart changes a second later.

INP stops its stopwatch at the first frame after the handler hands control back to the browser. This handler hands it back at line 6's await. So the frame INP times is the one with Adding… in it. web.dev's guide to better INP gives the same advice. First run "just the logic required to apply visual updates for the next frame". Leave the rest for later.

Lesson 11.4, Event Timing and INP, measures the three parts of a real click, with a bell on a café counter. The stage Responsiveness: INP shows how to shrink each part.

Which limit applies?

Each kind of wait has its own limit. To find it, ask what kind of wait it is. Does something move on the screen? Is it a direct action, like a light switch? Is it a new step, like a question in a conversation? Or is it a big job, like a long call on hold?

Common mix-ups

• "100 ms is the INP limit." No. About 100 ms feels instant. INP calls up to 200 ms good. web.dev chose 200 after weighing the research against what real sites reach.
• "Every screen gives me 16.7 ms a frame." No. That's 60 Hz. At 120 Hz, each frame gets 8.3 ms, and the browser's own work comes out of that.
• "The limits are sharp lines." No. They're rough marks. web.dev found that the 1-second limit stands for a range, and Card gave the 10-second one as "say, 5-30 sec".
• "RAIL is the current standard." No. web.dev recommends the Core Web Vitals for performance goals, and their limits are different.
• "Faster is always better." Almost. Nielsen noted that a computer can react too fast to follow. Think of a list that scrolls past the line you wanted. So time animations by the clock, not by how fast the computer runs.
• "Every wait needs a spinner." No. Under a second, just show the result. Past a second, show that the page is working. Past about 10 seconds, show how much is done.
• "The limits will change as computers get faster." No. They're sized to people, like the shop's front door. In 2014, Nielsen wrote that they had been the same for 46 years.

Practice exercises

Answer first, then use the hints.

function howItFeels(ms) {
  if (ms <= 100) return "instant";
  if (ms <= 1000) return "noticed, but the flow of thought isn't broken";
  if (ms <= 10000) return "the flow breaks, but attention stays on the task";
  return "attention moves to something else";
}

for (const ms of [1000]) {
  console.log(`${ms} ms: ${howItFeels(ms)}`);
}

const hz = 90;
console.log((1000 / hz).toFixed(1), "ms");

function feedbackFor(ms) {
  if (ms <= 1000) return "just show the result";
  if (ms <= 10000) return "show that it's working";
  return "show how much is done";
}

console.log(feedbackFor(4000));

const target = 200;
const inputDelay = 50;
const presentation = 8;

const handler = target - inputDelay - presentation;
console.log("time left for the event handler:", handler, "ms");

const goal = 100;
const idleChunk = 50;

console.log("left for the handler:", goal - idleChunk, "ms");

Check your understanding

For each question, ask: is this limit about people, about the screen, or about what real sites can reach?

Key takeaways

• 0.1 second feels instant, as if you did it yourself. 1 second keeps the flow of thought. 10 seconds is the most a person waits with their attention on the task.
• The limits come from research on people: Miller in 1968, Card's team in 1991, and Nielsen in 1993.
• They don't change as computers get faster, and they're rough marks, not sharp lines.
• Up to about 100 ms, people see their action cause the result, as in Michotte's experiment.
• INP's good limit is 200 ms. web.dev chose it by weighing the research against what real sites reach.
• A frame lasts 16.7 ms at 60 Hz and 8.3 ms at 120 Hz, and the browser's own work comes out of it.
• An interaction's 200 ms splits into input delay, processing and presentation delay.
• When the work is slow, ring the doorbell first: change the screen in the next frame, then do the rest.

Sources

The facts on this page come from this research and these docs:

• Response Times: The 3 Important Limits, Jakob Nielsen, Nielsen Norman Group (from Usability Engineering, 1993, with a 2014 update).
• Response time in man-computer conversational transactions (1968), Robert B. Miller.
• The Information Visualizer, an information workspace (1991), Stuart K. Card, George G. Robertson and Jock D. Mackinlay.
• Defining the Core Web Vitals metrics thresholds (Michotte, Miller, Kaaresoja, and the INP data), web.dev.
• Interaction to Next Paint (INP), web.dev.
• Window: requestAnimationFrame(), MDN.
• Measure performance with the RAIL model, web.dev.
• Long Tasks API, W3C.
• Optimize Interaction to Next Paint, web.dev.

Coming next: Perceived performance. Some waits can't be removed. It shows how to make them feel shorter: what to show while people wait, and how to show useful content early.