Rohit Nandi

Full Stack Engineer

Node.js Worker Threads: Making Image Processing Actually Fast

Node.js Worker Threads: Making Image Processing Actually Fast

Published on 11th April 2026

The Problem with Node.js and CPU Work

If you have spent any time with Node.js, you have probably heard the phrase "single-threaded" thrown around a lot. And it is true. Node runs your JavaScript on a single thread. For most web server stuff like handling HTTP requests, reading from a database, or writing to a file, this is totally fine. The event loop handles I/O beautifully, and life is good.

But then you try to do something CPU-intensive, like processing images, and suddenly that single thread becomes a bottleneck. While one image is being resized or transformed, everything else just sits there waiting. No other request gets handled. Nothing moves forward. Your server is essentially frozen until that CPU work finishes.

This is where worker threads come in.

What Are Worker Threads?

Worker threads let you spin up additional threads from your Node.js process. Each thread gets its own V8 engine instance and its own event loop. They run in parallel, on separate CPU cores, doing real concurrent work. This is not the same as Promise.all or async/await, which are still single-threaded concurrency. Worker threads give you actual parallelism.

Node provides the worker_threads module for this, and it has been stable since Node 12.

const {
  Worker,
  isMainThread,
  parentPort,
  workerData,
} = require('worker_threads')

The key pieces are:

  • Worker: creates a new thread from the main thread
  • isMainThread: boolean that tells you if the current code is running on the main thread or inside a worker
  • parentPort: the communication channel back to the main thread (available inside workers)
  • workerData: data passed from the main thread when creating the worker

The Experiment: Image Processing Benchmark

To see worker threads in action, I built a small benchmark. The idea is simple: take a few large images (4000x3000 pixels), run several processing tasks on each one (resize, blur, grayscale, sharpen, etc.), and compare how long it takes to do all of that work single-threaded vs. with worker threads.

Here is the setup for generating source images. Each image is a 4000x3000 PNG filled with tinted noise, so they are large enough to actually stress the CPU:

const COLORS = [
  { name: 'crimson', rgb: { r: 220, g: 20, b: 60 } },
  { name: 'ocean', rgb: { r: 0, g: 105, b: 148 } },
  { name: 'forest', rgb: { r: 34, g: 139, b: 34 } },
  { name: 'sunset', rgb: { r: 255, g: 140, b: 0 } },
]

const IMG_WIDTH = 4000
const IMG_HEIGHT = 3000

function generateNoiseBuffer(
  width: number,
  height: number,
  tint: { r: number; g: number; b: number },
): Buffer {
  const pixels = width * height * 3
  const buf = Buffer.alloc(pixels)
  for (let i = 0; i < pixels; i += 3) {
    buf[i] = (Math.random() * 128 + tint.r / 2) & 0xff
    buf[i + 1] = (Math.random() * 128 + tint.g / 2) & 0xff
    buf[i + 2] = (Math.random() * 128 + tint.b / 2) & 0xff
  }
  return buf
}

Each source image gets saved as a PNG using sharp, which is a popular high-performance image processing library for Node.

Defining the Tasks

Each image goes through multiple transformations. A task looks something like this:

interface ImageTask {
  inputPath: string
  outputPath: string
  operation: 'resize' | 'blur' | 'grayscale' | 'sharpen' | 'rotate' | 'tint'
  params?: Record<string, any>
}

For 4 source images with 6 operations each, that gives us 24 image processing tasks. Not a huge number, but each one takes a meaningful amount of CPU time because the images are large.

Approach 1: Single-Threaded

The straightforward approach. Just loop through all the tasks and process them one after the other:

import sharp from 'sharp'

async function processTask(task: ImageTask): Promise<{ success: boolean }> {
  try {
    let pipeline = sharp(task.inputPath)

    switch (task.operation) {
      case 'resize':
        pipeline = pipeline.resize(task.params.width, task.params.height)
        break
      case 'blur':
        pipeline = pipeline.blur(task.params.sigma)
        break
      case 'grayscale':
        pipeline = pipeline.grayscale()
        break
      case 'sharpen':
        pipeline = pipeline.sharpen()
        break
      case 'rotate':
        pipeline = pipeline.rotate(task.params.angle)
        break
      case 'tint':
        pipeline = pipeline.tint(task.params.color)
        break
    }

    await pipeline.toFile(task.outputPath)
    return { success: true }
  } catch (error) {
    return { success: false }
  }
}

async function runSingleThreaded(tasks: ImageTask[]) {
  const results = []
  for (const task of tasks) {
    const result = await processTask(task)
    results.push(result)
  }
  return results
}

