Przegląd instancji roboczych

Jak mechanizmy robocze i service worker mogą zwiększyć wydajność witryny oraz kiedy stosować mechanizmy web worker, a kiedy service worker.

Andrew Guan

Demián Renzulli

W tym artykule omówiono, jak mechanizmy robocze i service worker mogą poprawić wydajność witryny oraz kiedy stosować mechanizmy web worker, a kiedy service worker. Zapoznaj się z resztą tej serii, aby poznać określone wzorce komunikacji między oknami i skryptami service worker.

Jak pracownicy mogą ulepszyć witrynę

Przeglądarka używa pojedynczego wątku (wątku głównego) do uruchamiania całego kodu JavaScriptu na stronie internetowej oraz wykonywania takich zadań jak renderowanie strony czy czyszczenie pamięci. Uruchomienie zbyt dużej ilości kodu JavaScript może zablokować wątek główny, co zwleka z wykonywaniem tych zadań przez przeglądarkę i pogorszy komfort korzystania z witryny.

W przypadku tworzenia aplikacji na iOS/Androida typowym wzorcem zapewniania, że główny wątek aplikacji pozostanie swobodny w reagowaniu na zdarzenia użytkownika, jest przeniesienie operacji do dodatkowych wątków. W najnowszych wersjach Androida blokowanie wątku głównego na zbyt długo prowadzi do awarii aplikacji.

W internecie JavaScript został zaprojektowany z myślą o pojedynczym wątku i nie ma funkcji niezbędnych do wdrożenia modelu wielowątkowości, takiego jak w przypadku konkretnej aplikacji, na przykład pamięci współdzielonej.

Pomimo tych ograniczeń podobny wzorzec można osiągnąć w internecie, używając instancji roboczych do uruchamiania skryptów w wątkach w tle, co pozwala wykonywać zadania bez zakłócania działania wątku głównego. Instancje robocze to cały zakres JavaScriptu działający w osobnym wątku, bez pamięci współdzielonej.

W tym poście poznasz 2 różne typy instancji roboczych (web-workingi), ich podobieństwa i różnice, a także najczęstsze wzorce używania ich w witrynach produkcyjnych.

Skrypty Web Worker i skrypty service worker

Podobieństwa

Instancje robocze i Skrypty service worker to 2 typy instancji roboczych dostępne dla witryn. Są pewne cechy wspólne:

• Oba działają w wątku dodatkowym, co umożliwia wykonywanie kodu JavaScript bez blokowania wątku głównego i interfejsu.
• Nie mają dostępu do obiektów Window ani Document, więc nie mogą bezpośrednio korzystać z DOM i mają ograniczony dostęp do interfejsów API przeglądarek.

Różnice

Ktoś może pomyśleć, że większość czynności, które można przekazać do instancji roboczych, można wykonać w skrypcie service worker i odwrotnie, ale występują między nimi istotne różnice:

• Inaczej niż w przypadku instancji roboczych, mechanizmy Service Worker umożliwiają przechwytywanie żądań sieciowych (za pomocą zdarzenia fetch) i nasłuchiwanie zdarzeń Push API w tle (za pomocą zdarzenia push).
• Strona może powodować utworzenie wielu instancji roboczych, ale pojedynczy skrypt service worker kontroluje wszystkie aktywne karty w ramach zakresu, do którego została zarejestrowana.
• Czas życia zasobu roboczego jest ściśle powiązany z kartą, do której należy, a cykl życia instancji roboczej jest od niego niezależny. Dlatego zamknięcie karty, na której działa mechanizm internetowy, spowoduje jego zakończenie, a skrypt service worker może działać w tle, nawet jeśli w witrynie nie są otwarte żadne aktywne karty.

Przykłady zastosowań

Różnice między tymi dwoma typami instancji roboczych wskazują, w jakich sytuacjach lepiej skorzystać z jednej z tych sytuacji:

Przypadki użycia zasobów internetowych są częściej związane z przenoszeniem zadań (np. ciężkich obliczeń) do wątku dodatkowego, aby uniknąć zablokowania interfejsu.

• Przykład: zespół, który stworzył grę wideo PROXX, chciał, aby główny wątek był jak najwolniejszy, aby zająć się wprowadzaniem użytkowników i animacjami. W tym celu wykorzystali narzędzia internetowe do uruchomienia logiki gry i konserwacji stanu w osobnym wątku.

Zadania service worker są bardziej związane z funkcjonowaniem serwerów proxy sieci, obsługą zadań w tle oraz takimi jak buforowanie danych czy tryb offline.

Przykład: w podcastu PWA możesz zezwolić użytkownikom na pobieranie pełnych odcinków do słuchania offline. Można do tego 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 będzie trzeba przerywać.

Narzędzia i biblioteki

Komunikację między oknami i instancjami roboczymi można zaimplementować za pomocą różnych interfejsów API niższego poziomu. Na szczęście istnieją biblioteki, które zajmują się abstrakcjami tego procesu, obsługując typowe przypadki użycia. W tej sekcji omawiamy 2 z nich, które odpowiednio obsługują mechanizmy sieciowe i serwisowe: Comlink i Workbox.

Comlink

Comlink to mała biblioteka RPC (o rozmiarze 1,6 tys.), która zajmuje się wieloma kluczowymi kwestiami związanymi z tworzeniem witryn używających procesów Web Workers. Jest używany w takich witrynach jak PROXX i Squoosh. Podsumowanie motywacji i przykłady kodu znajdziesz tutaj.

Workbox

Pole robocze to popularna biblioteka do tworzenia witryn korzystających z mechanizmów Service Worker. Zawiera zestaw sprawdzonych metod dotyczących takich aspektów jak buforowanie, tryb offline, synchronizacja w tle itp. Moduł workbox-window zapewnia wygodny sposób wymiany wiadomości między skryptem service worker a stroną.

Dalsze kroki

Pozostała część tej serii skupia się na wzorcach komunikacji okien i skryptów service worker:

• Przewodnik po buforowaniu: wywoływanie skryptu service worker ze strony w celu wcześniejszego buforowania zasobów (np. w sytuacjach pobierania z wyprzedzeniem).
• Transmitowanie aktualizacji: wywołanie strony z skryptu service worker w celu poinformowania o ważnych aktualizacjach (np. że jest dostępna nowa wersja witryny).
• Komunikacja dwukierunkowa: przekazywanie zadania skryptowi service worker (np. bardzo częste pobieranie pliku) i informowanie strony o postępach.

Wzorce komunikacji między oknami i instancjami roboczymi znajdziesz w artykule: Uruchamianie JavaScriptu z głównego wątku przeglądarki za pomocą narzędzi internetowych.