Jak skrypty web worker i service worker mogą zwiększyć wydajność witryny oraz kiedy używać skryptu web worker, a kiedy skryptu service worker.
Z tego artykułu dowiesz się, jak web workerzy i service workerzy mogą poprawić wydajność Twojej witryny oraz kiedy używać web workera, a kiedy service workera. Więcej informacji o konkretnych wzorcach komunikacji między oknem a procesem service worker znajdziesz w pozostałych filmach z tej serii.
Jak pracownicy mogą ulepszyć Twoją witrynę
Przeglądarka używa jednego wątku (głównego wątku) do uruchamiania całego kodu JavaScript na stronie internetowej, a także do wykonywania zadań takich jak renderowanie strony i odśmiecanie pamięci. Wykonywanie zbyt dużej ilości kodu JavaScript może blokować wątek główny, opóźniając wykonywanie tych zadań przez przeglądarkę i pogarszając wrażenia użytkownika.
W przypadku tworzenia aplikacji na iOS i Androida powszechnym wzorcem zapewniającym, że główny wątek aplikacji pozostaje wolny i może odpowiadać na zdarzenia użytkownika, jest przenoszenie operacji do dodatkowych wątków. W najnowszych wersjach Androida zbyt długie blokowanie wątku głównego prowadzi do awarii aplikacji.
W internecie JavaScript został zaprojektowany z myślą o jednym wątku i nie ma możliwości potrzebnych do wdrożenia modelu wielowątkowego, takiego jak w aplikacjach, np. pamięci współdzielonej.
Pomimo tych ograniczeń podobny wzorzec można uzyskać w internecie, używając procesów roboczych do uruchamiania skryptów w wątkach w tle, co pozwala im wykonywać zadania bez zakłócania działania głównego wątku. Worker to cały zakres JavaScriptu działający w osobnym wątku bez pamięci współdzielonej.
Z tego posta dowiesz się o 2 rodzajach instancji roboczych (web worker i service worker), ich podobieństwach i różnicach oraz najczęstszych wzorcach ich używania na stronach produkcyjnych.
Procesy internetowe i skrypty service worker
Podobieństwa
Skrypty web worker i service worker to 2 typy skryptów dostępne dla witryn. Mają kilka cech wspólnych:
- Oba działają w wątku dodatkowym, co umożliwia wykonywanie kodu JavaScript bez blokowania wątku głównego i interfejsu użytkownika.
- Nie mają dostępu do obiektów
WindowiDocument, więc nie mogą bezpośrednio wchodzić w interakcję z DOM i mają ograniczony dostęp do interfejsów API przeglądarki.
Różnice
Można by pomyśleć, że większość zadań, które można przekazać do wątku roboczego, można wykonać w usłudze Service Worker i odwrotnie, ale istnieją między nimi istotne różnice:
- W przeciwieństwie do web workerów service workery umożliwiają przechwytywanie żądań sieciowych (za pomocą zdarzenia
fetch) i nasłuchiwanie zdarzeń Push API w tle (za pomocą zdarzeniapush). - Strona może uruchamiać wiele skryptów web worker, ale jeden skrypt service worker steruje wszystkimi aktywnymi kartami w zakresie, w którym został zarejestrowany.
- Okres istnienia web workera jest ściśle powiązany z kartą, do której należy, natomiast cykl życia service workera jest od niego niezależny. Dlatego zamknięcie karty, na której działa web worker, spowoduje jego zakończenie, natomiast skrypt service worker może działać w tle nawet wtedy, gdy witryna nie ma otwartych żadnych aktywnych kart.
Przypadki użycia
Różnice między tymi dwoma typami instancji roboczych wskazują, w jakich sytuacjach warto użyć jednego z nich:
Przypadki użycia web workerów są częściej związane z przenoszeniem pracy (np. obliczeń) do wątku pomocniczego, aby uniknąć blokowania interfejsu.
- Przykład: zespół, który stworzył grę wideo PROXX, chciał, aby główny wątek był jak najmniej obciążony, aby można było obsługiwać dane wejściowe użytkownika i animacje. W tym celu użyli procesów roboczych, aby uruchomić logikę gry i zarządzanie stanem w osobnym wątku.
Zadania service workerów są zwykle bardziej związane z działaniem jako serwer proxy sieci, obsługą zadań w tle oraz takimi kwestiami jak buforowanie i praca w trybie offline.
Przykład: w progresywnej aplikacji internetowej do podcastów można zezwolić użytkownikom na pobieranie całych odcinków, aby mogli ich słuchać offline. W tym celu można użyć skryptu service worker, a w szczególności interfejsu Background Fetch API. Dzięki temu, jeśli użytkownik zamknie kartę podczas pobierania odcinka, zadanie nie zostanie przerwane.
Narzędzia i biblioteki
Komunikację między oknami i procesami roboczymi można zaimplementować za pomocą różnych interfejsów API niższego poziomu. Na szczęście istnieją biblioteki, które upraszczają ten proces i obsługują najczęstsze przypadki użycia. W tej sekcji omówimy 2 z nich, które obsługują odpowiednio okna do wątków internetowych i wątki usług: Comlink i Workbox.
Comlink
Comlink to niewielka (1,6 KB) biblioteka RPC, która zajmuje się wieloma szczegółami podczas tworzenia witryn korzystających z Web Workers. Jest on używany w witrynach takich jak PROXX i Squoosh. Podsumowanie motywacji i przykładowe fragmenty kodu znajdziesz tutaj.
Workbox
Workbox to popularna biblioteka do tworzenia stron internetowych, które korzystają z service workerów. Zawiera zestaw sprawdzonych metod dotyczących m.in. buforowania, trybu offline i synchronizacji w tle. Moduł workbox-window umożliwia wygodną wymianę wiadomości między service workerem a stroną.
Dalsze kroki
Pozostałe części tej serii skupiają się na wzorcach komunikacji między oknem a procesem service worker:
- Przewodnik po buforowaniu imperatywnym: wywoływanie skryptu service worker ze strony w celu wcześniejszego buforowania zasobów (np. w scenariuszach wstępnego pobierania).
- Rozsyłanie aktualizacji: wywoływanie strony z poziomu service workera w celu informowania o ważnych aktualizacjach (np. o dostępności nowej wersji witryny).
- Komunikacja dwukierunkowa: delegowanie zadania do komponentu Service Worker (np. pobieranie dużego pliku) i informowanie strony o postępach.
Wzorce komunikacji między oknem a procesem roboczym znajdziesz w artykule Używanie procesów roboczych do uruchamiania JavaScriptu poza głównym wątkiem przeglądarki.