Browser & Frontend Runtime
Event loop: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the loop’s timing model stick.
Reconstruct the unit’s core mechanisms — the five-step iteration, the microtask checkpoint, timer throttling, the starvation failure mode, the INP-to-LoAF pipeline, and Node’s reordering — without looking back at the lessons.
- 01Walk through one full iteration of the browser event loop, naming what runs and when each step is skipped.
- 02Why does await Promise.resolve() fail to 'yield to the browser' even though it suspends the calling function, and what actually yields?
- 03Name the three throttling layers that compound on setTimeout accuracy, and the one rule that ties them together.
- 04Describe the microtask-starvation failure mode, how it looks in DevTools, and one production scenario where it appears by accident.
- 05You see an INP regression in production. Walk through the LoAF-to-fix pipeline that turns the metric into a deployable change.
- 06How does Node's event loop reorder things relative to the browser, and what is the headless equivalent of INP?
If you could reconstruct each answer from memory, you hold the unit’s spine: one task runs to completion, then the microtask checkpoint drains fully before any frame, then rendering runs only on a frame boundary. Microtasks never yield to the renderer — only tasks do — which is why self-scheduling microtasks starve the page. Timers are lower bounds throttled by three compounding layers. INP measures the user-perceived cost, LoAF plus sourcemaps attribute it, and Node reruns the whole model with process.nextTick promoted above microtasks and event-loop lag standing in for INP.