Node.js Performance Optimization: The Practical Guide

Node.js performance problems are almost always one of three things: event loop blocking, memory leaks, or inefficient I/O. Get these three right and most Node.js applications run well without exotic optimization. The challenge is diagnosing which one you have and finding it in a production codebase.

This guide covers practical techniques I use when a Node.js application is not performing as expected.

Measuring Before Optimizing

The first rule is to measure. Node.js performance problems often lurk in unexpected places. Profile before you optimize.

Event loop lag measures how delayed the event loop is. A healthy Node.js application has near-zero event loop lag. Anything consistently above 100ms indicates blocked I/O or synchronous work on the main thread:

let lastCheck = Date.now()

setInterval(() => {
  const lag = Date.now() - lastCheck - 1000 // Expected 1000ms
  lastCheck = Date.now()

  if (lag > 100) {
    console.warn(`Event loop lag: ${lag}ms`)
  }
}, 1000)

In production, report this metric to your observability system (Datadog, Prometheus). A spike in event loop lag correlates directly with poor response times and user experience degradation.

Memory tracking catches leaks before they take the process down:

setInterval(() => {
  const { heapUsed, heapTotal, external, rss } = process.memoryUsage()
  console.log({
    heapUsedMB: Math.round(heapUsed / 1024 / 1024),
    heapTotalMB: Math.round(heapTotal / 1024 / 1024),
    rssMB: Math.round(rss / 1024 / 1024),
  })
}, 30000) // Every 30 seconds

If heapUsed grows monotonically over hours, you have a memory leak. If it grows and shrinks, the garbage collector is working normally.

Profiling CPU Usage

When you know the event loop is slow but not why, use Node.js's built-in profiler:

node --prof app.js

After running under load, process the profile:

node --prof-process isolate-*.log > processed.txt

The output shows which functions are consuming CPU time. Look for synchronous operations — JSON parsing, cryptography, string manipulation — in hot paths.

For more modern profiling, use the --inspect flag with Chrome DevTools:

node --inspect app.js

Open chrome://inspect in Chrome and attach to the Node process. The Performance tab provides flame charts that show exactly where time is spent.

The Event Loop Blocking Patterns

The most common Node.js performance mistakes all share a root cause: blocking the single-threaded event loop with synchronous work.

Synchronous JSON parsing of large objects:

// BAD: Blocks the event loop for the duration of parsing
const huge = JSON.parse(fs.readFileSync('huge-file.json', 'utf8'))

// BETTER: Use async file reading + streaming for very large files
import { createReadStream } from 'fs'
import { pipeline } from 'stream/promises'
import JSONStream from 'JSONStream'

async function processLargeJSON(filePath: string) {
  const stream = createReadStream(filePath)
  const parser = JSONStream.parse('*')
  // Process items as they stream rather than loading all at once
}

Regular expressions with catastrophic backtracking:

// This regex can block for seconds on certain inputs (ReDoS)
const BAD_REGEX = /^(a+)+$/

// Test your regex against adversarial inputs before production
// Use a ReDoS checker tool

Synchronous cryptography:

// BAD: bcrypt.hashSync blocks the event loop
const hash = bcrypt.hashSync(password, 12) // Can take 200-500ms

// GOOD: Use async version
const hash = await bcrypt.hash(password, 12) // Non-blocking

Worker Threads for CPU-Intensive Work

For genuinely CPU-intensive tasks (image processing, PDF generation, data transformation), offload to worker threads:

// workers/imageProcessor.ts
import { parentPort, workerData } from 'worker_threads'
import sharp from 'sharp'

async function processImage() {
  const { inputBuffer, width, height, format } = workerData

  const result = await sharp(inputBuffer)
    .resize(width, height, { fit: 'inside' })
    .toFormat(format)
    .toBuffer()

  parentPort?.postMessage(result, [result.buffer])
}

processImage()

// In your main application
import { Worker } from 'worker_threads'

function processImageInWorker(
  inputBuffer: Buffer,
  options: { width: number; height: number; format: string }
): Promise<Buffer> {
  return new Promise((resolve, reject) => {
    const worker = new Worker('./dist/workers/imageProcessor.js', {
      workerData: { inputBuffer, ...options },
      transferList: [inputBuffer.buffer],
    })

    worker.on('message', resolve)
    worker.on('error', reject)
    worker.on('exit', (code) => {
      if (code !== 0) reject(new Error(`Worker exited with code ${code}`))
    })
  })
}

