Lesson 3 of 30

Web Workers

Q: Why would you reach for a Web Worker, and what's the actual mechanism that lets it help — given that JavaScript is single-threaded?

A strong answer covers: JavaScript on the main thread blocks everything else — rendering, input — while it runs (the single-threaded model from the event loop lesson); A Web Worker runs on a genuinely separate thread, so heavy computation there doesn't block the main thread's ability to paint or respond to input; Communication happens via postMessage, with data copied via structured clone by default, not shared memory.

Q: Your app's dashboard freezes for half a second every time the user filters a 200,000-row table on the main thread. Walk me through how you'd actually fix this with a Web Worker.

A strong answer covers: Move the pure filtering/sorting computation into a worker — it needs no DOM access; The main thread posts the raw data and filter criteria to the worker; the worker computes and posts the result back; The main thread updates state/UI with the result when it arrives, like any other async operation; Worth noting the real cost: spinning up a worker and copying data isn't free — it's worth it because the computation is expensive enough to justify avoiding a frozen UI.

JavaScript is single-threaded — one heavy computation freezes the whole page. A Web Worker runs real JavaScript on a separate thread so it doesn't have to.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

A Web Worker mutates the hugeDataset object it received via postMessage. Does this affect the original hugeDataset on the main thread?

No — postMessage copies the data via structured clone; the worker has its own independent copyYes — workers share memory with the main thread by defaultYes, but only for primitive values, not objects

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Web Workers

What interviewers actually ask about this, and what a strong answer has to cover.

Why would you reach for a Web Worker, and what's the actual mechanism that lets it help — given that JavaScript is single-threaded?

A strong answer covers

JavaScript on the main thread blocks everything else — rendering, input — while it runs (the single-threaded model from the event loop lesson)
A Web Worker runs on a genuinely separate thread, so heavy computation there doesn't block the main thread's ability to paint or respond to input
Communication happens via postMessage, with data copied via structured clone by default, not shared memory

Likely follow-ups

If a worker computes a huge sorted array and posts it back, is the main thread getting the SAME array object the worker built, or a copy? Why does that matter?
Can a Web Worker read or modify the DOM directly? What does that constrain about what work you can actually move into one?
What's the difference between a Web Worker and a Service Worker — are they the same thing?

Your app's dashboard freezes for half a second every time the user filters a 200,000-row table on the main thread. Walk me through how you'd actually fix this with a Web Worker.

A strong answer covers

The plain-language idea

From the event loop lesson: JavaScript runs on one thread. A long synchronous task — sorting 500,000 rows, parsing a huge JSON blob, running an image filter — blocks that thread completely. No clicks register, no scrolling happens, nothing paints, until the task finishes.

A Web Worker runs JavaScript on a genuinely separate thread. Move the heavy computation there, and the main thread stays free to keep the page responsive while the worker crunches numbers in the background.

See it in a real thing: a frozen filter, fixed

// main.js — freezes the page for however long this takes
const filtered = hugeDataset.filter((row) => row.value > threshold).sort(compareFn);
render(filtered);

// main.js — with a worker, the main thread stays responsive
const worker = new Worker("filter-worker.js");
worker.postMessage({ hugeDataset, threshold });
worker.onmessage = (e) => render(e.data.filtered);

// filter-worker.js — runs on its own thread
self.onmessage = (e) => {
  const { hugeDataset, threshold } = e.data;
  const filtered = hugeDataset.filter((row) => row.value > threshold).sort(compareFn);
  self.postMessage({ filtered });
};

The worker can't touch the DOM at all — no document, no window. It only computes, and hands the result back via postMessage.

Web workers: heavy work off the thread the UI needsStep 1 of 3

A heavy computation on the main thread blocks everything — the UI freezes until it finishes.

What people usually miss

Watch out

Workers don't share memory by default. Every message is a copy. (SharedArrayBuffer is the advanced exception, used rarely and carefully — most real usage relies on copying.)
Spinning up a worker has real overhead. For a cheap computation, the cost of creating the worker and copying data across can exceed whatever you'd save — the same "measure before optimizing" caution from the memoization lesson.
A worker can't read the DOM to gather its own input. Any "read something from the page, then compute" logic has to happen on the main thread first; only the pure computation part moves into the worker.
Web Workers and Service Workers are different things, commonly confused in interviews. A Web Worker runs background computation. A Service Worker sits between your app and the network — intercepting requests, enabling offline caching, and powering push notifications. Same "worker" name, unrelated jobs.

Why this matters in interviews — and why big companies care

At small scale, main-thread jank is invisible. At the scale of a spreadsheet app, a data dashboard, an image or video editor, or a code editor doing syntax highlighting on a huge file, that same jank becomes a measurable, user-visible stutter — and at millions of users, a 200ms freeze during scroll is a real, frequent complaint, not a rare edge case. Companies operating at that scale reach for workers specifically to keep expensive computation from ever blocking the frame that would otherwise drop.