Fast event handlers

Why does Asha's cart wait for the analytics?

Asha is back on the Leaf and Kettle tea list, on her phone. She clicks Add on Mint tea. For a quarter of a second, nothing changes. Then two things appear at once. The badge at the top says Cart: 1. And a line under the search box says which teas go well with Mint tea.

Ravi built that Add button. When Asha clicks it, his code does four jobs:

• Show the badge: change Cart: 0 to Cart: 1.
• Show suggestions: pick teas that go well with Mint tea, and show them.
• Save the cart: keep it in the browser, so it's still there tomorrow.
• Send analytics: tell the shop's stats service that someone added Mint tea.

Asha is only waiting for the first one. She wants to know that her click worked. The other three can come a moment later, or when she isn't looking. So why did the badge wait for all of them? And how can it come first, without dropping the rest?

Ravi also built a screen-first page. It does the same four jobs, in a different order. Here is what Asha saw on each page. These are real frames Chrome captured. A frame is one picture the browser draws on the screen.

Here are the same times as code:

1// Times in ms after Asha's click, on her phone.2const pages = [3  { name: "All at once", cartShown: 252.8, suggestionsShown: 252.8 },4  { name: "Screen first", cartShown: 44.9, suggestionsShown: 115.9 },5];6for (const page of pages) {7  console.log(`${page.name}: Cart: 1 after ${page.cartShown.toFixed(1)} ms, the suggestions after ${page.suggestionsShown.toFixed(1)} ms`);8}

• Line 1 is a comment. Times are in milliseconds (ms) after her click. A millisecond is a thousandth of a second.
• Lines 3 and 4 hold the two pages. cartShown is the first frame with Cart: 1. suggestionsShown is the first frame with the suggestions.
• Line 7 prints All at once: Cart: 1 after 252.8 ms, the suggestions after 252.8 ms and Screen first: Cart: 1 after 44.9 ms, the suggestions after 115.9 ms.

It was the same work on the same phone. But on the screen-first page, Cart: 1 came 207.9 ms sooner. Why it matters: Asha judges the page by the first change she sees, not by when all the work is done.

An event handler is the code that runs when an event happens, like a click. Lesson 26.2 split a click's time into three parts. The handlers' part is called processing duration. This lesson makes that part short, in four steps:

1. Show the change first, then yield.
2. Move saving and analytics to quiet moments.
3. Let scrolling start without waiting for your listener.
4. Wait for the typing to stop before a slow search.

How the course recorded it

• Ten pages: nine are the tea list from lesson 26.1, with one new script on each. Four change the Add button, three add a scroll listener, and two change the search box. The tenth times localStorage writes.
• Asha's phone: this computer in Chrome 157, with its processor, the CPU, slowed 4 times, as in Module 27.
• Stand-in work: each slow job runs a loop called work() for a set number of steps. It stands in for real code that takes time.
• Three runs each: each page loaded three times, taking turns. The lesson quotes the middle one. Each time, Chrome kept a trace: a detailed record of everything it did, with screenshots.
• Input: clicks and key presses went through Chrome's DevTools protocol, the way programs drive Chrome. Chrome passes them straight to the page, as it does a real mouse or keyboard. Wheel turns are different. The scrolling section says how.

Show the change, then yield

Here is Ravi's click handler on the first page:

1teas.addEventListener("click", function addToCart(event) {2  if (!event.target.matches(".add")) return;3  const tea = event.target.closest("li").dataset.name;4  cart.push(tea);5  showBadge();6  showSuggestions(tea);7  saveCart();8  sendAnalytics(tea);9});

• Line 1 adds a click listener to the list of teas, teas. A listener is a function you add with addEventListener. This one runs on every click in the list.
• Line 2 stops if the click wasn't on an Add button.
• Line 3 reads the tea's name from its row. Line 4 puts it in the cart.
• Lines 5 to 8 do the four jobs, one after another.

And here are the four jobs:

