The JavaScript event loop: tasks, microtasks and rendering

HOW IT FITS TOGETHER

KEY TERMS

Call stack and run-to-completion

Each callback runs until it returns and the stack is empty; nothing interleaves with it. This is why shared state needs no locks within one thread, and also why any synchronous work blocks input, timers and rendering for its full duration.

Tasks (macrotasks)

Units of work the event loop picks one at a time: running a script, a timer callback, a dispatched input event, a network or message callback. The HTML spec has several task queues and lets the browser choose which to service, so ordering is only guaranteed within one source (two timers keep their order relative to each other).

Microtasks

Promise reactions (then/catch/finally), await continuations, queueMicrotask and MutationObserver callbacks. The queue is drained completely whenever the stack empties after a callback, and microtasks queued during the drain join the same drain. That is why they always beat setTimeout(fn, 0).

Rendering steps and requestAnimationFrame

Rendering is not a task you schedule; the browser takes a rendering opportunity between tasks, roughly once per display refresh. rAF callbacks run inside it, just before style and layout, which makes rAF the right place for visual updates. It is paused in background tabs and hidden iframes.

Long tasks and responsiveness

Any task over 50 ms is a long task. An input event that arrives during one waits until it ends, then waits for its own handler and the next paint; that total is what Interaction to Next Paint measures. The fix is to split work and yield between chunks, or move it off the main thread.

Yielding: setTimeout vs scheduler.yield()

Awaiting a promise does not yield to the browser: the continuation is a microtask. setTimeout(resolve, 0) does yield, but your continuation goes to the back of the task queue. scheduler.yield() yields and resumes in a prioritized continuation; it ships in Chromium (129+) and Firefox (142+) but not Safari, so feature-detect it.

Node.js in one paragraph

Node uses the same task/microtask split on top of libuv phases (timers, poll, check, close). It adds process.nextTick, a queue drained before promise microtasks in CommonJS, and setImmediate, which runs in the check phase. Phase details belong to the Node runtime explainer.

IN YOUR STACK

console.log("A");
setTimeout(() => console.log("B"), 0);
Promise.resolve().then(() => {
  console.log("C");
  queueMicrotask(() => console.log("C2")); // queued during the drain
});
queueMicrotask(() => console.log("D"));
(async () => {
  console.log("E"); // runs synchronously, up to the first await
  await null;       // continuation becomes a microtask
  console.log("F");
})();
console.log("G");

// A E G C D F C2 B

function yieldToMain() {
  if (globalThis.scheduler?.yield) return scheduler.yield();
  return new Promise((resolve) => setTimeout(resolve, 0)); // Safari fallback
}
async function processInChunks(items, handle, budgetMs = 10) {
  let deadline = performance.now() + budgetMs;
  for (const item of items) {
    handle(item);
    if (performance.now() >= deadline) {
      await yieldToMain(); // input, rendering and other tasks can run here
      deadline = performance.now() + budgetMs;
    }
  }
}
const list = document.querySelector("#list");
const status = document.querySelector("#status");
const rows = Array.from({ length: 50_000 }, (_, i) => `Row ${i}`);
const renderRow = (text) => list.append(Object.assign(document.createElement("li"), { textContent: text }));

document.querySelector("#load").addEventListener("click", async () => {
  status.textContent = "Loading…";
  await yieldToMain(); // let the feedback paint before the heavy work
  await processInChunks(rows, renderRow);
  status.textContent = "Done";
});

// What you write
async function loadUser(id) {
  const res = await fetch(`/api/users/${id}`);
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  return res.json();
}

// Roughly what it means: each await splits the function into a continuation
function loadUserThen(id) {
  return fetch(`/api/users/${id}`).then((res) => {
    if (!res.ok) throw new Error(`HTTP ${res.status}`); // becomes a rejection
    return res.json();
  });
}

// Either way, the caller keeps running first
loadUser(1).then((user) => console.log("user", user));
console.log("requested"); // logs before "user"

// Sequential awaits in a loop serialize independent requests
async function loadMany(ids) {
  return Promise.all(ids.map((id) => loadUser(id))); // concurrent, same thread
}

const box = document.querySelector("#box");
const DURATION_MS = 600;
let start;
let frameId = 0;

function step(now) {
  start ??= now;
  // Progress from elapsed time, not frame count: 60 Hz and 144 Hz screens agree.
  const t = Math.min((now - start) / DURATION_MS, 1);
  const eased = 1 - (1 - t) ** 3; // ease-out cubic
  box.style.transform = `translateX(${eased * 300}px)`; // write only, no layout reads
  if (t < 1) frameId = requestAnimationFrame(step); // rAF is one-shot
}

function play() {
  cancelAnimationFrame(frameId); // restart cleanly if already running
  start = undefined;
  frameId = requestAnimationFrame(step);
}

document.querySelector("#play").addEventListener("click", play);

// order.cjs (CommonJS)  run: node order.cjs
const fs = require("node:fs");

setTimeout(() => console.log("timeout"), 0);
setImmediate(() => console.log("immediate"));
Promise.resolve().then(() => console.log("promise"));
process.nextTick(() => console.log("nextTick"));
console.log("sync");
// sync, nextTick, promise, then timeout and immediate in either order

fs.readFile(__filename, () => {
  // Inside an I/O callback the order is deterministic:
  setTimeout(() => console.log("io: timeout"), 0);
  setImmediate(() => console.log("io: immediate")); // always first
});

WHERE IT BITES

• Starving the loop with microtasks: a promise chain or queueMicrotask that keeps re-queueing itself never lets a task or a frame through. The page freezes even though every step was async.
• Treating await as a yield. Awaiting resolved promises in a hot loop keeps the main thread busy just like synchronous code; only a task boundary (setTimeout, scheduler.yield, a message) lets input and rendering in.
• Assuming setTimeout(fn, 0) means now. It means after the current task, all microtasks, possibly a frame, and other queued tasks; nested timers are clamped to 4 ms and background tabs throttle to 1 s or more.
• Heavy synchronous work in event handlers (big JSON.parse, sorting, rendering thousands of rows). One 400 ms click handler is a 400 ms INP no matter how fast the network was.
• Driving logic from requestAnimationFrame. It pauses in hidden tabs, so timers, sync and analytics built on it silently stop.
• Interleaving DOM reads and writes inside one frame. Each read after a write forces layout, turning one frame into dozens of layout passes.

WHEN IT BREAKS IN PRODUCTION

• A long list loads and scrolls slowly

SOURCES

• WHATWG HTML: Event loops (opens in new tab)Checked 2026-10-11
• MDN: Using microtasks in JavaScript with queueMicrotask() (opens in new tab)Checked 2026-10-11
• MDN: JavaScript execution model (opens in new tab)Checked 2026-10-11
• MDN: Scheduler.yield() (opens in new tab)Checked 2026-10-11
• web.dev: Optimize long tasks (opens in new tab)Checked 2026-10-11
• Node.js: The event loop, timers, and process.nextTick() (opens in new tab)Checked 2026-10-11