Web Workers — Stop Freezing the UI With This Practical Guide

#react #javascript #webdev #performance

Full guide with a live frozen vs smooth UI demo, Comlink setup, transferable objects, and React hook on
onlyWebPro.

JavaScript on the main thread shares one thread with rendering, event handling, and layout. A heavy computation — sorting 200k rows, parsing a 10MB CSV — blocks everything until it finishes. The UI freezes.

Web Workers move that computation to a separate OS thread. The main thread stays completely free.

Why async/await doesn't solve this

Promises and async/await are still single-threaded. They let you defer work so other tasks can run in between — but if the computation itself is CPU-bound, the thread is still blocked while it runs. Web Workers are a separate thread. That's a completely different thing.

The basic pattern

// worker.js — runs in its own thread
self.onmessage = function(event) {
  const { n } = event.data;
  const result = findNthPrime(n);   // heavy computation here
  self.postMessage({ result });
};

// main.js — creates and communicates with the worker
const worker = new Worker('worker.js');
worker.onmessage = ({ data }) => console.log(data.result);
worker.postMessage({ n: 8000 });

Comlink — the right way in 2026

Raw postMessage gets messy fast: manual message routing, matching requests to responses, propagating errors. Comlink (1.1kB, Google) wraps all of that and lets you call worker functions as regular async functions.

// heavy.worker.js
import * as Comlink from 'comlink';

Comlink.expose({
  async findNthPrime(n) { /* ... */ },
  async sortLargeArray(arr) { return [...arr].sort((a, b) => a - b); },
  async parseCSV(text) { return text.trim().split('\n').map(r => r.split(',')); }
});

// main.js
import * as Comlink from 'comlink';
const worker = new Worker(new URL('./heavy.worker.js', import.meta.url), { type: 'module' });
const api = Comlink.wrap(worker);

// Feels like a local async call — no postMessage in sight
const prime  = await api.findNthPrime(8000);
const sorted = await api.sortLargeArray(hugeArray);

Transferable objects — zero-copy data transfer

By default, postMessage deep-copies data. For a 50MB ArrayBuffer that's ~180ms of copy time — defeating the purpose of the worker. Transferable objects transfer ownership in ~0.1ms regardless of size.

const buffer = new ArrayBuffer(50 * 1024 * 1024); // 50 MB

// ❌ Copy — ~180ms for 50MB
worker.postMessage({ buffer });

// ✅ Transfer — ~0.1ms, buffer unusable on main thread afterward
worker.postMessage({ buffer }, [buffer]);

Use transfer for: ArrayBuffer, ImageBitmap, OffscreenCanvas, streams.

React hook — clean lifecycle management

export function useWorker(workerUrl) {
  const workerRef = useRef(null);
  const apiRef    = useRef(null);

  useEffect(() => {
    workerRef.current = new Worker(workerUrl, { type: 'module' });
    apiRef.current    = Comlink.wrap(workerRef.current);
    return () => workerRef.current?.terminate(); // always clean up
  }, []);

  return apiRef;
}

When to use a worker (and when not to)

✅ Use for: sorting/filtering 100k+ rows, parsing large files, image processing, running a search index, encryption/hashing

❌ Don't use for: fetch calls (already async), DOM updates (workers have no DOM access), computations under ~5ms (message overhead isn't worth it)

The full guide has a live demo where you can see a bouncing animation freeze on the main thread and keep running with a worker — same computation, completely different experience.

👉 Read the full guide + live demo

Part 4 — the final post — of the Frontend Performance Series on onlyWebPro.

Have you shipped Web Workers in a production app? What was the use case?

DEV Community