The Event Loop, As The Browser Runs It

The event loop, which is defined by the HTML specification rather than by JavaScript, and which belongs to the browser rather than the engine. V8 executes; the loop schedules. The schedule is: pick a task, run it to completion, drain microtasks, maybe render, repeat.

The loop's rules produce an ordering that is deterministic for microtasks and only partly deterministic for tasks relative to frames. Knowing it lets you place work exactly.

the common mistake and the fix:

  // "let the UI update, then do heavy work"
  await Promise.resolve();          // microtask: UI does NOT update
  heavy();

  await new Promise(r => requestAnimationFrame(() => setTimeout(r)));
                              // after the next paint
  heavy();

  await scheduler.yield();          // a task boundary, prioritised continuation

The browser does not render after every task. It renders when it decides a frame is worth producing, which is tied to the display's refresh and to whether anything changed. Understanding that timing is what makes rAF the right tool and setTimeout the wrong one for visual work.

Input is a task source with priority, but it has a longer path than most people picture, and the compositor is in the middle of it.

Because INP measures from the tap to the next paint, and the handler is only the middle of that. If a 300 ms task was running when the tap landed, the handler waited 300 ms to start. If the handler's changes triggered a 60 ms layout, the paint waited for that. INP is the whole chain; the handler is one link.

INP, decomposed:

  input delay         time from the event's timestamp until its handler starts
                         = whatever task was already running, plus queued tasks ahead
  processing          all handlers for the interaction (pointerdown, pointerup, click)
  presentation delay  from the last handler's end to the frame that shows the result
                         = style + layout + paint of what the handlers changed

  good < 200 ms   needs improvement < 500 ms   poor beyond

the reported INP is near the worst interaction of the visit (98th percentile), not the average.

setTimeout, MessageChannel and requestIdleCallback were the tools for a decade. scheduler.postTask and scheduler.yield are the designed replacement: tasks with priorities the browser understands.

a pattern for a heavy interaction:

  button.onclick = async () => {
    button.disabled = true;             // visible now, this frame
    await scheduler.yield();            // let that paint
    for (const chunk of chunks(items, 200)) {
      render(chunk);
      await scheduler.yield();
    }
    scheduler.postTask(sendAnalytics, { priority: 'background' });
  };

the user sees the button respond in one frame; the work drains without blocking input; the analytics never compete.

Three observer APIs deliver information the browser already computes, batched at well-defined points in the loop, so you never have to poll or force layout.

Each worker has its own event loop on its own thread, which is why moving work there frees the main thread. Part 7 covers workers fully; here is the loop-level view.