Browser & Frontend Runtime
Workers: multiple-choice review
Crux Multiple-choice synthesis across the workers unit — thread isolation, clone vs transfer cost, service-worker lifecycle traps, the COOP/COEP gate, pool backpressure, and the DOM-in-a-worker mistake.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each one mirrors an architectural call you make under real load — which primitive fits, what it costs, and the failure mode it cannot solve — not a definition to recite.
Goal
Confirm you can pick the right worker primitive for a job, reason about its data-transfer cost, and recognise the lifecycle and isolation traps the three primitives cannot solve on their own.
Quiz
Completed
A teammate moves a slow React list re-render into a web worker to fix scroll jank, and nothing improves. Why, and what actually fixes it?
Heads-up Speed is not the issue — the worker literally cannot touch the DOM. React's commit writes real elements, which only the main thread owns. Compute can move; the commit cannot.
Heads-up There is no polyfill that gives a worker a DOM. The constraint is architectural: WorkerGlobalScope has no document. You move derivation off-thread and keep the commit on the main thread.
Heads-up OffscreenCanvas renders pixels, not a DOM list of elements. A virtualised React list is DOM nodes — the commit stays main-thread; only pure compute offloads.
Quiz
Completed
You postMessage a 40 MB Float32Array to a worker and the sending thread still freezes for ~40 ms before the worker even starts. Best fix?
Heads-up JSON.stringify of a 40 MB typed array is far slower than structured clone and produces a much larger string — it makes the block worse, not better.
Heads-up Total clone cost is the same 40 MB, now spread across 40 task hops with 40× the scheduling overhead. Transfer eliminates the copy entirely.
Heads-up SAB also avoids the copy, but it is for concurrent shared access and needs COOP+COEP. If the sender hands the data off and stops using it, transfer is the simpler, header-free fit.
Quiz
Completed
You deploy a new service worker, reload, and still get old behaviour with no error. The new worker installed fine. What is happening?
Heads-up The browser does fetch and install the new worker; it simply does not activate it over open pages by default. That is the waiting state, not a caching bug.
Heads-up Manual unregister is never required. skipWaiting() + clients.claim() hands off immediately; otherwise closing all tabs does too.
Heads-up The browser re-checks sw.js on navigation and installs the new worker — it just waits to activate. (Separately, serve sw.js with Cache-Control: no-cache so the re-check is never stale.)
Quiz
Completed
A multithreaded-WASM module silently runs single-threaded in production. typeof SharedArrayBuffer is 'undefined' and crossOriginIsolated is false; COOP: same-origin is set but COEP is not. What is the exact fix and its cost?
Heads-up Memory size is irrelevant — the module degrades because SharedArrayBuffer is undefined. SAB requires both isolation headers; only the missing COEP header unlocks it.
Heads-up No memory knob unlocks SAB. The gate is the COOP/COEP cross-origin-isolation pair, full stop.
Heads-up Transfer moves exclusive ownership — it cannot back threads that all read/write the same memory, which is exactly what pthreads need. The fix is unlocking SAB via COEP, not replacing it.
Quiz
Completed
A button triggers a 400 ms image job. Users click rapidly; the tab spawns a new worker per click, climbs to 400 MB, and gets killed on mobile. What is the right architecture?
Heads-up Terminating after every job throws away the worker and forces a fresh 5–20 ms startup on the next click. A persistent pool amortises startup; per-job spawn-and-kill does not.
Heads-up Chunking keeps input alive but the 400 ms still competes with rendering on one thread, and unbounded clicks still pile up. Pool + backpressure offloads the compute AND bounds the queue.
Heads-up You cannot raise the mobile memory ceiling, and leaking workers is the real bug. Bound the worker count with a pool and cap the queue with backpressure.
Quiz
Completed
A service worker intercepts navigation and serves the app shell cache-first. You ship a shell bug; some users hit the broken cached shell on every reload with no recovery button. What is the architectural defence?
Heads-up Ordinary users cannot or will not do this. Recovery has to be engineering-owned: network-first navigation plus a remote kill switch.
Heads-up A navigation-cache-first worker may serve the cached HTML before it ever checks for an update, so skipWaiting never gets a chance. Network-first navigation and a kill switch force the update path.
Heads-up The browser has no concept of a broken worker — a successful broken cached response looks identical to a correct one. You must build the recovery path in advance.
Recap
The through-line of the unit is one decision tree: pick the primitive by job — web worker for off-main-thread compute, service worker for the network proxy, SharedArrayBuffer for shared memory — then pay the right transport cost (clone for small data, transfer for large binary, SAB for concurrent access behind COOP+COEP). Around that, three traps recur: a worker cannot touch the DOM (so DOM mutation never offloads), a service worker waits before activating and is hard to recover when it breaks navigation, and pools need backpressure or they leak. None of the primitives fixes a main-thread DOM bottleneck — that work stays where the DOM lives.