Web Workers vs Service Workers — różnica?

Web Worker to wątek do obliczeń, działa tylko w trakcie sesji (zamykanej z kartą). Service Worker to proxy między przeglądarką a siecią — żyje też po zamknięciu karty, służy do cache, offline mode i push notifications. Różne narzędzia do różnych problemów.

Kiedy warto wdrożyć Worker, a kiedy to przerost formy?

Warto, gdy masz konkretny long task > 100 ms na main threadzie (widoczne w DevTools → Performance → czerwone bloki). Dla operacji poniżej 50 ms narzut komunikacji często przewyższa zysk. Reguła: najpierw zmierz w DevTools, potem optymalizuj.

Czy Workery są wspierane przez wszystkie przeglądarki?

Tak, podstawowe Web Workers — od dawna we wszystkich nowoczesnych przeglądarkach. Module workers (ESM imports w workerze) — Chrome od 80, Firefox od 114, Safari od 15. SharedArrayBuffer (pamięć dzielona między wątkami) wymaga CORS isolation (headers COOP + COEP).

Czy można używać Workerów z Next.js?

Tak — Next.js wspiera workery przez webpack. Wystarczy new Worker(new URL('./worker.ts', import.meta.url)) . Można też używać bibliotek typu Comlink, które abstrahują postMessage i pozwalają wywołać metody workera tak, jakby były lokalne. Działa w SSR i SSG, ale worker odpala się tylko po stronie klienta.

Web Workers — SEOGods

Web Workers to mechanizm uruchamiania JavaScriptu w osobnym wątku, równolegle do głównego wątku przeglądarki. Pozwala wykonywać ciężkie obliczenia bez blokowania UI — czyli bez psucia INP i bez „zamrażania" strony podczas operacji wymagających mocy CPU.

Jak działają

Worker to osobny plik .js uruchamiany przez new Worker('worker.js'). Główny wątek i worker komunikują się przez postMessage() — przesyłają dane jako kopie (lub Transferable Objects dla wydajności przy dużych payloadach). Worker nie ma dostępu do DOM, window ani document — tylko do API niezależnych od głównego wątku (fetch, IndexedDB, Crypto, WebSocket).

Klasyczne zastosowania

Ciężkie obliczenia: kompresja obrazów, parsowanie dużych JSON (powyżej kilku MB), kryptografia, algorytmy ML w przeglądarce (TensorFlow.js, ONNX Runtime).
Third-party heavy libs: charting libs, edytory tekstu, parsery markdown — przeniesienie do workera odciąża main thread.
Service Workers (osobny typ) — cache, offline mode, push notifications, PWA.
Background sync: wysyłanie danych do API niezależnie od interakcji użytkownika.

Jak wpływają na Core Web Vitals

Główny zysk to INP. Long tasks (powyżej 50 ms) na main threadzie blokują reakcję na interakcje — przeniesienie ich do workera eliminuje problem. Dodatkowy zysk: LCP, bo główny wątek może szybciej renderować pierwszą warstwę. CLS bez zmian — workery nie dotykają DOM.

Kompromisy

Komunikacja przez postMessage ma narzut serializacji — nie warto dla małych zadań (poniżej 50 ms). Worker nie widzi DOM — wszystkie zmiany UI muszą wrócić do main threada przez postMessage. Debug trudniejszy (osobny kontekst w DevTools). Nie każda biblioteka działa w workerze (zależne od window są out — np. starsze wersje jQuery).