Jak web workery i service workery mogą zwiększyć wydajność witryny oraz kiedy używać web workera, a kiedy service workera.
W tym ogólnym omówieniu wyjaśniamy, jak web workery i service workery mogą poprawić wydajność witryny oraz kiedy używać web workera, a kiedy service workera. Zapoznaj się z pozostałymi artykułami z tej serii, aby poznać konkretne wzorce komunikacji między oknem a usługą.
Jak pracownicy mogą poprawić Twoją witrynę
Przeglądarka używa jednego wątku (głównego wątku) do wykonywania całego kodu JavaScript na stronie internetowej, a także do wykonywania takich zadań jak renderowanie strony i usuwanie elementów z pamięci podręcznej. Wykonywanie nadmiernej ilości kodu JavaScript może blokować wątek główny, opóźniać wykonywanie tych zadań przez przeglądarkę i pogarszać wrażenia użytkownika.
W przypadku tworzenia aplikacji na iOS/Androida często stosuje się wzór, który zapewnia, że główny wątek aplikacji pozostaje wolny, aby reagować na zdarzenia użytkownika. Polega on na przekierowywaniu operacji do dodatkowych wątków. W najnowszych wersjach Androida blokowanie wątku głównego przez zbyt długi czas powoduje awarię aplikacji.
W internecie język JavaScript został zaprojektowany z myślą o pojedynczym wątku i nie ma funkcji potrzebnych do implementacji modelu wielowątkowego, takiego jak w aplikacjach, np. współdzielonej pamięci.
Pomimo tych ograniczeń podobny wzór można osiągnąć w internecie, używając wątków do wykonywania skryptów w tłach, co pozwala im wykonywać zadania bez zakłócania wątku głównego. Workery to cały zakres JavaScriptu działający w osobnym wątku bez żadnej pamięci współdzielonej.
Z tego artykułu dowiesz się więcej o 2 różnych typach wątków (workers) (workers web i workers service), ich podobieństwach i różnicach oraz najpopularniejszych wzorcach ich używania w witrynach produkcyjnych.
Procesy internetowe i skrypty service worker
Podobieństwa
skrypty web worker i skrypty service worker to 2 rodzaje skryptów dostępnych dla witryn. Mają one kilka cech wspólnych:
- Oba wątki działają w wątku dodatkowym, co pozwala na wykonywanie kodu JavaScript bez blokowania głównego wątku ani interfejsu użytkownika.
- Nie mają dostępu do obiektów
WindowiDocument, więc nie mogą bezpośrednio wchodzić w interakcje z DOM-em, a ich dostęp do interfejsów API przeglądarki jest ograniczony.
Różnice
Można sądzić, że większość zadań, które można zlecić procesowi wątek internetowy, można też wykonać w procesie workera usługi i odwrotnie, ale istnieją między nimi ważne różnice:
- W przeciwieństwie do procesów w tle workery usługowe umożliwiają przechwytywanie żądań sieciowych (za pomocą zdarzenia
fetch) i nasłuchiwanie w tle zdarzeń interfejsu API Push (za pomocą zdarzeniapush). - Strona może tworzyć wiele procesów web worker, ale tylko jeden skrypt service worker steruje wszystkimi aktywnymi kartami w ramach zakresu, w którym został zarejestrowany.
- Czas życia web workera jest ściśle powiązany z kartą, do której należy, a czas życia service workera jest niezależny od karty. Dlatego zamknięcie karty, na której działa web worker, spowoduje jego zakończenie, podczas gdy skrypt service worker może nadal działać w tle, nawet jeśli w witrynie nie ma żadnych aktywnych kart.
Przypadki użycia
Różnice między tymi dwoma typami pracowników sugerują, w jakich sytuacjach warto użyć jednego lub drugiego:
Przypadki użycia web workerów są częściej związane z przekazywaniem pracy (np. ciężkich obliczeń) do wątku pomocniczego, aby uniknąć blokowania interfejsu użytkownika.
- Przykład: zespół, który stworzył grę PROXX, chciał pozostawić główny wątek możliwie wolnym, aby zająć się danymi wejściowymi użytkownika i animowanymi elementami. Aby to osiągnąć, użyli elementów Web Workers do obsługi logiki gry i zarządzania stanem w oddzielnym wątku.
Zadanie service workera jest zazwyczaj związane z działaniem jako serwera proxy sieciowego, obsługą zadań w tle oraz takimi funkcjami jak buforowanie i praca offline.
Przykład: w PWA z podcastami możesz zezwolić użytkownikom na pobieranie pełnych odcinków, aby mogli słuchać ich 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 oknem a pracownikiem można zaimplementować, korzystając z różnych interfejsów API niższego poziomu. Na szczęście istnieją biblioteki, które abstrahują ten proces, obsługując najczęściej występujące przypadki użycia. W tej sekcji omówimy 2 z nich, które obsługują odpowiednio okna dla web workers i service workers: Comlink i Workbox.
Comlink
Comlink to niewielka (1,6 tys.) biblioteka RPC, która zajmuje się wieloma szczegółami podrzędnymi podczas tworzenia witryn korzystających z Web Workers. Jest on używany w witrynach takich jak PROXX i Squoosh. Omówienie motywacji i przykłady kodu znajdziesz tutaj.
Workbox
Workbox to popularna biblioteka do tworzenia stron internetowych, które korzystają z usług dla robotów. Zawiera on zestaw sprawdzonych metod dotyczących takich kwestii jak buforowanie, tryb offline, synchronizacja w tle itp. Moduł workbox-window zapewnia wygodny sposób wymiany wiadomości między usługą w tle a stroną.
Dalsze kroki
Pozostała część tej serii koncentruje się na wzorach komunikacji między oknem a usługą:
- Przewodnik po pamięci podręcznej imperatywnej: wywołanie skryptu service worker ze strony w celu wcześniejszego zapisania zasobów do pamięci podręcznej (np. w scenariuszach wstępnego pobierania).
- Wyświetlanie powiadomień: wywołanie strony z workera usługowego w celu poinformowania o ważnych aktualizacjach (np. o dostępnej nowej wersji witryny).
- Komunikacja dwukierunkowa: delegowanie zadania do service workera (np. duże pobieranie) i informowanie strony o postępach.
Aby poznać wzorce komunikacji między oknem a procesorem internetowym, przeczytaj artykuł Używanie procesów internetowych do uruchamiania kodu JavaScript poza wątkiem głównym przeglądarki.