1const cart = [];2function showBadge() {3  document.querySelector("#cart").textContent = "Cart: " + cart.length;4}5function showSuggestions(tea) {6  work(14_000_000); // picks teas that go well with this one7  document.querySelector("#about").textContent = "Goes well with " + tea + ": Jasmine and Green tea.";8}9function saveCart() {10  work(10_000_000); // packs the cart with every tea's details11  localStorage.setItem("cart", JSON.stringify(cart));12}13function sendAnalytics(tea) {14  work(24_000_000); // the analytics library builds its report15  navigator.sendBeacon("/collect", JSON.stringify({ event: "add_to_cart", tea }));16}

• Lines 2 to 4 change the badge. That's quick.
• Lines 5 to 8 pick the suggestions and show them. Line 6 is the stand-in work: 14 million steps.
• Lines 9 to 12 save the cart. Line 11 writes it to localStorage, a small store the browser keeps for each site.
• Lines 13 to 16 send analytics. Line 15 hands a small message to navigator.sendBeacon(), which sends it to the server.

Why the badge waited

Line 3 changed the badge almost at once. So why didn't Asha see it?

1// The all-at-once click, in ms after Asha's click.2const click = { cartWritten: 4.8, handlersRan: 210.1, cartShown: 252.8 };3console.log(`Cart: 1 was written after ${click.cartWritten.toFixed(1)} ms.`);4console.log(`The click's handlers ran for ${click.handlersRan.toFixed(1)} ms.`);5console.log(`Cart: 1 reached the screen after ${click.cartShown.toFixed(1)} ms.`);

• Line 2 holds three times from the trace.
• It prints Cart: 1 was written after 4.8 ms., then The click's handlers ran for 210.1 ms. and Cart: 1 reached the screen after 252.8 ms.

The badge's text changed at 4.8 ms. But changing the page isn't the same as showing it. The browser shows changes only when it draws a frame. And it draws frames between tasks, never in the middle of one.

A task is one piece of work that runs from start to end, as lesson 27.1 showed. Tasks run on the main thread. That's the one thread that runs the page's JavaScript and draws its frames.

Ravi's whole handler was one task. So the frame waited for all four jobs: 210.1 ms. Then Chrome needed about 38 ms more to put the frame on the screen. Chrome timed the whole click at 250.8 ms. That's over 200 ms, the limit for a good INP. INP, or Interaction to Next Paint, is the measure from lesson 26.1: roughly a visit's slowest click, tap or key press. Why it matters: one slow job in a handler holds back every change the handler makes.

Yield right after the change

web.dev's advice for event handlers starts simply: do as little work in them as you can. Then it names a better place to yield. In its words, yield "immediately after an event callback that updates the user interface so rendering logic can run sooner." Rendering is drawing the page. To yield is to stop for a moment, so the browser can do something else. Lesson 27.2 showed how scheduler.yield() does it. Here is the second page's handler:

1teas.addEventListener("click", async function addToCart(event) {2  if (!event.target.matches(".add")) return;3  const tea = event.target.closest("li").dataset.name;4  cart.push(tea);5  showBadge();6  await scheduler.yield();7  showSuggestions(tea);8  saveCart();9  sendAnalytics(tea);10});

• Line 1 now says async, so the function can pause with await.
• Line 5 changes the badge, as before.
• Line 6 yields. The rest of the function waits for a new task.
• Lines 7 to 9 do the other three jobs, in that new task.

Here are both clicks, side by side:

1// In ms after Asha's click, on her phone.2const pages = [3  { name: "All at once", interaction: 250.8, cartShown: 252.8, suggestionsShown: 252.8 },4  { name: "Then yield", interaction: 43.9, cartShown: 46.0, suggestionsShown: 257.3 },5];6for (const page of pages) {7  console.log(`${page.name}: the click took ${page.interaction.toFixed(1)} ms. Cart: 1 at ${page.cartShown.toFixed(1)}, suggestions at ${page.suggestionsShown.toFixed(1)}.`);8}

• Lines 3 and 4 hold each page's click.
• Line 7 prints All at once: the click took 250.8 ms. Cart: 1 at 252.8, suggestions at 252.8. and Then yield: the click took 43.9 ms. Cart: 1 at 46.0, suggestions at 257.3.

Cart: 1 came 206.8 ms sooner. Chrome timed the click at 43.9 ms, well under 200. Yet the suggestions came no sooner. They still waited for saving and analytics, in the same task. The next section fixes that. Why it matters: one line made the click's answer come more than five times sooner.

Why the frame went first

After a yield, the browser picks what to run next. Lesson 27.2 found that scheduler.yield() usually lets your next piece go ahead of other tasks. So why did the frame win here? Chrome's scheduler treats the frame after a click as urgent. A comment in its source code says: "The user is waiting for the result of a discrete input event, e.g. clicks or typing. The next frame is prioritized at highest priority (matching input)."

A discrete input is a single event, like a click or a key press. A scroll is the other kind: a stream of events. The trace agrees with the comment. The three jobs started 43.5 ms after the click, right after the main thread finished the badge's frame. Here is the main thread on all four pages:

Read each row from left to right. On the first page, the jobs start at once and the frame waits. On the other three, the badge gets its frame first. Why it matters: in Chrome, a yield right after the change is enough to get it on the screen.

When there's no scheduler.yield()

Safari has no scheduler.yield(). Lesson 27.3 let a frame through another way, with requestAnimationFrame and setTimeout. web.dev's own example uses the same trick:

1const afterNextFrame = () => new Promise((resolve) => requestAnimationFrame(() => setTimeout(resolve, 0)));2const yieldToFrame = () => (globalThis.scheduler?.yield ? scheduler.yield() : afterNextFrame());

• Line 1 is afterNextFrame from lesson 27.3. requestAnimationFrame runs its callback just before the next frame. The timer set there starts a new task after that frame.
• Line 2 uses scheduler.yield() where the browser has it, and afterNextFrame() where it doesn't.

The course's third page used line 1. It awaited afterNextFrame() where the second page yielded. Chrome timed its click at 44.1 ms, and Cart: 1 came after 46.2 ms. Why it matters: every browser can show the change first.

Look at the diagram once more. After the yield, the three jobs still ran as one long task of 208.3 ms. A second click in that time would wait. Lesson 27.3 showed how to cut such work into short pieces. Pick a page below to see when each job ran:

Saving and analytics can wait for a quiet moment

On the yield page, the suggestions came after 257.3 ms. Asha can see them. But they waited behind saving and analytics, which she can't. So the fourth page sorts the jobs by who is waiting for them:

1const whenIdle = (job) => requestIdleCallback(job, { timeout: 1000 });2teas.addEventListener("click", async function addToCart(event) {3  if (!event.target.matches(".add")) return;4  const tea = event.target.closest("li").dataset.name;5  cart.push(tea);6  showBadge();7  whenIdle(saveCart);8  whenIdle(() => sendAnalytics(tea));9  await scheduler.yield();10  showSuggestions(tea);11});

• Line 1 makes whenIdle. It asks the browser to run a job in an idle period: a stretch when the main thread has nothing else to do. Lesson 27.2 met requestIdleCallback(). The timeout says: if no idle period comes within 1 second, run the job anyway.
• Line 6 changes the badge.
• Lines 7 and 8 ask for saveCart and sendAnalytics in idle time. They don't run yet.
• Line 9 yields, so the badge's frame can be drawn.
• Line 10 shows the suggestions, in the next task.

1// The screen-first click, in ms after Asha's click.2const times = { suggestionsShown: 115.9, saveStarted: 113.0, saveRan: 42.4, analyticsStarted: 157.4, analyticsRan: 98.8 };3console.log(`The suggestions reached the screen after ${times.suggestionsShown.toFixed(1)} ms.`);4console.log(`saveCart started at ${times.saveStarted.toFixed(1)} ms and ran ${times.saveRan.toFixed(1)} ms.`);5console.log(`sendAnalytics started at ${times.analyticsStarted.toFixed(1)} ms and ran ${times.analyticsRan.toFixed(1)} ms.`);

• Line 2 holds five times from the trace.
• It prints The suggestions reached the screen after 115.9 ms., then saveCart started at 113.0 ms and ran 42.4 ms. and sendAnalytics started at 157.4 ms and ran 98.8 ms.

The suggestions came 141.4 ms sooner than on the yield page. The two quiet jobs ran right after them. saveCart started just before the frame reached the screen. That's because the main thread had already done its part of that frame. The idle callback standard says idle time comes after "rendering and compositing for a given frame has been completed". Why it matters: work Asha can't see now fills the gaps she doesn't notice.

localStorage blocks while it writes

Why move saving at all? Because localStorage is synchronous: the next line of code waits until the write is done. MDN says the work is done "synchronously, blocking the execution of other JavaScript code until the operation is completed." web.dev puts it more strongly: "LocalStorage should be avoided because it is synchronous and will block the main thread."

The course timed writes of three sizes on Asha's phone:

1// One localStorage.setItem() call on Asha's phone, on average, in ms.2const writes = [3  { size: "1 KB", ms: 0.0 },4  { size: "100 KB", ms: 0.4 },5  { size: "1 MB", ms: 5.2 },6];7for (const write of writes) {8  console.log(`${write.size}: ${write.ms < 0.1 ? "under 0.1" : write.ms.toFixed(1)} ms`);9}

• Lines 3 to 5 hold the average time of one setItem() call. The texts were 1,024 letters, 102,400 letters, and about a million letters long.
• It prints 1 KB: under 0.1 ms, 100 KB: 0.4 ms and 1 MB: 5.2 ms.

A small cart costs almost nothing. On Ravi's pages, the write itself took 1.4 ms or less. The stand-in work made saveCart slow. But a big write blocks the page, and it grows with the size. Why it matters: keep what you store small, and write it when the page is quiet. For bigger data, MDN points to IndexedDB, another store in the browser, which doesn't block. Try writes in your own browser:

1const text = "x".repeat(size);2const start = performance.now();3localStorage.setItem("cf-storage-lab", text);4const took = performance.now() - start;

Analytics, without the wait

navigator.sendBeacon() doesn't wait for the server. MDN says it "asynchronously sends an HTTP POST request containing a small amount of data". It's made for analytics. On Asha's phone, a call took 0.4 ms on average. So the slow part of analytics is the code that builds the report. Here, that's the stand-in work.

Waiting for quiet time has one risk. If Asha closes the tab first, the work might never run. MDN's advice for analytics is to send it when the page is hidden, on the visibilitychange event. The cart deserves the same care:

1document.addEventListener("visibilitychange", () => {2  if (document.visibilityState === "hidden") saveCart();3});

• Line 1 listens for visibilitychange. It fires when the page is hidden or shown again, for example when Asha switches tabs.
• Line 2 saves the cart if the page is now hidden.

Lesson 27.3's IdleQueue does this for you, with ensureTasksRun. Why it matters: quiet work still has to happen. It just doesn't go first.

Passive listeners let the page scroll

Ravi wants to know how far people scroll down the tea list. So he adds track.js. It listens for the wheel event. A mouse wheel or a trackpad fires it when you scroll.

1let scrolled = 0;2function noteScroll(event) {3  work(23_000_000); // works out which teas Asha scrolled past4  scrolled += event.deltaY;5}6teas.addEventListener("wheel", noteScroll);

• Lines 2 to 5 are noteScroll. Line 3 stands in for slow tracking code: 23 million steps, about 100 ms on Asha's phone.
• Line 6 adds it as a wheel listener on the tea list.

Asha turns her mouse wheel over the list. Nothing moves for a tenth of a second. Then the list jumps. Why would a listener that only takes notes hold the scroll back?

A wheel event has a default action: the thing the browser does unless a listener stops it. Here, that's scrolling. A listener can stop it with event.preventDefault(). A map might do that, to zoom instead. The browser can't know if this listener will. MDN says the browser "is in general unable to start the default action until the event listener has finished".

That promise is called passive. The DOM standard, which defines events, says passive "indicates that the callback will not cancel the event by invoking preventDefault()". Here are the lines on the two other scroll pages:

teas.addEventListener("wheel", noteScroll, { passive: true });
window.addEventListener("wheel", noteScroll);

• Line 1 adds the same listener to the list, marked passive.
• Line 2 adds it to the window, with no options at all.

1// In ms after the wheel reached the page, on Asha's phone.2const pages = [3  { name: "On the list", moved: 118.9, listenerRan: 103.1 },4  { name: "Passive", moved: 3.7, listenerRan: 103.3 },5  { name: "On the window", moved: 3.6, listenerRan: 104.2 },6];7for (const page of pages) {8  console.log(`${page.name}: the list moved after ${page.moved.toFixed(1)} ms. The listener ran ${page.listenerRan.toFixed(1)} ms.`);9}

• Lines 3 to 5 hold each page's times. moved is when the first frame showed the list moved, counted from when the wheel reached the page. listenerRan is how long noteScroll ran.
• It prints On the list: the list moved after 118.9 ms. The listener ran 103.1 ms., then Passive: the list moved after 3.7 ms. The listener ran 103.3 ms. and On the window: the list moved after 3.6 ms. The listener ran 104.2 ms.

On the list, the scroll waited for the whole listener. Passive, the list moved in the very next frame. The listener still ran for 103.3 ms, but nobody waited for it. Why it matters: a passive listener can be slow without making scrolling slow. It still keeps the main thread busy, so keep it light.

Why the window's listener didn't block

Line 2 didn't say passive, yet it acted like line 1. Many sites added these listeners to the whole page and never stopped a scroll. So browsers changed the default, and the DOM standard now says it. For touchstart, touchmove, wheel and mousewheel listeners on the window, the document, the html element or the body, passive is true unless you say otherwise.

Chrome did this for touch events in Chrome 56, and for wheel events in Chrome 73. Safari doesn't do it for wheel events. So write { passive: true } yourself.

The events were different inside, too. On the list, event.cancelable was true. On the passive pages, it was false. When every listener is passive, the DOM standard lets the browser start scrolling at once. It marks the event as one that can't be cancelled. What if a passive listener tries anyway?

1const list = new EventTarget();2list.addEventListener("wheel", (event) => {3  event.preventDefault();4  console.log("Stopped by a passive listener?", event.defaultPrevented);5}, { passive: true });6list.dispatchEvent(new Event("wheel", { cancelable: true }));

• Line 1 makes an EventTarget: any object that can have listeners. Every element on a page is one.
• Lines 2 to 5 add a passive wheel listener. Line 3 calls preventDefault().
• Line 6 fires a wheel event that could be cancelled.
• Line 4 prints Stopped by a passive listener? false.

The DOM standard says preventDefault() does nothing in a passive listener. Chrome may also print a warning in the console. To really stop a scroll, write { passive: false }. For touch, Chrome's team also points to the CSS touch-action property. The plain scroll event can't be cancelled at all, so passive doesn't matter for it.

How the wheel was recorded

The course turned the wheel through Chrome's DevTools protocol. DevTools holds a wheel event until the page has drawn a frame, and only then passes it on. Its source code says this is so that "newly added event listeners on the main thread" see it. A real mouse isn't held. Here the page was quiet, so the hold took 2.0 ms or less. The times above start when the wheel reached the page, after the hold.

Scrolling isn't part of INP, as lesson 26.1 showed. But a list that sticks still feels slow. Try it here:

1box.addEventListener("wheel", () => {2  busyFor(60); // a slow listener3  wheels += 1;4}, { passive });

Search when Asha stops typing

The tea list has a search box. Ravi's search.js searches the whole shop on every key press:

1function search(words) {2  work(35_000_000); // looks through the whole shop3  let found = 0;4  for (const row of teas.children) {5    row.hidden = !row.dataset.name.toLowerCase().includes(words);6    if (!row.hidden) found += 1;7  }8  document.querySelector("#about").textContent = "Teas found: " + found;9}10box.addEventListener("input", () => search(box.value.toLowerCase()));

• Lines 1 to 9 are search(). Line 2 stands in for searching the whole shop: 35 million steps, about 150 ms on Asha's phone.
• Lines 4 to 7 hide the teas that don't match, and count the rest. Line 8 shows how many were found.
• Line 10 runs search() on every input event. That event fires each time the box's text changes.

Asha types mint, a key every 120 ms. Here is each key press:

1// Asha types "mint". In ms, from her first key press.2const keys = [3  { key: "m", pressed: 0.0, waited: 1.2, took: 320.7 },4  { key: "i", pressed: 118.0, waited: 44.2, took: 442.9 },5  { key: "n", pressed: 238.3, waited: 78.4, took: 384.4 },6  { key: "t", pressed: 358.7, waited: 109.8, took: 264.0 },7];8for (const key of keys) {9  console.log(`${key.key}: waited ${key.waited.toFixed(1)} ms, took ${key.took.toFixed(1)} ms`);10}

• Lines 3 to 6 hold her key presses. waited is how long a key waited before its handlers could start. took is the key press's time as INP counts it, up to the next frame.
• It prints m: waited 1.2 ms, took 320.7 ms and i: waited 44.2 ms, took 442.9 ms. Then it prints n: waited 78.4 ms, took 384.4 ms and t: waited 109.8 ms, took 264.0 ms.

Each search took about 150 ms, but a new key came every 120 ms. So each key waited for the searches before it, and the waits grew. The slowest key press took 442.9 ms. That one key press would be her INP. Why it matters: a handler that runs on every key press must be quick, or the keys pile up.

The fix is to debounce the search: wait until the typing stops, then search once. The JavaScript lesson Debounce & throttle builds debounce step by step. The system design lesson Debounce and throttle plans whole search boxes with it. Here is a small one, on the second search page:

1const debounce = (fn, wait) => {2  let timer;3  return (...args) => {4    clearTimeout(timer);5    timer = setTimeout(() => fn(...args), wait);6  };7};8const searchSoon = debounce(search, 250);9box.addEventListener("input", () => searchSoon(box.value.toLowerCase()));

• Lines 1 to 7 are debounce(). Line 4 cancels the last timer, and line 5 starts a new one. So fn runs only after wait ms with no new call.
• Line 8 makes searchSoon, which searches 250 ms after the last call.
• Line 9 calls it on every input event.

1// Asha types "mint". In ms, from her first key press.2const pages = [3  { name: "Every key", slowestKey: 442.9, searches: 4, resultsShown: 624.9 },4  { name: "Debounced", slowestKey: 10.6, searches: 1, resultsShown: 773.2 },5];6for (const page of pages) {7  const runs = page.searches === 1 ? "1 search" : page.searches + " searches";8  console.log(`${page.name}: slowest key ${page.slowestKey.toFixed(1)} ms, ${runs}, results at ${page.resultsShown.toFixed(1)} ms`);9}

• Lines 3 and 4 hold both pages: the slowest key press, how many searches ran, and when the result for mint reached the screen.
• It prints Every key: slowest key 442.9 ms, 4 searches, results at 624.9 ms and Debounced: slowest key 10.6 ms, 1 search, results at 773.2 ms.

Here is what Asha saw on each page:

Searching on every key, her screen showed nothing new for 322.7 ms. Then the box jumped from empty to mi. Debounced, the m showed after 12.9 ms, and every key press took 10.6 ms or less. The search ran once instead of four times.

But look at the last number. The result came 148.3 ms later than before. It waited 250 ms of quiet first. Why it matters: debouncing keeps typing smooth and saves work. Pick a wait a little longer than the gap between key presses.

Scrolls and drags: once per frame

Some events fire many times a second, like scroll and pointermove. There, you want updates while they happen, not only after. web.dev's article Debounce your input handlers gives the rule: keep the handler short, then "store event values and deal with style changes in the next requestAnimationFrame callback." The JavaScript lesson calls this a requestAnimationFrame throttle. It does the work at most once per frame, with the newest value.

Now try a slow search in your own browser. Type at your normal speed, then switch to Debounced:

1const search = () => { busyFor(120); filter(box.value); };2const searchSoon = debounce(search, 250);3box.addEventListener("input", debounced ? searchSoon : search);

Before the frame, after it, or when quiet?

Every job in an event handler fits one of three times. Here are this lesson's four fixes. Read each row as one fix: what it changes, and what the recording showed.

Now sort these jobs from a real shop. When should each one run?

Common mix-ups

• "Yielding makes the work faster." No. After the yield, the three jobs still ran as one task of 208.3 ms. Yielding changed what Asha saw first, not how long the work took.
• "If the click's INP is good, the work is done." No. INP stops at the next frame. On the yield page, the jobs ran on after it, and a second click would have waited.
• "localStorage writes in the background." No. It's synchronous. A 1 MB write blocked Asha's phone for 5.2 ms on average.
• "A passive listener doesn't run." No. It runs as usual. It just can't stop the scroll. The passive listener still ran for 103.3 ms.
• "Every wheel listener holds the scroll back." No. In Chrome and Firefox, wheel listeners on the window, the document and the body are passive by default. The window's listener let the list move after 3.6 ms.
• "Debouncing makes the results come sooner." No. They came 148.3 ms later. Debouncing keeps typing smooth, and runs the search once.

Practice exercises

Answer first, then use the hints.

// The DOM standard's rule for passive, when the code doesn't say.
const roots = ["window", "document", "html", "body"];
const types = ["touchstart", "touchmove", "wheel", "mousewheel"];
const passiveByDefault = (type, target) => types.includes(type) && roots.includes(target);
console.log(passiveByDefault("wheel", "body"), passiveByDefault("wheel", "#teas"), passiveByDefault("click", "window"));

// Key presses, in ms. A debounced search runs when the gap after a key is at least the wait.
const keys = [0, 120, 240, 360, 900, 1020];
const wait = 250;
let searches = 0;
keys.forEach((at, i) => {
  const next = keys[i + 1];
  if (next === undefined || next - at >= wait) searches += 1;
});
console.log("Searches:", searches);

Check your understanding

For each question, ask who is waiting for the work: Asha, or nobody yet.

Key takeaways

• A handler's changes show only in the next frame, and the frame waits for the whole task.
• Change what the visitor is waiting for first, then yield, so a frame can show it.
• In Chrome, the frame after a click or key press goes first. Elsewhere, wait for a frame with requestAnimationFrame and setTimeout.
• Run saving and analytics in idle time, with a timeout, and finish them when the page is hidden.
• localStorage is synchronous, so keep writes small. sendBeacon() sends without waiting.
• Mark touch and wheel listeners passive unless they stop the scroll. Safari doesn't make wheel listeners passive by default.
• Debounce slow work that runs on every key press. For scrolls and drags, do the work once per frame.

Sources

The facts on this page come from these specs, docs and source files:

• Optimize Interaction to Next Paint, web.dev.
• Optimize long tasks, web.dev.
• main_thread_scheduler_impl.h, Chromium, Chromium on GitHub.
• Window: requestIdleCallback() method, MDN.
• Cooperative Scheduling of Background Tasks (requestIdleCallback), W3C.
• Web Storage API, MDN.
• Storage for the web, web.dev.
• Navigator: sendBeacon() method, MDN.
• EventTarget: addEventListener() method, MDN.
• DOM Standard: Interface EventTarget, WHATWG.
• Making touch scrolling fast by default, Chrome for Developers.
• Making wheel scrolling fast by default, Chrome for Developers.
• input_handler.cc, Chromium, Chromium on GitHub.
• Debounce your input handlers, web.dev.

Coming next: Reducing presentation delay. After the handlers, the browser still has to draw the frame. The next lesson makes that part smaller.