Web Workers Don't Make JavaScript Faster — They Keep the UI Thread Breathing
Developers who treat Workers as a general speed-up will ship slower code. The right use is isolating tasks that would otherwise block the UI, not micro-optimizing every calculation.
A Web Worker runs scripts in a separate thread with its own V8 isolate and event loop, communicating with the main thread asynchronously via postMessage. The payoff is a responsive UI during heavy computation, not raw speed. Spinning up a Worker incurs a cold-start cost of tens to hundreds of milliseconds as the browser creates a new JS environment, loads, parses, and compiles the worker script. Every postMessage round-trip adds further overhead, even for small payloads. For lightweight calculations, the main thread finishes faster because it skips these setup and communication taxes. The real value is keeping DOM rendering and interaction smooth when work is genuinely heavy. Multiple Workers can parallelize work, but Chrome caps them around eight, and the OS scheduler will queue excess threads. Each Worker also consumes significant memory through its isolated heap. A practical ceiling is Math.max(2, navigator.hardwareConcurrency - 1) to avoid thrashing CPU and memory.
The mental model of 'Worker equals faster' is backwards: the main thread often wins on speed for small tasks because it skips the cold-start and serialization tax. Workers are a UI-responsiveness tool, not a performance accelerator.
Browser thread limits and per-isolate memory costs make Worker pools a constrained resource, not an elastic one. Over-provisioning punishes performance through OS scheduling and memory pressure, which is the opposite of what a naive 'just parallelize it' approach expects.
The postMessage bridge is a bottleneck that turns fine-grained parallelism into an anti-pattern. The overhead per message means batching work into fewer, larger messages is essential, yet the API's simplicity hides this.
navigator.hardwareConcurrency offers a logical core count, but the usable Worker ceiling is lower because the OS, browser, and other tabs all compete for the same physical threads. The recommended formula acknowledges this contention explicitly.