Web Worker in JavaScript: heavy work without freezing the page

Sorting a hundred thousand rows, resizing an image, parsing a file on load: for those few seconds the page stops responding. Clicks pile up, animations freeze, the cursor spins.

The cause comes down to a simple rule: JavaScript runs one thing at a time inside a page. A single interface lets you step out of it.

Definition

A Web Worker is a script the browser runs in a separate thread, alongside the page. It shares no variable with it and communicates only through messages.

// page.js
const worker = new Worker("compute.js");

worker.postMessage({ rows: 5000000 });

worker.onmessage = (event) => {
  console.log(event.data.total);
  worker.terminate();
};

// compute.js
self.onmessage = (event) => {
  let total = 0;
  for (let i = 0; i < event.data.rows; i++) {
    total += i;
  }
  self.postMessage({ total });
};

Throughout the loop the page stays perfectly responsive. The self keyword refers to the worker itself instead of the window: this does not point at the same object as it does in a page.

What a worker does not have

Isolation comes at a price. A worker lives without a page, which takes away a good share of the usual tools.

• No access to the DOM: no document, no querySelector(), not the slightest change to what is displayed.
• No synchronous storage: localStorage does not exist in this context, unlike IndexedDB.
• No shared variables: the worker sees nothing of what the page defined.

On the other hand fetch(), JSON, timers and RegExp expressions all work normally. The computation goes into the worker, and showing the result comes back to the page.

What travels inside a message

Data sent across is copied through the structured clone algorithm, not shared. Three consequences are worth knowing.

• A function does not travel: the send fails with a cloning error.
• A class instance loses its prototype: it arrives as a plain object, stripped of its methods.
• A large buffer can be transferred rather than copied, by passing it as the second argument of postMessage.

Frequently asked questions

No, and the confusion is common. An async function organizes the wait for a result, it adds no thread whatsoever. A heavy loop placed inside such a function blocks the page exactly as it would anywhere else, because it occupies the same thread, the one described by the Event loop.

Technically many, usefully few. Each one consumes its own memory and its own startup time, and past the number of cores on the machine they simply compete for the same resources. The navigator.hardwareConcurrency value gives an order of magnitude for sizing a pool of reused workers.

A worker never interrupts the page: an internal error stays locked inside it. The error event on the page-side object carries the message out, and messageerror reports data the cloning could not transport. Without those two listeners, a broken worker simply never answers.