A browser routine splits a long job into chunks and yields between them with `await new Promise(r => setTimeout(r, 0))`. Why can the remaining chunks be delayed by unrelated work, and what does scheduler.yield() change?

## The two costs of yielding Breaking a long job into chunks that hand the thread back is the standard way to keep a page responsive while doing a lot of work. But every yield has two costs, and engineers usually only account for the first. The obvious cost is **overhead** — each resumption is a fresh trip through the event loop. The subtle cost is **losing your place**. Task queues are first-in-first-out per task source, and the browser picks among sources. When you yield with `setTimeout(resolve, 0)`, your continuation joins the timer queue *behind* everything queued while your chunk was executing. On a quiet page that is nothing. On a live dashboard with sockets, timers, and observer callbacks, each of your chunks is separated from the next by an arbitrary amount of unrelated work. Total wall-clock time for the job becomes unbounded, even though its total CPU cost never changed — and that is the failure mode people misdiagnose as "chunking made it slower". ## Why the platform needed a new primitive Nothing in the older primitives fixes this. `setTimeout(0)` is back-of-queue by construction. `requestIdleCallback` is worse for a job the user is waiting on — it runs only in leftover time and can be starved indefinitely. `queueMicrotask` and `await Promise.resolve()` sit at the other extreme: they do not end the task at all, so they never let the browser handle input or paint. There was no way to say "pause, let the browser breathe, then give me the thread back before you start new work". ## scheduler.yield() ```js for (const chunk of chunks) { process(chunk); await scheduler.yield(); } ``` `scheduler.yield()` returns a promise. Awaiting it ends the current task, so the browser can run input handlers and rendering steps — the whole point of yielding. What differs is the resumption: the continuation is scheduled as a *continuation* of the yielding task, at the priority that task was running at, and it takes precedence over same-priority tasks that were enqueued while you were away. Your chunks stay close together, but a click in between is still serviced. This composes with `scheduler.postTask`: yield inside a task posted at `'background'` and you resume at background priority, so a genuinely deferrable job stays deferrable. Inheriting priority is what stops `yield()` from becoming a way to jump the queue. ## Availability and the fallback `scheduler.yield()` shipped in Chrome 129 and is not yet in every engine as of 2026, so production code detects it: ```js const yieldToBrowser = () => 'scheduler' in globalThis && 'yield' in globalThis.scheduler ? globalThis.scheduler.yield() : new Promise((resolve) => setTimeout(resolve, 0)); ``` The fallback is honest about what it gives up — back-of-queue resumption — while keeping the call sites identical, so the day support is universal you delete one branch. ## Yield on a schedule, not per item Orthogonal to which primitive you use: yield on a *time budget*, not on a fixed item count. Check elapsed time with `performance.now()` and yield once you have held the thread for something on the order of 50 ms. That keeps each task short enough not to delay input while amortising the yield overhead across many items — and it adapts automatically to slow devices, where a fixed item count is either far too long or wastefully short. Chromium additionally exposes `navigator.scheduling.isInputPending()`, which lets a loop yield only when input is actually waiting. It is Chromium-only and easy to misuse — pending input is not the only reason to yield, since rendering matters too — so treat it as a refinement on top of the time budget, never as the whole policy. ## What to say in an interview Name the mechanism: FIFO task queues mean a timer-based yield resumes behind whatever arrived while you ran; `scheduler.yield()` resumes as a prioritised continuation instead. Then add the two engineering caveats — inherit priority so deferrable work stays deferrable, and yield on a time budget rather than per item — and note the feature detection. Someone who has actually shipped this mentions the fallback without being asked.