Nothing fancy. Each task waits for the previous one to finish before starting. On a machine with 8 or 10 CPU cores, this means only one core is doing work while the rest sit idle.

Approach 2: Worker Threads

Now let us bring in worker threads. The idea is to create a pool of workers and distribute the image tasks across them so they run in parallel.

The Worker Script

First, we need a script that each worker thread will run. It listens for a task from the main thread, processes the image, and sends back the result:

import { parentPort, workerData } from 'worker_threads'
import sharp from 'sharp'

const task = workerData

async function run() {
  try {
    let pipeline = sharp(task.inputPath)

    switch (task.operation) {
      case 'resize':
        pipeline = pipeline.resize(task.params.width, task.params.height)
        break
      case 'blur':
        pipeline = pipeline.blur(task.params.sigma)
        break
      case 'grayscale':
        pipeline = pipeline.grayscale()
        break
      case 'sharpen':
        pipeline = pipeline.sharpen()
        break
      case 'rotate':
        pipeline = pipeline.rotate(task.params.angle)
        break
      case 'tint':
        pipeline = pipeline.tint(task.params.color)
        break
    }

    await pipeline.toFile(task.outputPath)
    parentPort?.postMessage({ success: true })
  } catch (error) {
    parentPort?.postMessage({ success: false, error: String(error) })
  }
}

run()

The important thing here is workerData. When the main thread creates a worker, it passes the task data through workerData, and the worker picks it up immediately. Once the work is done, the worker uses parentPort.postMessage() to send the result back.

The Main Thread Orchestrator

On the main thread side, we create one worker per task and wait for all of them to finish:

import { Worker } from 'worker_threads'
import path from 'path'

function runWorker(task: ImageTask): Promise<{ success: boolean }> {
  return new Promise((resolve, reject) => {
    const worker = new Worker(path.join(__dirname, 'worker.js'), {
      workerData: task,
    })

    worker.on('message', (result) => {
      resolve(result)
    })

    worker.on('error', (error) => {
      resolve({ success: false })
    })

    worker.on('exit', (code) => {
      if (code !== 0) {
        resolve({ success: false })
      }
    })
  })
}

async function runMultiThreaded(tasks: ImageTask[]) {
  const promises = tasks.map((task) => runWorker(task))
  return Promise.all(promises)
}

Each call to new Worker(...) spawns a new thread. We pass the task as workerData, then listen for the message event to get the result back. Since Promise.all is used, all workers start at roughly the same time and run truly in parallel across CPU cores.

The Benchmark Runner

The main script ties everything together. It generates the source images, runs both approaches, and compares the results:

import os from 'os'

async function main() {
  console.log('=== Node.js Worker Threads Benchmark ===')
  console.log(`CPU cores: ${os.cpus().length}\n`)

  await generateSourceImages()

  // Single-threaded run
  const singleTasks = generateTasks(IMAGES_DIR, path.join(OUTPUT_DIR, 'single'))
  console.log(`Processing ${singleTasks.length} image tasks...\n`)

  console.log('[1] Without Worker Threads (single-threaded)')
  const single = await timeIt(() => runSingleThreaded(singleTasks))
  console.log(`    Time: ${formatMs(single.ms)}ms`)

  // Multi-threaded run
  const multiTasks = generateTasks(IMAGES_DIR, path.join(OUTPUT_DIR, 'multi'))

  console.log('[2] With Worker Threads (parallel)')
  const multi = await timeIt(() => runMultiThreaded(multiTasks))
  console.log(`    Time: ${formatMs(multi.ms)}ms`)

  // Compare
  const speedup = single.ms / multi.ms
  console.log('\n=== Results ===')
  console.log(`  Single-threaded: ${formatMs(single.ms)}ms`)
  console.log(`  Worker threads:  ${formatMs(multi.ms)}ms`)
  console.log(`  Speedup:         ${speedup.toFixed(2)}x faster with workers`)
}

The timeIt utility is a simple wrapper that measures execution time:

function timeIt<T>(
  fn: () => T | Promise<T>,
): Promise<{ result: T; ms: number }> {
  const start = performance.now()
  const maybePromise = fn()

  if (maybePromise instanceof Promise) {
    return maybePromise.then((result) => ({
      result,
      ms: Math.round(performance.now() - start),
    }))
  }

  return Promise.resolve({
    result: maybePromise,
    ms: Math.round(performance.now() - start),
  })
}

What Kind of Speedup to Expect

On a machine with 10 CPU cores processing 24 image tasks, you would typically see something like:

=== Node.js Worker Threads Benchmark ===
CPU cores: 10

Processing 24 image tasks...

