Web Workers
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).