Reference · print-friendly

Web Workers decision playbook

One page for design reviews. Walk gates top to bottom; stop when a row rejects the current candidate.

← Lesson 6 Integration checklist Messaging cost Glossary

Gate A · Is the main thread the problem?

If…	Prefer…
Work already fits interaction/frame budgets on target devices	Stay on main; measure first
Bottleneck is layout/paint/React commit, not pure JS	Main-thread render work — workers can’t fix DOM cost
Long pure compute/parse freezes input	Dedicated worker (or yield/chunk if simpler)
Offline / cache / push / request intercept	Service worker — different tool

Gate B · Which concurrency tool?

If…	Prefer…
One page; offload CPU / pure data work	Dedicated `Worker`
Tabs only need to notify each other	`BroadcastChannel`
One shared process (one socket, shared engine, multi-window hub)	`SharedWorker` (same origin; verify support)
Network proxy / offline shell	Service Worker

Gate C · Message & capability design

If…	Plan…
Need DOM / window / framework render in the “worker”	Split pure core → worker; keep render on main — or reject
Small control messages / modest state	Structured clone `postMessage`
Large binary you won’t need again on sender	Transfer (`ArrayBuffer` in transfer list)
Huge or high-frequency logical state	Patches / chunking — not full-state clone every tick
Multi-job worker	Typed messages + correlation `id` + `onerror`

Gate D · Integration (FE-visible)

Bundler: new Worker(new URL("./w.js", import.meta.url)) / Vite ?worker
Same-origin worker script (or known CORS story)
Lifecycle: create once / reuse; terminate() on unmount; SharedWorker port hygiene
Spec mindset: workers are relatively heavy — not one per keystroke
Debug: worker DevTools; named workers; error paths tested

Review sentence

“We use main | dedicated | shared | BroadcastChannel | SW because problem class; messages are clone | transfer | patches; we own lifecycle + bundler + one risk.”