Web Workers: Offload Heavy Tasks from the UI Thread

Why it exists

JavaScript is single-threaded. If a script runs a long, intensive task on the main thread, the entire user interface becomes unresponsive—animations freeze, clicks are ignored, and the page feels broken. Web Workers were created to solve this by providing a way to run scripts in the background, off the main thread.

The mental model

A Web Worker is like hiring a temporary assistant to handle a heavy task in a separate room. You give them instructions and data (a message), they do the work without interrupting you, and then they pass the result back. They can't directly change anything in your room (the DOM); all communication happens through these passed messages.

How it works

You create a worker by instantiating the Worker object with the path to a JavaScript file: const myWorker = new Worker('worker.js');. This script runs in a separate global context, different from the main page's window. Inside the worker, the global scope is self. To communicate, the main thread and the worker use the postMessage() method to send data and an onmessage event handler to receive it. The data sent in a message is copied, not shared, creating a duplicate for the receiving thread. While workers cannot manipulate the DOM, they can use many other APIs like fetch(), WebSockets, and IndexedDB.

When to use it

Use Web Workers for any computation that is CPU-intensive and risks blocking the main thread. This includes tasks like processing large datasets, complex mathematical calculations, cryptography, or parsing large JSON files without freezing the UI. They are also useful for pre-fetching and caching data in the background.

When not to use it

Do not use Web Workers for tasks that require direct, synchronous access to the DOM, as this is impossible. The overhead of creating a worker and copying data also makes them unsuitable for very small, quick tasks where the communication cost would outweigh the benefit of parallelism. If you need to share memory instead of copying it, you would need a more advanced tool like SharedArrayBuffer.

One canonical example

A common use case is a web-based image editor. When a user applies a complex filter to a large image, the pixel manipulation can take several seconds. Instead of freezing the UI, the main thread sends the image data to a Web Worker. The worker performs the heavy pixel-by-pixel calculations and, once finished, sends the modified image data back to the main thread, which then updates the image element on the page.