Web worker mechanics: dedicated, shared, and OffscreenCanvas

You know workers exist. But new Worker('script.js') spawns a dedicated thread that dies with the tab — so what do you use when five tabs need the same WebSocket connection, or when WebGL rendering should survive main-thread saturation?

Dedicated workers

new Worker('worker.js') spins up a fresh JS realm on its own OS thread, with its own event loop, its own global (DedicatedWorkerGlobalScope), and no access to document, window, or the DOM. It can use fetch, IndexedDB, WebSocket, OffscreenCanvas, timers, and importScripts/ES modules. Communication is exclusively postMessage in both directions.

A worker is tied to the page that created it: close the tab and the worker dies. Use it for anything CPU-bound that would otherwise blow the 50 ms task budget — JSON parsing of large payloads, image filters, cryptographic hashing, diffing, compression, syntax highlighting, physics.

The same-origin constraint. The worker script URL must be same-origin (or a blob URL). You cannot load a worker straight from a third-party CDN without proxying it through your own origin first. This is the same origin boundary that protects the rest of the browser’s security model.

Shared workers

new SharedWorker('s.js') creates a worker that is shared across all tabs of the same origin. Each tab connects through a MessagePort, and the worker lives as long as any tab uses it — useful for one shared WebSocket connection or a coherent cross-tab cache. Support is weaker than dedicated workers (absent in some browser configurations) and debugging is harder, because the worker’s lifetime is decoupled from any single tab.

Module workers

The { type: 'module' } option changes how a worker loads its dependencies:

• Classic worker — uses importScripts() to load dependencies synchronously.
• Module worker — uses ordinary static import. This gives tree-shaking, top-level await, and the same module graph as the rest of the app.

Module workers are the modern default. Classic importScripts remains only for legacy code and cases that build the script name dynamically at runtime.

OffscreenCanvas: the one DOM carve-out

A worker cannot touch the DOM, but canvas is a special case — a canvas bitmap is not part of the DOM tree, it is just a pixel buffer. OffscreenCanvas is the canvas decoupled from a <canvas> element.

The pattern:

1. Main thread calls canvas.transferControlToOffscreen(), gets an OffscreenCanvas.
2. Transfers it to a worker through postMessage’s transfer list.
3. Worker gets a 2D or WebGL context and renders entirely on its own thread.
4. The browser reflects the result into the visible <canvas> — with no main-thread involvement.

This makes smooth 60 fps WebGL visualisations, map rendering, and games possible even while the main thread is saturated.

A worker can also create a standalone new OffscreenCanvas(w, h) purely for off-screen rendering — texture generation, image processing — and return the result as a transferable ImageBitmap.

The exclusivity constraint. An OffscreenCanvas whose control was transferred cannot also be drawn from the main thread — ownership is exclusive, exactly like a transferred ArrayBuffer. If both threads need to draw, you need two canvases or a different architecture; the platform deliberately forbids two threads racing on one bitmap.