Web Workers
debt(d7/e5/b3/t5)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints list chrome-devtools and lighthouse, which can flag long synchronous tasks and poor INP scores, but these tools catch symptoms (UI jank, slow INP) rather than directly flagging 'you should use a Web Worker here.' A developer must interpret profiler output and recognize that the bottleneck is CPU-bound and off-threadable — this requires careful analysis rather than an automated fix suggestion. Slightly better than d9 because Lighthouse/DevTools do surface the evidence.
Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix says 'offload CPU-intensive tasks to Web Workers,' but this is not a one-line patch. It requires creating a worker file, restructuring the computation to be message-based (postMessage back and forth), handling transferable objects, managing worker lifecycle, and updating the calling code — spanning at least two files and a meaningful refactor. Not quite a cross-cutting architectural rework (e7), but clearly more than a small parameterised fix.
Closest to 'localised tax' (b3). Web Workers apply only to web contexts and only to specific CPU-intensive tasks within a component. Once implemented correctly, the rest of the codebase is largely unaffected. The worker pattern is self-contained — a worker file plus a manager — so future maintainers pay a modest overhead understanding the postMessage boundary but it doesn't shape the entire codebase.
Closest to 'notable trap' (t5). The misconception field explicitly states that developers believe Web Workers speed up all JavaScript, when they only help CPU-bound tasks — I/O-bound async operations gain nothing. Additionally, common_mistakes highlight DOM access attempts (workers have no DOM) and cloning vs. transferring large objects. These are documented, well-known gotchas that most developers encounter and learn, placing this squarely at t5 rather than a more severe trap level.
Also Known As
TL;DR
Explanation
Web Workers run in a separate thread with no access to the DOM. Communication is via postMessage/onmessage with structured clone serialisation. Use for: heavy computation (image processing, encryption, data parsing), running WASM modules, and large data transformations. Service Workers are a specialised type for network interception. SharedArrayBuffer enables shared memory between workers (requires COOP/COEP headers). Workers solve the 'why does my page freeze?' problem for CPU-intensive code.
Common Misconception
Why It Matters
Common Mistakes
- Trying to access the DOM from a worker — workers have no DOM access; pass data back via postMessage.
- Transferring large objects by clone instead of transfer — use Transferable objects (ArrayBuffer) to move memory without copying.
- Creating workers inside loops — each worker has overhead; create a pool and reuse workers.
- Not terminating workers when done — idle workers consume memory and CPU resources.
Code Examples
// CPU-intensive task on main thread — freezes UI:
btn.addEventListener('click', () => {
const result = processLargeDataset(millionRows); // Blocks UI for seconds
displayResult(result);
});// Offload to Web Worker — UI stays responsive:
// worker.js:
self.onmessage = ({ data }) => {
const result = processLargeDataset(data.rows);
self.postMessage({ result });
};
// main.js:
const worker = new Worker('worker.js');
btn.addEventListener('click', () => {
worker.postMessage({ rows: millionRows }); // Non-blocking
});
worker.onmessage = ({ data }) => displayResult(data.result);