Jak skrypty web worker i service worker mogą poprawić wydajność witryny oraz kiedy używać skryptu web worker, a kiedy service worker.
Z tego omówienia dowiesz się, jak skrypty web worker i service worker mogą poprawić wydajność witryny oraz kiedy używać skryptu web worker, a kiedy service worker. Zapoznaj się z pozostałymi artykułami z tej serii, aby poznać konkretne wzorce komunikacji między oknem a skryptem service worker.
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 zbieranie nieużytków. Uruchamianie nadmiernej ilości kodu JavaScript może blokować główny wątek, opóźniając wykonywanie tych zadań przez przeglądarkę i pogarszając wrażenia użytkownika.
W przypadku tworzenia aplikacji na iOS/Androida typowym wzorcem zapewniającym, że główny wątek aplikacji będzie mógł 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 powoduje awarię aplikacji.
W internecie JavaScript został zaprojektowany wokół koncepcji pojedynczego wątku i nie ma możliwości potrzebnych do wdrożenia modelu wielowątkowego, takiego jak w aplikacjach, np. pamięci współdzielonej.
Mimo tych ograniczeń podobny wzorzec można osiągnąć w internecie, używając skryptów do uruchamiania skryptów w wątkach w tle, co pozwala im wykonywać zadania bez zakłócania głównego wątku. Skrypty service worker to cały zakres JavaScriptu działający w osobnym wątku, bez współdzielonej pamięci.
W tym poście dowiesz się o 2 różnych typach instancji roboczych (instancje robocze i skrypty service worker), ich podobieństwach i różnicach oraz najczęstszych wzorcach ich używania w witrynach produkcyjnych.
Internetowe instancje robocze i skrypty service worker
Podobieństwa
Skrypty web worker i service worker to 2 typy skryptów instancji roboczych dostępnych dla witryn. Mają kilka wspólnych cech:
- Oba działają w wątku pomocniczym, co umożliwia wykonywanie kodu JavaScript bez blokowania wątku głównego i interfejsu.
- Nie mają dostępu do obiektów
WindowiDocument, więc nie mogą bezpośrednio wchodzić w interakcje z DOM i mają ograniczony dostęp do interfejsów API przeglądarki.
Różnice
Można by pomyśleć, że większość rzeczy, które można przekazać do wątku roboczego, można wykonać w skrypcie service worker i na odwrót, ale istnieją między nimi istotne różnice:
- W przeciwieństwie do skryptów web worker skrypty service worker umożliwiają przechwytywanie żądań sieciowych (za pomocą zdarzenia
fetch) i nasłuchiwanie zdarzeń interfejsu Push API w tle (za pomocą zdarzeniapush). - Strona może wygenerować wiele instancji Web Worker, ale pojedyncza instancja Service Worker kontroluje wszystkie aktywne karty w zakresie, w którym została zarejestrowana.
- Cykl życia skryptu web worker jest ściśle powiązany z kartą, do której należy, natomiast cykl życia skryptu service worker jest od niej niezależny. Z tego powodu zamknięcie karty, na której działa skrypt web worker, spowoduje jego zakończenie, podczas gdy skrypt service worker może nadal działać w tle, nawet jeśli witryna nie ma otwartych żadnych aktywnych kart.
Przypadki użycia
Różnice między tymi dwoma typami instancji roboczych sugerują, w jakich sytuacjach warto użyć jednego lub drugiego:
Przypadki użycia skryptów web worker są częściej związane z przenoszeniem zadań (takich jak ciężkie obliczenia) 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 mógł obsługiwać dane wejściowe użytkownika i animacje. Aby to osiągnąć, użyli skryptów Web Worker do uruchamiania logiki gry i utrzymywania stanu w osobnym wątku.
Zadania skryptów service worker są zwykle bardziej związane z działaniem jako serwer proxy sieci, obsługą zadań w tle oraz takimi kwestiami jak buforowanie i tryb offline.
Przykład: w aplikacji PWA z podcastami 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 oknem a procesem roboczym można zaimplementować za pomocą różnych interfejsów API niższego poziomu. Na szczęście istnieją biblioteki, które upraszczają ten proces, obsługując najczęstsze przypadki użycia. W tej sekcji omówimy 2 z nich, które obsługują odpowiednio komunikację między oknem a skryptami Web Worker i skryptami Service Worker: Comlink i Workbox.
Comlink
Comlink to niewielka (1,6 kB) biblioteka RPC, która dba o wiele szczegółów podczas tworzenia witryn korzystających z Web Workers. Został on użyty w witrynach takich jak PROXX i Squoosh. Podsumowanie motywacji i przykładowe kody znajdziesz tutaj.
Workbox
Workbox to popularna biblioteka do tworzenia witryn korzystających z skryptów service worker. 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 skryptem service worker a stroną.
Dalsze kroki
W pozostałej części tej serii skupimy się na wzorcach komunikacji między oknem a skryptem service worker:
- Przewodnik po imperatywnym buforowaniu: wywoływanie skryptu service worker ze strony w celu wcześniejszego buforowania zasobów (np. w scenariuszach pobierania z wyprzedzeniem).
- Przesyłanie aktualizacji: wywoływanie strony z poziomu skryptu service worker w celu poinformowania o ważnych aktualizacjach (np. o dostępności nowej wersji witryny).
- Komunikacja dwukierunkowa: delegowanie zadania do skryptu 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 kodu JavaScript poza głównym wątkiem przeglądarki.