A team proposes moving the app's data layer — parsing and transforming large API responses — into a Web Worker to eliminate long tasks on the main thread. How would you evaluate that proposal?

## What the proposal is actually claiming "Move the data layer to a worker" packs two claims together: that the expensive work is the parsing and transformation, and that moving it will make the page responsive. Both need evidence. Worker offloading is one of the few genuinely effective ways to remove main-thread work, and also one of the most reliable ways to add a lot of architecture for no measurable gain. The evaluation is about telling those cases apart before the migration, not after. ## Test one: is the work actually pure computation? A worker has no DOM. It cannot read `document`, measure an element, or touch anything that needs synchronous access to the page's object graph. Work that qualifies is self-contained: decode bytes, parse a format, filter and aggregate rows, run a diff, compute a layout of data (not of pixels), do crypto. Apply that honestly to "the data layer". If parsing is followed immediately by building DOM nodes or by a render pass, only the first half moves, and the second half — often the expensive half — stays exactly where it was. Teams discover this after the migration far more often than before it. ## Test two: what does the data cost to move? This is the test that decides most real cases. Values sent with `postMessage` are copied using the structured clone algorithm, and that copy is **work on the main thread** — serialization on the way out, deserialization on the way in. For a deep object graph of a few megabytes it is not free, and it is not obviously cheaper than the parse you were avoiding. Two shapes change the answer: - **Transferables.** An `ArrayBuffer`, `MessagePort` or `ImageBitmap` can be *transferred* rather than copied — ownership moves and the transfer is effectively free regardless of size, at the cost of the sender losing access. This is why binary pipelines (images, audio, columnar or packed data) are such good worker candidates and deep object graphs are not. - **Reduction in the worker.** If the worker returns a *summary* — a page of 50 rows, an aggregate, a prepared string — instead of the whole parsed structure, the clone cost collapses. A worker that parses 8 MB and returns 20 KB is an excellent trade. One that parses 8 MB and returns 8 MB has mostly relocated the problem. A useful framing: the worker should be where data gets *smaller*. ## Test three: does the access pattern fit? Everything across the boundary becomes asynchronous. If the current data layer is read synchronously from many call sites — selectors, computed values, render-time lookups — those all become promises, and a chatty pattern of many small round trips can feel slower than the synchronous version even though the main thread is doing less. Worker boundaries want coarse, batched, request-response interactions. If the API cannot be reshaped that way, the migration is fighting the design. ## Test four: the complexity budget Honest costs to put on the table: - the async boundary propagates outward through every caller and every test; - debugging spans two contexts, and errors must be serialized and re-thrown to be useful; - shared code may be bundled twice unless the build is set up carefully; - telemetry and error reporting need wiring into a context most tools instrument less well; - a fallback path is needed if worker creation fails, and worker startup is not instant. None of these are blockers. All of them are ongoing tax that the performance win has to exceed. ## Cheaper alternatives to consider first - **Do less work.** Request fewer fields, paginate, or transform on the server, where the CPU is not shared with the user's interface. This frequently beats offloading outright. - **Do it later.** Work not needed for the current view can be deferred past the interaction entirely. - **Do it incrementally.** Streaming or chunked processing keeps the thread interruptible without a second context. - **Cache.** The fastest transformation is the one that already ran. ## What I would require before saying yes 1. Field data showing which tasks are long, how long, and at which percentile and device class — not a laptop trace. 2. A prototype on the single worst path, measured end to end **including** the clone cost on both sides, compared against the current implementation. 3. A named payload shape at the boundary: what crosses, how large, and whether it can be transferable. 4. An answer for debugging, error reporting and the failure fallback. 5. A stated success criterion in user-visible terms — a responsiveness number at a real percentile — so the migration can be judged rather than admired. ## Where it clearly wins Say yes quickly when the workload is image, audio or video processing; cryptography; parsing or diffing large binary payloads; search indexing; spreadsheet-style recalculation; or model inference. All of these are CPU-heavy, DOM-free, and have inputs or outputs that are either small or transferable. That combination is the actual precondition — not the mere fact that something is slow.