Performance

Node.js is fast for I/O-bound workloads because its event loop can multiplex thousands of concurrent connections on a single thread. That same strength becomes a bottleneck when synchronous work blocks the loop, when memory leaks grow without bound, or when CPU-bound tasks monopolize the only available thread. Performance tuning in Node.js is therefore about protecting the event loop, scaling horizontally across CPU cores, and measuring before optimizing.

This guide covers the tools and patterns that matter in production: the cluster module for multi-process scaling, worker_threads for true parallelism, event-loop lag measurement, CPU and heap profiling, memory-leak detection, stream backpressure, caching strategies, benchmarking discipline, and load-balancing practices.

All examples target Node.js 20+ unless noted otherwise.

Premature optimization is especially dangerous in Node.js because the event loop makes some code unexpectedly fast and other code unexpectedly slow. A synchronous 5 ms JSON parse feels instant in development but destroys throughput at 1,000 requests per second. Always establish a baseline, identify the actual bottleneck, and then optimize.

A simple benchmark harness in pure Node.js can rule out obvious regressions before you introduce a full framework. Use performance.now() from node:perf_hooks for sub-millisecond precision and run enough iterations to amortize startup noise.

By default a Node.js process uses one CPU core. The node:cluster module forks worker processes that share the same server port, letting the operating system distribute incoming connections across available cores. This is the simplest way to scale a stateless HTTP server vertically.

Each worker is a separate process with its own memory space and event loop. Workers cannot share in-memory state directly, so use Redis or a database for shared data. Cluster load balancing is connection-based, so long-running WebSocket or keep-alive sessions can skew distribution; use a reverse proxy for request-level balancing.

The node:worker_threads module lets you run JavaScript in parallel threads within the same process. Unlike child processes, workers share memory through SharedArrayBuffer and Atomics, and communication via MessagePort is much faster than IPC.

Use worker threads for CPU-intensive work such as image resizing, PDF generation, and cryptographic key derivation. Do not use them for I/O-bound work; the event loop already handles that more efficiently. Creating a worker has overhead, so maintain a pool and reuse workers for sustained workloads.

Event loop lag measures how late the loop is relative to when a timer was supposed to fire. Sustained lag above 50 ms degrades latency-sensitive workloads. Lag is usually caused by synchronous work: large JSON parsing, synchronous file reads, unbounded loops, or blocking cryptography.

When latency is high but you cannot pinpoint the cause, profiling shows where the process spends time and memory. Node.js ships with built-in sampling profilers and an inspector protocol that integrates with Chrome DevTools.

The --prof output lists the hottest JavaScript and C++ functions. Look for functions with high [self] and [total] tick counts. Native stack frames from V8 builtins, libuv, and crypto often reveal hidden costs such as excessive stringification or JSON parsing.

Heap snapshots capture the object graph at a point in time. Compare two snapshots taken before and after a suspected leak to see which object types grew. Generate them programmatically or via the inspector.

Node.js memory usage grows until the heap limit is reached, then the process exits with an out-of-memory error. The most common leaks are accidental closures, unbounded caches, forgotten event listeners, and timers that hold references to large objects.

For caches that should not keep objects alive forever, prefer WeakMap or WeakRef when the lifetime of the cached value should follow the lifetime of an external object. For request-scoped caches, use an LRU with explicit bounds.

Streams let you move data incrementally without loading everything into memory. Backpressure happens when a fast producer overwhelms a slow consumer. Ignoring backpressure causes memory spikes, latency jumps, and eventually process crashes.

The pipeline function from node:stream/promises automatically handles errors and closes streams. Always prefer it over .pipe(), which leaks error handlers and does not propagate cleanup. Async iterator streams created with Readable.from() are backpressure-aware by default and work well with pipeline.

Caching is the highest-impact performance improvement for read-heavy workloads, but it introduces complexity around invalidation, consistency, and stale data. A good cache has a clear TTL, bounded size, and a defined invalidation policy.

Vertical scaling with cluster and worker threads takes you only as far as one machine. Horizontal scaling across multiple machines requires a load balancer and a stateless application design. Statelessness means any request can be handled by any instance without depending on local memory.

Health checks route traffic away from failed instances. A minimal health endpoint should verify that the event loop is responsive and that critical dependencies such as the database or cache are reachable. Do not make health checks expensive.

Most Node.js performance problems are repeated patterns that block the event loop, waste memory, or serialize work unnecessarily. The worst offenders are synchronous file system calls, large JSON.parse operations, unpooled database connections, synchronous logging, CPU work on the main thread, and missing request timeouts.