The frame and the event loop.

On Copperpot's product page for the 24 cm enamel casserole, a shopper taps the Teal swatch. The click handler was written to be helpful. First it marks Teal as chosen and sets the stock line to "Checking stock…". Then it rebuilds the "Pairs well with" row of matching lids and trivets for the new colour, which takes 84 ms of JavaScript on this phone. Finally it looks Teal up in the variant data the page already holds and writes "In stock, delivered Thursday".

The shopper never sees "Checking stock…". For about a tenth of a second the old Cream page stays on screen with no sign that the tap landed, and then Teal, the new row and the final stock line all appear together. The label was in the DOM for 86 ms, yet no frame was ever drawn while it was there.

That is the event loop at work. The page's main thread runs one piece of work, a task, from start to finish without interruption. The tap's handler is one task. Drawing a frame (running style, layout and paint and handing the result to the screen) is something the loop does between tasks, when the display is ready for a new picture, roughly every 16.7 ms on a 60 Hz screen. A task that is still running cannot be paused for a frame, so the frame waits, and when it is finally drawn it shows the DOM as the task left it. Intermediate values are simply overwritten.

Everything in this topic follows from that one rule: when the frame comes, what runs just before it (requestAnimationFrame), what squeezes in ahead of it (microtasks), what has no idea it exists (timers), and how to arrange work so the shopper sees the right thing at the right moment.

A window's event loop owns several task queues. A task is a self-contained piece of work queued by some source: dispatching a click, running a timer callback, delivering a network response, parsing a chunk of HTML, posting a message. Each turn, the loop picks one queue, takes the oldest runnable task from it and runs it to completion. Which queue it picks is left to the browser, which is how browsers can favour input: the standard's own example gives keyboard and mouse tasks preference three times out of four, while tasks from any single source always keep their order.

When the task returns, the loop performs a microtask checkpoint. The microtask queue is separate and is not a task queue: promise reactions, queueMicrotask callbacks and MutationObserver deliveries go there. The checkpoint runs microtasks until the queue is empty, including any that the running microtasks add. Only then can anything else happen.

Rendering is woven in on its own clock. In parallel with the loop, the browser waits for a rendering opportunity, the moment its display can take a new picture, and queues a task to update the rendering. That task waits its turn like any other, so a long task in front of it delays the frame, and it is skipped for documents that are hidden or have nothing new to draw and no animation frame callbacks waiting.

The task that updates the rendering is a fixed list, run for every visible document that has something to show. The order matters, because each step can change what the later ones see. Events tied to the screen, such as resize and scroll, are not fired the instant the window changes size or the page moves; they are fired here, at most once per frame, which is why a scroll listener never runs more often than frames are drawn.

Two consequences follow. First, requestAnimationFrame is the last place where script can change the page and have the change appear in this very frame without paying for a second layout: style and layout run right after it. Second, a write is cheap at the moment it happens. Setting a class or a style does not recompute anything; the engine only marks the affected elements dirty (style needs recalculating, layout needs redoing, a region needs repainting) and step 8 and paint later redo just the dirty parts, once, for every write since the last frame. That is why ten writes in one task cost about the same as one at frame time.

The marks can be cashed early. If script reads geometry such as offsetHeight or getBoundingClientRect() while layout is dirty, the browser must run style and layout on the spot to answer: a forced synchronous layout. Doing that read-after-write inside a loop repeats layout many times in one frame, the pattern the layout-thrashing topic owns along with its fixes. How much the next frame must redo depends on what was written, as the table shows; the layers and compositing topic explains when a transform or opacity change skips the main thread altogether.

The display decides the beat. A 60 Hz screen takes a new picture every 16.7 ms; a 120 Hz screen every 8.3 ms. The browser lines its rendering opportunities up with that signal (usually called vsync) and may lower the rate for a page that cannot keep up, for a cross-origin frame that is out of view, or for a hidden tab, where the standard allows a few frames a second or none at all.

Inside one interval, everything the page does has to fit: the tasks that happen to run, the rAF callbacks, style, layout and paint, plus the browser's own work to get the frame to the screen. web.dev's rule of thumb at 60 Hz is about 10 ms for the page out of the 16.7 ms. On a 120 Hz screen the same proportion leaves about 5 ms, so code that was smooth on a 60 Hz test phone can miss every other frame on a newer one.

Copperpot's basket drawer has a free-delivery meter: "£11 to go" fills towards a £75 threshold when something is added. The fill is driven by script, a scaleX on the bar recomputed each step. The first version used setTimeout with a 16 ms delay, because 16 ms is about a frame. That reasoning has two holes. A timer is a task on its own clock: it fires at least 16 ms after it was set, later if the thread is busy, and it knows nothing about when the next frame is drawn. And not every screen is 60 Hz.

requestAnimationFrame asks for the one thing a visual update wants: run this just before the next frame is drawn. Its callbacks run inside the rendering steps, once per frame, at whatever rate the screen refreshes, and they all receive the same timestamp, the frame's time. Browsers pause them in background tabs and hidden iframes, which saves battery but means a rAF loop must never be the clock for anything that has to keep time.

A promise callback does not run when the promise settles; it is queued as a microtask, and microtasks run at the next checkpoint, which comes as soon as the current task or callback returns. That makes them the fastest way to defer something, faster than any timer and always ahead of the next frame. It also means a chain of awaits that never touches the network or a timer completes inside a single turn, with no frame in between, however many steps it has.

Copperpot's real stock check goes to the server. The request runs in parallel, off the main thread; when the response arrives, a task is queued to settle the fetch's promise, and the then callbacks run as microtasks right after that task. Whatever they write is painted at the next frame together with anything else written before it.

The fix for the Teal tap is not to make the label appear sooner by force; there is no API that paints in the middle of a task. It is to end the task once the feedback is written and continue the heavy part in a task that is guaranteed to start after the next frame. A requestAnimationFrame callback runs just before that frame is painted; a zero-delay timer set from inside it becomes a task that cannot run until the rendering update has finished. Together they mean "after the next paint".

This changes what the shopper feels, not how much work is done. The press ring and "Checking stock…" appear at the first frame, about 33 ms after the tap instead of 100 ms. The rebuild is still one 84 ms task, long enough to delay the next tap; breaking it into smaller pieces and yielding between them is the subject of the long-tasks topic, which also covers scheduler.yield() and how Interaction to Next Paint measures exactly this gap between an input and the frame that answers it.

Copperpot runs a weekend offer with an "Offer ends in 04:59" banner. A first version subtracted one sixtieth of a second on every animation frame. A shopper switches to a messaging app for 40 seconds and comes back to a banner that has lost only the 10 seconds it was visible for. Nothing was broken: hidden documents get no rendering updates, so animation frame callbacks stop, and timers in background tabs are throttled too (Chrome checks heavily throttled timers only once a minute after five minutes hidden). Anything that keeps time has to read a clock and use frames only to show the result.