Reference
60-second risk scan before green-lighting a dedicated worker in a design review. Capabilities from MDN — APIs in workers.
| Usually available | Not available / different |
|---|---|
fetch, timers, console,
IndexedDB, WebSockets, many file/canvas helpers
(e.g. createImageBitmap, OffscreenCanvas path)
|
DOM (document, nodes),
window as page window,
localStorage / sessionStorage (use
IDB), UI frameworks’ render trees
|
Always verify a specific API in the availability list / browser support — the list grows over time.
| Risk | Question | If red |
|---|---|---|
| DOM coupling | Does “the work” need elements, layout, or React state? | Keep on main, or split pure logic into worker |
| Tooling |
Can the bundler emit a worker URL
(new URL(..., import.meta.url) / Vite
?worker)?
|
Budget build config before coding features |
| Origin / CDN | Is the worker script same-origin (or properly CORS)? | Host worker with the app bundle; avoid random CDN worker scripts |
| Lifecycle | Who terminates on route change / tab close intent? | Define owner component + cleanup or you leak threads |
| Message protocol | Types, correlation ids, error messages defined? | Don’t ship fire-and-forget blobs for multi-job workers |
| Payload size | Peak message size / frequency under budget? | Transfer, patch, or chunk (lesson 3) |
| Debuggability | Can DevTools attach to the worker? Error path tested? |
Name workers; wire onerror /
messageerror
|
| Wrong tool | Is this offline/cache/push? | Service worker, not dedicated compute worker |