Avoid Blocking the Node.js Event Loop with CPU-Heavy Work

A practical approach

Step 1

Measure first: watch request latency under load and use event-loop delay monitoring, such as perf_hooks.monitorEventLoopDelay, to detect blocking.

Step 2

Profile slow endpoints with the built-in --cpu-prof flag or your APM tool to find the synchronous functions consuming time.

Step 3

Replace synchronous APIs such as fs.readFileSync, zlib's sync functions and crypto's sync hashing with their asynchronous versions in request handlers.

Step 4

Move genuinely CPU-heavy work to worker_threads or a separate background job processor, and return a job ID for long tasks.

Step 5

Limit input sizes, such as maximum upload or JSON body size, so a single request cannot trigger unbounded work.

Worked example

A certificate service generated PDF files synchronously inside the HTTP handler. When a batch of 200 learners claimed certificates after a webinar, health checks timed out and the platform restarted the service repeatedly. Moving generation to a queue processed by a worker, and returning a status URL immediately, kept the API responsive and let certificates complete steadily in the background.

A mistake to avoid

Do not try to fix CPU-bound blocking by wrapping the code in async functions or promises. An async function that performs a heavy synchronous loop still blocks the event loop while the loop runs.

Try it yourself

Create a small Express or Fastify server with two routes: one that responds immediately and one that runs a heavy synchronous loop. Call the slow route and the fast route together and observe the delay. Then move the heavy work to a worker thread and repeat.

Your implementation checklist

• I monitor event-loop delay in production
• Request handlers do not use synchronous file, compression or crypto APIs
• CPU-heavy tasks run in workers or background jobs
• Long tasks return a job ID instead of holding the request open
• Input sizes are limited to prevent unbounded work