Wdrożenie skryptu service worker może w nieprzewidziany sposób zmienić zachowanie witryny. Ponieważ Workbox ułatwia zapisywanie i wdrażanie skryptu service worker, po wdrożeniu może być łatwo przeoczyć niektóre jego skutki na stronie internetowej.
Nie oznacza to, że korzystanie z pakietu Workbox nie przynosi oczekiwanych rezultatów, a wygoda, jaką zapewnia ta usługa, może ułatwić pokrycie przez nią problemów, jeśli nie wiemy, co wiążą się z wdrażaniem skryptu service worker.
Unikanie pułapek
Stosowanie wstępnego buforowania zostało omówione wcześniej w tych dokumentach, ale nie omówiliśmy w pełni możliwości, o jaki dana praktyka może się odwrócić. Jeśli zastosujesz wstępne działanie do zbyt wielu zasobów lub skrypt service worker zostanie zarejestrowany, zanim strona zdoła wczytać najważniejsze zasoby, mogą wystąpić problemy.
Domyślnym zachowaniem workbox-webpack-plugin jest instruowanie skryptu service worker, by automatycznie buforował wygenerowane zasoby, dlatego może to być problematyczne i łatwe do przeoczenia, ponieważ bariera wdrażania jest niska.
workbox-webpack-plugin.
W tym przykładzie wstępnie buforowane są 14 zasobów w bieżącym projekcie, które łącznie mają łącznie 352 kilobajty.Gdy skrypt service worker wstępnie przechowuje zasoby podczas instalacji, jedno lub kilka żądań sieciowych jest inicjowane jednocześnie. Nieodpowiednie ustawienie czasu może powodować problemy z wrażeniami użytkownika. Nawet wtedy, gdy czas jest ustawiony zgodnie z planem, w dalszym ciągu może się okazać, że zmarnujesz dane, jeśli ilość zasobów w pamięci podręcznej nie zostanie w jakiś sposób ograniczona.
Wszystko jest w odpowiednim czasie
Jeśli mechanizm Service Worker zapisuje coś w pamięci podręcznej, wtedy czas rejestracji ma znaczenie.
Skrypty service worker są często rejestrowane za pomocą wbudowanych elementów <script>.
Oznacza to, że parsery HTML mogą wykryć kod rejestracji skryptu service worker, zanim krytyczne zasoby strony zostaną wczytane.
Na tym polega problem. Skrypt service worker w najgorszych przypadkach powinien być neutralny pod względem wydajności – nie pogarsza go. Wyświadcz przysługę użytkownikom i zarejestruj skrypt service worker po uruchomieniu zdarzenia load na stronie.
Zmniejsza to ryzyko zakłócenia wczytywania najważniejszych zasobów strony w pamięci podręcznej, a to z kolei sprawia, że strona może działać szybciej, co eliminuje konieczność obsługi żądań sieciowych dotyczących zasobów, które i tak mogą nie być potrzebne później.
Pamiętaj o użyciu danych
Niezależnie od czasu wstępne buforowanie obejmuje wysyłanie żądań sieciowych. Jeśli plik manifestu zasobów do wstępnego buforowania nie jest starannie dobrany, może to oznaczać pewną ilość odpadów.
Marnowanie danych to potencjalny kompromis, ale nie każdy ma dostęp do szybkiego internetu czy nawet nieograniczonego abonamentu na transmisję danych. W przypadku wstępnego buforowania staraj się wycinać szczególnie duże zasoby i polegać na pamięci podręcznej w czasie działania, aby je przechwytywać. Nie musisz zakładać kosztownych założeń.
Uruchomienie skryptu service worker może opóźniać żądania sieciowe
Skrypty service worker są uruchamiane w innym procesie niż reszta kodu witryny. Ten proces często się rozpoczyna i zatrzymuje. Gdy skrypt service worker musi obsłużyć zdarzenie pobierania po nieaktywności, przeglądarka musi najpierw uruchomić go. Te dodatkowe nakłady pracy związane z obsługą żądania są niewielkie w porównaniu z korzyścią udostępniania odpowiedzi z pamięci podręcznej zamiast z sieci.
Gdy stosujesz strategie, które nie mogą udostępniać danych z pamięci podręcznej i muszą dotrzeć do sieci – zwłaszcza podczas obsługi żądań nawigacji – czas uruchamiania zawsze wiąże się z pewnym opóźnieniem. W zależności od możliwości urządzenia i ciśnienia pracy procesora żądanie nawigacji może znacznie opóźnić czas z powodu powolnego uruchamiania skryptu service worker. Wdrożenie skryptu service worker bez informowania o tym opóźnieniu może spowodować niezamierzone obniżenie wydajności.
Ten problem został rozwiązany za pomocą funkcji wstępnego wczytywania nawigacji, ale nie jest jeszcze obsługiwany we wszystkich przeglądarkach. Warto jednak wziąć pod uwagę jego zastosowanie, które zostało omówione w dalszej części tej dokumentacji.
Strategie koncentrujące się na pamięci podręcznej mogą działać niestabilnie
Strategie buforowania, które najpierw sprawdzają pamięć podręczną (lub tylko sprawdzają pamięć podręczną), świetnie sprawdzają się zarówno w przypadku dostępu offline, jak i wydajności. Jednak w niektórych przypadkach powodują problemy.
Buforowanie w czasie środowiska wykonawczego zasobów statycznych bez wersji
Pakiety zwykle tworzą wersje zasobów statycznych z hashtagiem opartym na treści w nazwie pliku (np. styles.a4edf38c.css).
W przypadku instancji service worker, które korzystają ze strategii buforowania, które sprawdzają zasoby statyczne w pamięci podręcznej, i używają strategii skoncentrowanej na sieci w przypadku znaczników stron, nie powinny występować problemy z pamięcią, ponieważ zaktualizowane zasoby odwołują się do znaczników, które są zawsze pobierane z sieci.
Problemy pojawiają się, gdy określone w ten sposób zasoby statyczne są przechowywane w pamięci podręcznej w czasie działania.
Jeśli funkcjonalność strony internetowej jest udostępniana przez app.js i używana jest strategia środowiska wykonawczego priorytetowego, app.js zostanie później zaktualizowana bez zmiany nazwy pliku, wersja z pamięci podręcznej nadal będzie pobierana z pamięci podręcznej, a nie z pamięci podręcznej.
Rozwiązaniem jest użycie strategii, która konsultuje się z siecią w poszukiwaniu aktualizacji, np. najpierw działających na sieci lub nieaktualnej podczas ponownej weryfikacji. Narzędzia do kompilacji mogą też wygenerować dla tych zasobów plik manifestu wstępnego buforowania, ponieważ logika wstępnego buforowania w boksie Workbox zapewnia ich aktualność.
Niezależnie od tego zdecydowanie zalecamy stosowanie wersji zasobów statycznych za pomocą haszowania w nazwie zasobu lub w ciągu zapytania. Pozwoli to uniknąć problemów z nieaktualnymi zasobami w mechanizmach Service Worker, które korzystają ze strategii środowiska wykonawczego, które koncentruje się na buforowaniu zasobów statycznych.
Limity miejsca na dane
Skrypty service worker są wdrażane od czasu do czasu, a po ich wdrożeniu stare pamięci podręczne z nieaktualnymi nazwami zwykle są przycinane podczas aktywacji nowego skryptu service worker.
Niektóre iteracje mechanizmów Service Worker działają jednak przez długi czas lub nazwy pamięci podręcznej mogą nie być aktualizowane w ramach nowych aktualizacji. W takiej sytuacji stare zasoby statyczne mogą odkładać się w pamięci podręcznej w miarę przeprowadzania aktualizacji. Limity pamięci i limity mogą się różnić w zależności od przeglądarek. To dobry powód, aby o nich pamiętać.
Skrzynka robocza dobrze radzi sobie z tymi problemami, ale i tak można przekroczyć limity miejsca na dane. Dokładniejszą kontrolę nad pamięciami podręcznymi zapewnia moduł_workbox-expiration.
Bez obaw
Wdrożenie skryptu service worker to nie wszystko. Jednak odrobina planowania i uważności w kwestiach związanych z wdrażaniem mechanizmów Service Workbox nie powinno być trudne. Dzięki tej dokumentacji będziesz ostrożnie i z zachowaniem ostrożności w rozwiązaniu problemów.