Node.js event loop: phases, nextTick, and loop lag

Your Node service handles 1000 req/s fine in staging. In production it occasionally spikes to 500 ms tail latency. DevTools is useless — Node has no frames, no INP. You need the equivalent diagnostic for a headless loop: event-loop lag.

Node’s libuv loop: six phases

Node’s libuv-driven loop runs through six phases per iteration:

Between every phase, two queues drain: the process.nextTick queue (Node-specific, fires before microtasks) and the standard microtask queue (Promise.then, queueMicrotask).

process.nextTick — highest-priority callback in Node

process.nextTick is the highest-priority callback short of synchronous code. It fires before microtasks — before Promise.then. Misuse causes the same starvation pattern as runaway microtasks in the browser, but at one priority level higher:

function tick() {
  process.nextTick(tick); // starvation at nextTick level
}
tick(); // I/O callbacks, setImmediate, timers never run

If you need “run after this synchronous block,” prefer queueMicrotask or Promise.resolve().then in Node — they have correct priority relative to I/O.

setImmediate vs setTimeout(0) in Node

Despite the names, setImmediate does not run immediately and setTimeout(0) does not run at zero delay.

• setImmediate runs in the check phase (after I/O for this iteration).
• setTimeout(0) runs in the timers phase of the next iteration.

Inside an I/O callback (file read, socket read), setImmediate always wins — it fires this iteration’s check phase before the next iteration’s timers phase. Outside I/O callbacks, the order is non-deterministic by spec. Code that relies on either ordering between the two is brittle; if you need a guaranteed ordering, use queueMicrotask (always before either) or stack them with explicit dependencies.

Why blocking the Node loop matters

Node has no concept of frames or input — but it is single-threaded just like the browser. A 500 ms JSON.parse on a request handler blocks every other request on the same process for 500 ms. There is no rendering safety net. Mitigation:

• Offload CPU-bound work to a Worker thread (node:worker_threads).
• Keep request handlers async-first.
• Use streaming parsers (JSONStream, oboe.js) for large payloads.

The same “shorter tasks” discipline that fixes browser INP fixes Node tail latency.

Measuring event-loop lag in Node

The browser has INP and LoAF. Node has event-loop lag — the equivalent diagnostic for a headless loop. The idea: schedule a timer for T ms and measure how late it actually fired; the excess over T is time the loop was blocked by synchronous work.

perf_hooks.monitorEventLoopDelay() gives a histogram of this lag with percentiles. A healthy process holds p99 lag in single-digit ms; p99 in hundreds of ms means some handler regularly monopolises the thread, and every request that hits that window gets tail latency.

const { monitorEventLoopDelay } = require('perf_hooks');
const h = monitorEventLoopDelay({ resolution: 10 });
h.enable();
// … later:
console.log(`p99 lag: ${h.percentile(99)}ms`);

This is the same measurement as INP in the browser — “how long did one task hold the only execution thread” — just expressed as lag instead of interaction delay.