A worker thread pool is more efficient than creating a new worker per request. Libraries like piscina provide worker pool management:

import Piscina from 'piscina'

const pool = new Piscina({
  filename: './dist/workers/imageProcessor.js',
  maxThreads: Math.max(1, os.cpus().length - 1),
})

const result = await pool.run({ inputBuffer, width: 800, height: 600, format: 'webp' })

Clustering for Multi-Core Utilization

Node.js runs on a single CPU core by default. For web servers, use clustering to utilize all available cores:

// cluster.ts
import cluster from 'cluster'
import os from 'os'
import { createServer } from './app'

if (cluster.isPrimary) {
  const numCPUs = os.cpus().length
  console.log(`Primary ${process.pid} is running. Spawning ${numCPUs} workers.`)

  for (let i = 0; i < numCPUs; i++) {
    cluster.fork()
  }

  cluster.on('exit', (worker, code, signal) => {
    console.warn(`Worker ${worker.process.pid} died (${signal || code}). Restarting.`)
    cluster.fork()
  })
} else {
  createServer().listen(3000, () => {
    console.log(`Worker ${process.pid} started`)
  })
}

In practice, I prefer running multiple single-process instances behind a load balancer (with PM2 or Docker) rather than Node.js clustering. The isolation is better — a crash in one process does not affect others, and rolling restarts are cleaner.

Memory Leak Detection

Memory leaks in Node.js applications typically come from:

Event listeners not removed:

// BAD: Every request attaches a listener that never gets removed
app.get('/stream', (req, res) => {
  const dataSource = new EventEmitter()
  dataSource.on('data', (chunk) => res.write(chunk))
  // dataSource is never cleaned up if the request closes early
})

// GOOD: Clean up when the connection closes
app.get('/stream', (req, res) => {
  const dataSource = new EventEmitter()
  const handler = (chunk: Buffer) => res.write(chunk)

  dataSource.on('data', handler)
  req.on('close', () => dataSource.off('data', handler))
})

Growing caches without eviction:

// BAD: Cache grows forever
const cache = new Map()
function getCached(key: string) {
  if (!cache.has(key)) {
    cache.set(key, expensiveOperation(key))
  }
  return cache.get(key)
}

// GOOD: Use LRU cache with size limit
import LRU from 'lru-cache'
const cache = new LRU({ max: 1000, ttl: 1000 * 60 * 5 })

Closures capturing large objects:

// BAD: The closure captures the entire largeData array
async function processLargeData(largeData: Record<string, unknown>[]) {
  const results = largeData.map(item => ({
    ...item,
    processed: true,
  }))

  // If this promise stays in memory, largeData does too
  return longRunningOperation().then(() => results)
}

// GOOD: Process and release
async function processLargeData(largeData: Record<string, unknown>[]) {
  const ids = largeData.map(item => item.id) // Extract only what you need
  largeData = [] as any // Release the original

  await longRunningOperation()
  return ids
}

To find leaks, take heap snapshots before and after suspected leak scenarios:

import v8 from 'v8'
import fs from 'fs'

// Take a snapshot
const snapshot = v8.writeHeapSnapshot()
console.log('Heap snapshot written to:', snapshot)

Load snapshots in Chrome DevTools Memory tab to find retained objects.

Connection Pool Tuning

Database connection pools are a common performance bottleneck. The default pool sizes are conservative:

// Prisma
const prisma = new PrismaClient({
  datasources: {
    db: {
      url: process.env.DATABASE_URL,
    },
  },
  // connection_limit in the URL: postgresql://...?connection_limit=20
})

// Drizzle with postgres.js
import postgres from 'postgres'

const sql = postgres(process.env.DATABASE_URL!, {
  max: 20,           // Maximum pool size
  idle_timeout: 30,  // Close idle connections after 30 seconds
  connect_timeout: 10,
})

The right pool size is not "as large as possible." Too many connections exhaust the database's connection limit and increase context switching overhead. For PostgreSQL, a good starting point is 2 * CPU_cores + 1 connections per application instance.

Node.js performance is almost always about understanding what blocks the event loop, what leaks memory, and how efficiently you use database and external resources. Measure first, optimize what the data shows, and test under realistic load.

Dealing with performance issues in a Node.js application, or want help setting up monitoring to catch problems before they hit production? Book a call: calendly.com/jamesrossjr.