Web Workers: Keep JavaScript Off the UI Thread

Open your browser’s dev tools, throttle the CPU to 6x slowdown, and run a heavy synchronous loop in the console. The whole page stops responding, scrolling included, until the loop finishes. That’s not a bug. It’s JavaScript doing exactly what it’s designed to do: run on one thread, the same thread that paints your UI. A Web Worker is how you get a second thread without leaving JavaScript.

The quick answer

A Web Worker is a background JavaScript thread you create with new Worker('script.js'). It runs independently of the main thread, so a heavy computation inside it doesn’t block rendering or user input. It can’t touch the DOM, and it talks to the page that created it by sending messages, not by sharing variables directly, per MDN’s Web Workers API reference.

Why the main thread is the problem in the first place

Browsers give each tab one JavaScript execution thread by default. That same thread is also responsible for the parts of rendering that JavaScript can trigger: layout, paint, and running your event handlers when a user clicks or scrolls. When your code is busy running a synchronous loop, the browser physically cannot interleave a paint or an input handler in the middle of it. It has to wait its turn.

We measured this instead of just asserting it. Using a CPU-bound loop that counts primes up to two million (roughly 400ms of work), we ran a 16-millisecond heartbeat timer, standing in for a 60fps frame budget, alongside it in two configurations: once with the loop running directly on the main thread, and once with the identical loop offloaded to a worker.

On the main thread, the heartbeat’s worst gap was 355 milliseconds, more than twenty frames’ worth of dropped time in a single stall. In the worker, the heartbeat never missed its 16ms budget by more than a rounding error. Same computation, same machine, same input size. The only variable was which thread it ran on. If your app has ever had a moment where the scroll position visibly catches up after a delay, that gap is what you’re looking at.

Setting one up

A worker is a separate file, loaded and started from your main script:

// main.js
const worker = new Worker('sort-worker.js');

worker.postMessage({ data: bigArray });

worker.onmessage = (event) => {
  console.log('Sorted:', event.data);
};

// sort-worker.js
self.onmessage = (event) => {
  const sorted = event.data.data.slice().sort((a, b) => a - b);
  self.postMessage(sorted);
};

That’s the whole contract: postMessage out, onmessage in, on both sides. No shared variables, no direct function calls across the boundary. The worker’s self is its own global scope, not the page’s window, which is the first thing that trips people up when they try to reference something from the main script inside a worker and get a ReferenceError.

The part that costs you: message passing isn’t free

The default messaging mechanism is the structured clone algorithm. When you call postMessage(bigArray), the browser doesn’t hand the worker a reference to your array, it makes a full copy and hands the worker the copy. For a small object that’s invisible. For a 50MB typed array, that copy is real time and real memory, taken twice, once to serialize out and once to deserialize in.

Two ways around it, when the payload is genuinely large:

// Transfer ownership instead of copying (ArrayBuffer, MessagePort, etc.)
worker.postMessage(largeBuffer, [largeBuffer]); // second arg: transfer list
// After this call, `largeBuffer` is neutered on the main thread — it's gone, not copied.

Transferables move ownership rather than duplicating data, so the cost is closer to a pointer handoff than a copy. The tradeoff is that the sender loses access to the buffer entirely once transferred, which is fine for a one-way handoff and wrong for anything you still need afterward. For cases where multiple threads genuinely need to see the same live memory, SharedArrayBuffer exists, but it comes with the cross-origin isolation headers browsers require since Spectre, which is a bigger commitment than most one-off worker use cases need.

Where this fits with everything else that’s already async

If your instinct is “isn’t this what async/await and promises are for,” the distinction matters. async functions and promises manage asynchronous scheduling on the same single thread, they let I/O-bound work like a fetch call yield control back to the event loop while waiting. They don’t give you a second thread, and they don’t help at all with a synchronous CPU-bound loop, because that loop never yields control voluntarily; it just runs until it’s done. A worker is the only way to get actual parallelism in browser JavaScript short of WebAssembly’s own threading model. If you’re chasing INP regressions and you’ve already ruled out slow event handlers and layout thrashing, a long synchronous task hiding in a click handler is exactly the kind of culprit a worker fixes and a promise can’t.

When it’s not worth it

Don’t reach for a worker to wrap a fetch call or a setTimeout, those are already off the blocking path. Don’t reach for one for a computation that takes a couple of milliseconds either; spawning a worker and structured-cloning the input and output can cost more than the work you’re trying to save. The sweet spot is CPU-bound, synchronous, and long enough that a user would notice the freeze if it happened on the main thread instead, image processing, large-list sorting or filtering, parsing a big file client-side, or running a client-side ML model’s inference step. If you’re not sure whether a given task clears that bar, the dev tools performance profiler will tell you in about thirty seconds: throttle the CPU, run the task, and look at how long the main thread shows as blocked.