Tasks, microtasks, and scheduler.yield()

You write await Promise.resolve() to “yield” inside a long loop. The browser still freezes. You try setTimeout(fn, 0). Now it flickers weirdly. The problem is not your code — it is not knowing which queue each primitive lands in.

The HTML spec model: task sources and task queues

The HTML standard (§ event loops) defines an event loop as a thread with a set of task queues. Each task is associated with a task source — the kind of work that produced it (DOM manipulation, user interaction, networking, history traversal). Each task source has its own queue, and the user agent picks one queue per iteration, dequeues the oldest task, and runs it to completion. There is no preemption. When the task ends, the agent runs the microtask checkpoint, then optionally the render step, then loops back.

Microtasks vs tasks: the decisive rule

A microtask is queued by: Promise.then, Promise.catch, Promise.finally, queueMicrotask, MutationObserver, and await (sugar over Promise.then).

A task is queued by: setTimeout, setInterval, MessageChannel.postMessage, network responses, dispatched DOM events, parsed HTML chunks.

The decisive operational rule: microtasks drain to empty between every task and every frame. If a microtask schedules another microtask, both run before the loop moves on. This is why Promise.resolve().then(self) in a tight chain hangs the page: the microtask queue is never empty, the loop never reaches step 4, and the browser never paints.

queueMicrotask vs Promise.resolve().then vs MessageChannel

Three ways to “schedule something soon,” each with different semantics:

• queueMicrotask(fn) — queues a microtask directly. Runs after the current task, before the next. No rendering between.
• Promise.resolve().then(fn) — identical timing to queueMicrotask, but allocates a Promise, a closure, and a chain entry. Slightly slower, otherwise identical. Does not yield to the renderer.
• new MessageChannel().port1.postMessage(...) — queues a task. Runs after the current task, after microtasks drain, possibly after a frame. Does yield to the renderer.

The pattern matters when you want to yield to rendering: microtasks do not; MessageChannel does. Modern code uses scheduler.yield() (Chrome 115+) for explicit yield points.

Where requestAnimationFrame fits

rAF callbacks run in step 4 of the loop, immediately before style/layout/paint. The browser only enters step 4 when it has decided a frame is due — typically every 16.67 ms at 60 Hz. If a long task missed several frame deadlines, the browser does not queue up multiple rAF callbacks; it runs the rAF set once. This is why a long task always shows as exactly one frame drop: rAF is driven by the render budget, not a timer.

Where input fits

Input events (mousemove, click, keydown, touchstart) are queued as tasks by the browser’s input thread (a separate OS thread). The main thread pulls them in step 1 like any other task. There is no preemption: if your JS task runs for 80 ms when a click arrives at the 20 ms mark, the click waits 60 ms before its handler can run. INP measures exactly this latency: when did the user click, when did the next paint reflect the result. INP < 200 ms p75 is “good.” Hitting that requires that no single task on the loop exceeds about 50 ms.

How a DOM event becomes a task

When the user clicks, the browser’s input thread records the hit-test target and queues a single task on the main thread’s user-interaction task source. When the main thread pulls that task, it runs the full event dispatch in one shot: capture phase down to the target, then the target itself, then bubble phase back up. Every matching listener along that path runs synchronously inside this one task — there is no yield point between them. This is why a slow listener on a high ancestor (a mousemove handler on document) taxes every descendant interaction. The passive: true listener option matters for scroll, wheel, and touch: it promises the listener will not call preventDefault(), letting the browser start compositor scrolling without waiting for the dispatch task to finish.

Yielding inside a long task

If you must do 200 ms of work, break it into ≤50 ms chunks separated by yield points so input can interleave. Three techniques:

1. setTimeout(fn, 0) — queues a task in ~4 ms (clamped); coarse but universal.
2. MessageChannel with postMessage — queues a task immediately, no clamping. This is what React 18 uses internally for time-slicing.
3. scheduler.yield() (Chrome 115+) — promises a yield point that allows input and rendering to run, then resumes the same logical task with priority. Modern recommendation: use scheduler.yield(), fall back to setTimeout(0). Do not use await Promise.resolve() to yield — it queues a microtask, which does not let the renderer run.