Performance Overview

Node.js is fast by default for the workload it was designed for — I/O-bound servers handling many concurrent connections — but it's easy to accidentally make it slow. Because everything runs on a single thread, one blocking operation degrades every request at once, so Node performance work is mostly about not blocking the event loop and not doing redundant work. This page frames the discipline: measure before optimizing, understand the I/O-bound vs CPU-bound divide, know the common bottlenecks, and learn the order in which to attack them — before later pages dig into profiling, memory leaks, caching, and more.

Measure first — the cardinal rule

Don't optimize from intuition — profile first; the bottleneck is almost never where you guess

The most expensive performance mistake is optimizing code that isn't the bottleneck. Developers' intuition about *what's slow* is wrong far more often than right — the real cost is usually an N+1 database query, a missing index, or a synchronous call you forgot about, not the clever algorithm you're tempted to hand-tune. **Always measure before and after**: capture a baseline with [profiling](/nodejs/profiling) and [load testing](/nodejs/load-testing), change one thing, measure again. Optimization without measurement is guessing, and it routinely makes code more complex while moving the needle zero. Premature optimization wastes effort and adds bugs.

I/O-bound vs CPU-bound — they need opposite fixes

	I/O-bound	CPU-bound
Time spent	Waiting on DB, network, disk	Computing — crypto, parsing, image work
Node default fit	Excellent — async I/O, high concurrency	Poor — blocks the single thread
The fix	Parallelize, cache, batch, add indexes	Offload: worker threads, child processes, native code
Symptom	Slow but loop responsive	Event-loop lag, all requests stall together

Node excels at I/O concurrency but a CPU-bound task blocks everyone — diagnose which you have first

The single most important performance distinction in Node is whether a slow operation is **waiting** (I/O-bound) or **working** (CPU-bound). Node's async model makes it superb at I/O concurrency — thousands of connections all waiting on the database cost almost nothing because the thread is free while they wait. But a CPU-bound task (a big `JSON.parse`, password hashing, image resizing, a tight loop) *occupies* the single thread, so while it runs no other request can be served — latency spikes across the board. The fixes are opposite: I/O-bound code wants parallelism and caching; CPU-bound code must be moved *off* the main thread entirely. Identify which you have before choosing a remedy.

The usual suspects, roughly in order of impact

Database — N+1 queries, missing indexes, fetching too much, no connection pooling. Usually the #1 cost in a web app.
Blocking the event loop — synchronous crypto/fs, huge JSON, regex backtracking; stalls every request.
No caching — recomputing or re-fetching identical data on every request (caching strategies).
Serial instead of parallel — awaiting independent operations one-by-one instead of Promise.all.
Oversized payloads — sending more data than the client needs; no compression or pagination.
Memory pressure — leaks and excess allocation triggering frequent GC pauses.

The most common quick win: parallelize independent awaits

// ❌ Serial — 3 round-trips back to back (≈ sum of all three):
const user = await getUser(id)
const orders = await getOrders(id)
const prefs = await getPrefs(id)

// ✅ Parallel — they don't depend on each other, so fire together (≈ the slowest one):
const [user, orders, prefs] = await Promise.all([
  getUser(id), getOrders(id), getPrefs(id),
])

Awaiting independent operations serially is the most common self-inflicted slowdown

A pervasive, easy-to-fix mistake: `await`ing operations one after another when they don't depend on each other. Three sequential 50ms queries take ~150ms; the same three with `Promise.all` take ~50ms because they run concurrently. Scan your handlers for back-to-back `await`s where the later ones don't use the earlier results — those are free wins. (Only serialize when there's a genuine data dependency.) This single pattern often cuts endpoint latency more than any micro-optimization.

An optimization workflow

Set a goal — a concrete target (p95 < 200ms, 1000 req/s) so you know when to stop.
Establish a baseline — measure current behaviour under realistic load.
Find the bottleneck — profile CPU and inspect slow queries; let data point you.
Fix the biggest one — address the dominant cost, not a 1% sliver.
Measure again — confirm the change actually helped and didn't regress correctness.
Repeat or stop — iterate until you hit the goal; resist optimizing past "good enough".

Optimize for the common case and stop at 'good enough' — diminishing returns are real

Performance work has sharply diminishing returns: the first fix might halve latency, the tenth might shave 2%. Optimize the **common, hot path** that most requests take — not rare edge cases — and stop when you've met your goal, because beyond that you're trading real complexity (and new bug surface) for imperceptible gains. Also weigh cost: sometimes the cheapest "optimization" is a bigger instance or a managed cache, not a week of engineering. Keep the code readable; a 5% speedup that makes the code unmaintainable is usually a bad trade.

Find exactly where the time goes: [Profiling Node.js Apps](/nodejs/profiling).