Worker pools, Comlink, and production observability

You moved the 400 ms image job to a worker. Then users start clicking rapidly and the page accumulates fifty pending jobs, each spawning a new worker that never gets cleaned up. The browser tab now uses 400 MB and is being killed on mobile.

When workers pay off — and when they do not

Spawning a worker is not free: a new realm, a new event loop, a fresh copy of any imported scripts — typically 5–20 ms of startup plus a few MB of memory. A worker is worth it when:

• The task is long (tens of ms or more), so startup is amortised.
• The result-transfer cost is small relative to the compute.

It is a net loss when the task is short — the postMessage round-trip and clone overhead can exceed the work itself.

For repeated small jobs: maintain a worker pool rather than spawning per job.

The worker pool

A pool amortises startup cost and bounds memory:

pool size = navigator.hardwareConcurrency − 1  // leave one core for main thread

Components:

1. N workers, created once and reused.
2. A job queue — pending work waiting for a free worker.
3. A dispatcher — on job arrival: if a worker is free, send it; otherwise enqueue.

The pool pattern eliminates repeated startup cost and bounds total worker memory.

Backpressure. Without a queue cap, the queue grows unboundedly under load. Two options:

• Drop the oldest enqueued jobs.
• Reject new jobs (return a rejected promise) so callers can back off.

Priority routing. Not all jobs are equal — a filter preview the user is waiting for right now outranks background thumbnail generation. Use a priority-tagged queue: interactive jobs skip background ones.

Cancellation. If the user scrolls away before a job completes, cancel it. For a queued job: remove it. For an in-progress job: the clean way is an atomic cancellation flag in a SharedArrayBuffer — the worker checks it periodically and exits early, keeping itself alive for the next job. The blunt way is worker.terminate() — but that destroys the worker, forcing a new spawn for the next job (back to paying startup cost).

The DOM-in-a-worker mistake

The single most common worker mistake is architectural: teams reach for a worker to “speed up rendering” and discover the worker cannot touch the DOM at all. A worker can compute what should render but never render it — the result must be posted back and applied by the main thread.

If the bottleneck is DOM mutation itself (10 000 nodes inserted, a giant React reconciliation), a worker does not help — the expensive part has to happen on the main thread regardless. Workers help when the bottleneck is pure computation that produces a small result:

• Parse 5 MB JSON (worker) → post back 200-row array (cheap) → main thread renders 200 rows (fast). ✓
• React reconciliation of 10 000 nodes (bottleneck is the commit, not derivation) — worker cannot help. ✗

The exception: OffscreenCanvas. Canvas rendering can be done from a worker. Transfer an OffscreenCanvas and the worker draws 2D or WebGL entirely off the main thread.

Comlink and the RPC illusion

Comlink makes await worker.heavyCompute(data) look like a local call by wrapping a worker in a Proxy. This is ergonomic, but the abstraction hides two costs that still matter:

1. Every argument is structured-cloned unless explicitly wrapped with Comlink.transfer.
2. Every call is a task hop each way — a round-trip message between threads.

The illusion breaks for chatty interfaces — a worker API with many small methods called in a tight loop pays a task hop per call and serialises the program on the round-trips. Design worker interfaces coarse: one call that does a batch of work and returns a batch of results, not many fine-grained calls. Same principle as network API design: minimise round-trips, maximise work per round-trip.

Production observability

Each worker and each service worker is a separate context in DevTools. Web workers appear in the Sources panel thread list. Service workers have a dedicated panel under Application → Service Workers.

Telemetry across threads:

• Instrument both sides of every postMessage with timestamps. Measure real task-hop latency and clone cost in production — local dev on a fast machine systematically understates both.
• Track service worker fetch-handler duration. A slow handler delays every navigation and resource load on the page, and because it runs before the main thread sees the response, a regression there is invisible to ordinary main-thread profiling.

Worker leak detection:

• A component that creates a worker in useEffect without terminating in the cleanup function leaks a worker on every remount. After a dozen navigations, you accumulate a pool of dead workers that nobody created intentionally.
• Profile with DevTools → Performance → Threads to see all active workers. Unexpected idle threads are leaks.