Web Workers: Keep Your UI Responsive During Heavy Tasks

Why it exists

JavaScript is single-threaded. If a long-running script executes, the browser can't do anything else—it can't respond to clicks, update animations, or even scroll. The UI freezes. Web Workers were created to solve this by enabling true multi-threading in the browser, allowing long tasks to run without blocking the main thread.

The mental model

Think of the main browser thread as a busy front-desk receptionist who also handles all user interactions. If they get stuck on a long, complex phone call (a heavy script), no one else can be served. A Web Worker is like hiring a back-office employee. The receptionist can pass off a complex task to the back-office worker and continue serving users. The back-office worker will send a message back when the task is complete.

How it works

You instantiate a worker by providing the path to a JavaScript file: const myWorker = new Worker('worker.js');. This script runs in a separate global context, isolated from the main thread's window object. Communication is handled through an asynchronous messaging system. The main thread uses myWorker.postMessage(data) to send data, and the worker script uses self.postMessage(data) to send it back. Both listen for incoming messages with an onmessage event handler. Importantly, data is copied, not shared, when passed between threads.

When to use it

Use Web Workers for CPU-intensive operations that would otherwise block the UI. This includes things like complex mathematical calculations (e.g., image filtering, cryptography), parsing large JSON files, or managing data in a complex client-side database without freezing the page. They are also useful for pre-fetching data or performing background synchronization.

When not to use it

Don't use a worker for tasks that require direct, synchronous access to the DOM or the window object, as workers are explicitly forbidden from this. The overhead of creating a worker and passing messages also makes them unsuitable for very small, quick tasks. For simple asynchronous operations that don't block the CPU, like a standard fetch call, a Promise or async/await on the main thread is often sufficient.

One canonical example

A common use case is processing a user-uploaded image. The main thread receives the file and sends the image data to a worker using postMessage(). The worker then performs a heavy operation, like applying a grayscale filter pixel by pixel, without freezing the UI. Once done, the worker sends the modified image data back to the main thread, which then displays the result in a canvas element.