Browser & Frontend Runtime
Event loop: multiple-choice review
Crux Multiple-choice synthesis across the event-loop unit — queue semantics, the render step, timer throttling, starvation, scheduler.yield, and the Node loop.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each one mirrors a call you make in a real performance incident — not a definition to recite, but which queue a primitive lands in, and what that costs the next frame.
Goal
Confirm you can connect queue semantics, the render step, timer throttling, starvation, and cross-runtime differences — the synthesis the individual lessons built toward.
Quiz
Completed
Inside a click handler you call setTimeout(t, 0) then queueMicrotask(m), then the handler returns. In what order do t and m run relative to the next paint?
Heads-up setTimeout(0) queues a task; the microtask checkpoint drains before the loop pulls another task. queueMicrotask always runs before any setTimeout callback queued in the same turn.
Heads-up Queue, not registration order, decides timing. m is a microtask (pre-render, immediate); t is a task (post-render, after the checkpoint and possibly a frame).
Heads-up Microtasks drain before the render step, not after it. m runs before any paint; only t waits for a later iteration.
Quiz
Completed
A click handler runs for 400 ms. Which of these keeps working during the block, and why?
Heads-up Microtasks still need the main thread. They queue behind the running task and cannot run until the 400 ms handler returns.
Heads-up Timers only queue a task; the callback still needs the blocked main thread. Backed-up interval callbacks burst when the thread frees.
Heads-up The input thread records the event but the handler runs on the main thread. The click queues and waits — the user sees a frozen UI.
Quiz
Completed
You must do 200 ms of work without freezing input. You try await Promise.resolve() between chunks and the page still locks up. Why, and what actually yields?
Heads-up Allocation cost is negligible here. The freeze is structural: microtasks drain before the render step, so no yield to input ever happens.
Heads-up It still suspends the function and resumes via the microtask queue — but a microtask, by definition, runs before any frame, so it does not yield to the renderer.
Heads-up rAF only runs on a frame boundary, so it is a poor general yield. setTimeout(0) and scheduler.yield() both queue tasks that let input and rendering interleave.
Quiz
Completed
A background tab runs setInterval(poll, 1000). After several minutes hidden, how often does the callback fire, and what compounds with this?
Heads-up setInterval is throttled exactly like setTimeout in hidden tabs. The 1 s minimum applies immediately, the 1 min minimum after a longer hidden period.
Heads-up The 4 ms nesting clamp applies to deep setTimeout/setInterval chains; in a hidden tab the much larger background throttle wins.
Heads-up Timers fire at a throttled rate, not zero. Full suspension only happens if the Page Lifecycle API freezes the tab — a stronger, later signal.
Quiz
Completed
A search input shows INP of 410 ms. The Long Tasks API logs a 312 ms task but only attributes it to 'same-origin'. What is the right next instrument and why?
Heads-up buffered:true only backfills entries from before the observer attached; it does not add script-level attribution. Long Tasks attribution stays at browsing-context granularity.
Heads-up Local repro often misses production payload size and device class. LoAF plus sourcemap resolution is the correct production attribution path.
Heads-up User Timing needs you to already know where to place marks. LoAF auto-attributes the heaviest script per slow frame without manual instrumentation.
Quiz
Completed
A library tested only in Node chains process.nextTick(a) then Promise.resolve().then(b) and relies on a running before b. Ported to the browser via a nextTick polyfill, the ordering flips. Why?
Heads-up All microtasks run on the main thread. The flip is about queue priority: Node's nextTick outranks microtasks; the polyfilled version does not.
Heads-up process.nextTick is Node-specific and not in ECMA-262. The spec only defines the microtask (jobs) queue, which is why the polyfill collapses to queueMicrotask.
Heads-up A correctness-minded polyfill uses queueMicrotask, not setTimeout — but either way the point stands: nextTick's pre-microtask priority does not exist in the browser.
Recap
The through-line across the unit is one decision: which queue does this primitive land in, and what does that cost the next frame. Microtasks (promise callbacks, queueMicrotask, MutationObserver) drain before rendering and starve it if they self-schedule; tasks (setTimeout, MessageChannel, input dispatch) yield to rendering but pay clamps and throttling; rAF runs only on a frame boundary. Diagnose user-perceived latency with INP, attribute it with LoAF plus sourcemaps, and remember that Node reorders all of this with process.nextTick sitting above microtasks.