Механика web workers: dedicated, shared и OffscreenCanvas

Вы знаете, что воркеры существуют. Но new Worker('script.js') создаёт dedicated-поток, умирающий с вкладкой — что делать, если пяти вкладкам нужно одно WebSocket-соединение, или WebGL-рендеринг должен пережить перегрузку главного потока?

Dedicated-воркеры

new Worker('worker.js') поднимает свежий JS-realm на своём OS-потоке, со своим event loop, своим глобалом (DedicatedWorkerGlobalScope) и без доступа к document, window или DOM. Он может использовать fetch, IndexedDB, WebSocket, OffscreenCanvas, таймеры, importScripts/ES-модули. Коммуникация — исключительно postMessage в обе стороны.

Воркер привязан к создавшей его странице: закройте вкладку — и воркер умирает. Используйте его для всего CPU-bound, что иначе пробило бы бюджет задачи 50 мс — парсинг больших JSON-payload-ов, фильтры изображений, криптографическое хеширование, диффинг, сжатие, подсветка синтаксиса, физика.

Ограничение same-origin. URL скрипта воркера должен быть same-origin (или blob-URL). Нельзя загрузить воркер прямо со стороннего CDN, не проксировав его через свой origin. Это та же origin-граница, что защищает остальную модель безопасности браузера.

Shared-воркеры

new SharedWorker('s.js') создаёт воркер, разделяемый между всеми вкладками одного origin. Каждая вкладка коннектится через MessagePort, и воркер живёт, пока жива хоть одна вкладка — полезно для одного общего WebSocket-соединения или согласованного кеша между вкладками. Поддержка слабее, чем у dedicated-воркеров, и отладка тяжелее, потому что время жизни воркера отвязано от любой отдельной вкладки.

Module-воркеры

Опция { type: 'module' } меняет способ загрузки зависимостей:

• Classic-воркер — использует importScripts() для синхронной загрузки зависимостей.
• Module-воркер — использует обычный статический import. Это даёт tree-shaking, top-level await и тот же граф модулей, что и остальное приложение.

Module-воркеры — современный дефолт. Classic importScripts остаётся только для легаси-кода и случаев динамической сборки имени скрипта в рантайме.

OffscreenCanvas: единственная DOM-лазейка

Воркер не может тронуть DOM, но canvas — особый случай: bitmap-канвас не является частью DOM-дерева, это просто буфер пикселей. OffscreenCanvas — канвас, отвязанный от элемента <canvas>.

Паттерн:

1. Главный поток вызывает canvas.transferControlToOffscreen(), получает OffscreenCanvas.
2. Передаёт его воркеру через transfer-список postMessage.
3. Воркер получает 2D-контекст или WebGL-контекст и рисует целиком на своём потоке.
4. Браузер отражает результат в видимый <canvas> — без участия главного потока.

Это делает возможными плавные 60 fps WebGL-визуализации, рендеринг карт и игры даже когда главный поток забит.

Воркер также может создать standalone new OffscreenCanvas(w, h) чисто для off-screen рендеринга — генерации текстур, обработки изображений — и вернуть результат как transferable ImageBitmap.

Ограничение исключительности. OffscreenCanvas, чей контроль был передан, нельзя также рисовать из главного потока — владение эксклюзивно, ровно как у переданного ArrayBuffer. Если оба потока должны рисовать, нужны два canvas или другая архитектура; платформа намеренно запрещает двум потокам гонку на одном bitmap.