[1] Without Worker Threads (single-threaded)
    Time: 12,450ms

[2] With Worker Threads (parallel)
    Time: 2,830ms

=== Results ===
  Single-threaded: 12,450ms
  Worker threads:  2,830ms
  Speedup:         4.40x faster with workers

The speedup is not a perfect 10x even with 10 cores. There is overhead from spawning workers, serializing data between threads, and the OS scheduler. But a 3x to 5x improvement is very real and very noticeable.

How the Communication Works Under the Hood

Worker threads in Node do not share memory by default. When you pass workerData, Node serializes the data using the structured clone algorithm and deserializes it on the other side. Same thing with postMessage. This means each thread works with its own copy of the data.

If you need to share memory between threads (say, for a large buffer), you can use SharedArrayBuffer:

const sharedBuffer = new SharedArrayBuffer(1024)
const worker = new Worker('./worker.js', {
  workerData: { buffer: sharedBuffer },
})

But for most use cases, passing serialized data is simpler and avoids the whole class of race condition bugs that shared memory introduces.

When Should You Use Worker Threads?

Worker threads are great for:

  • Image/video processing like what we did here
  • Data parsing of large CSV/JSON files
  • Cryptographic operations like hashing or encryption
  • Mathematical computations like matrix operations or simulations
  • Compression/decompression of large files

Worker threads are overkill for:

  • I/O-bound work like database queries, HTTP requests, or file reads. The event loop handles these perfectly fine with async/await.
  • Lightweight operations that finish in a few milliseconds. The overhead of spawning a worker would be larger than the work itself.

A good rule of thumb: if the work blocks the event loop for more than 50ms or so, consider offloading it to a worker thread.

Worker Pool: A Better Pattern for Production

Spawning a new worker for every single task works for a benchmark, but in production you would want a worker pool. Creating a thread is not free, and you do not want to spin up hundreds of them.

A worker pool creates a fixed number of workers up front and reuses them:

import { Worker } from 'worker_threads'
import os from 'os'

class WorkerPool {
  private workers: Worker[] = []
  private queue: Array<{
    task: any
    resolve: (value: any) => void
    reject: (reason: any) => void
  }> = []
  private activeWorkers = 0

  constructor(
    private workerScript: string,
    private poolSize: number = os.cpus().length,
  ) {}

  async execute(task: any): Promise<any> {
    return new Promise((resolve, reject) => {
      this.queue.push({ task, resolve, reject })
      this.processQueue()
    })
  }

  private processQueue() {
    while (this.queue.length > 0 && this.activeWorkers < this.poolSize) {
      const { task, resolve, reject } = this.queue.shift()!
      this.activeWorkers++

      const worker = new Worker(this.workerScript, { workerData: task })

      worker.on('message', (result) => {
        this.activeWorkers--
        resolve(result)
        this.processQueue()
      })

      worker.on('error', (error) => {
        this.activeWorkers--
        reject(error)
        this.processQueue()
      })
    }
  }
}

Usage:

const pool = new WorkerPool('./worker.js', 4)

const results = await Promise.all(tasks.map((task) => pool.execute(task)))

This way you never have more workers than CPU cores, and tasks queue up when all workers are busy. Much more predictable resource usage.

Gotchas to Watch Out For

1. Not everything is cloneable. You cannot pass functions, class instances, or DOM objects through workerData or postMessage. Stick to plain objects, arrays, buffers, and primitives.

2. Each worker loads its own modules. If your worker script imports sharp, every worker thread loads sharp independently. This uses more memory. For a handful of workers this is fine, but keep it in mind.

3. Error handling matters. If a worker throws an unhandled error, it emits an error event and exits. Always listen for both error and exit events, or your main thread will hang waiting for a message that never comes.

4. Workers are not free. Each worker thread uses memory (a few MB at minimum for the V8 isolate). Do not create more workers than you have CPU cores unless you have a very good reason.

Full Source Code

You can find the complete working code for this benchmark on GitHub: github.com/RockingThor/blog-learnings. Clone it, run it on your machine, and see the speedup for yourself.

Wrapping Up

Node.js being single-threaded does not mean you are stuck with one core for everything. Worker threads give you a clean way to offload CPU-heavy work to separate threads, and the performance gains are significant. For our image processing benchmark, we saw a 4x+ speedup just by distributing tasks across threads.

The API is straightforward: create a Worker, pass it some data, and listen for the result. For production use, wrap it in a pool so you reuse threads instead of creating new ones for every task.

If your Node app is doing anything CPU-intensive and you have not tried worker threads yet, give them a shot. Your users (and your server) will thank you.