Odpowiadanie na żądania nawigacji bez oczekiwania na sieć za pomocą service workera.
Żądania dotyczące nawigacji to żądania dotyczące dokumentów HTML wysyłane przez przeglądarkę, gdy wpisujesz nowy adres URL na pasku nawigacyjnym lub klikasz link na stronie, który prowadzi do nowego adresu URL. To właśnie w tym przypadku skrypty service worker mają największy wpływ na wydajność: jeśli używasz skryptu service worker do odpowiadania na żądania nawigacyjne bez oczekiwania na sieć, możesz mieć pewność, że nawigacja będzie niezawodnie szybka, a dodatkowo będzie odporna na awarie sieci. To największy wzrost wydajności, jaki zapewnia skrypt service worker w porównaniu z tym, co jest możliwe dzięki buforowaniu HTTP.
Jak wyjaśniono w przewodniku Identyfikowanie zasobów wczytywanych z sieci, żądanie nawigacyjne jest pierwszym z potencjalnie wielu żądań wysyłanych w ramach schematu kaskadowego ruchu sieciowego. Kod HTML wczytywany przez żądanie nawigacyjne uruchamia przepływ wszystkich innych żądań dotyczących zasobów podrzędnych, takich jak obrazy, skrypty i style.
W obiekcie service workera w obiekcie fetch możesz sprawdzić, czy żądanie jest nawigacją, sprawdzając właściwość request.mode obiektu FetchEvent. Jeśli jest ustawiona na 'navigate', oznacza to, że jest to żądanie nawigacji.
Zasadniczo nie używaj długotrwałych Cache-Control headers do umieszczania w pamięci podręcznej odpowiedzi HTML na żądanie nawigacji. Zwykle powinny one być zaspokajane przez sieć za pomocą parametru Cache-Control: no-cache, aby mieć pewność, że kod HTML wraz z łańcuchem kolejnych żądań sieciowych jest (w miarę) aktualny. Przechodzenie na stronę internetową, która jest sprzeczna z zasadami sieci, za każdym razem, gdy użytkownik przechodzi na nową stronę, powoduje, że każda nawigacja może być powolna. Oznacza to co najmniej, że nie będzie stabilnie szybka.
Różne podejścia do architektur
Ustalenie, jak reagować na żądania nawigacji, unikając sieci, może być trudne. Odpowiedni sposób zależy w dużej mierze od architektury witryny i liczby unikalnych adresów URL, do których użytkownicy mogą przejść.
Nie ma rozwiązania, które byłoby idealne we wszystkich przypadkach. Te ogólne wskazówki powinny pomóc Ci zdecydować, które podejście jest najbardziej odpowiednie.
Małe witryny statyczne
Jeśli Twoja aplikacja internetowa składa się z relatywnie niewielkiej liczby (np. kilkunastu) unikalnych adresów URL, a każdy z nich odpowiada innemu statycznemu plikowi HTML, możesz po prostu zapisać wszystkie te pliki HTML w pamięci podręcznej i odpowiadać na żądania nawigacyjne za pomocą odpowiedniego HTML-a z pamięci podręcznej.
Dzięki wstępnemu przechowywaniu w pamięci podręcznej możesz przechowywać w pamięci podręcznej kod HTML z wyprzedzeniem, gdy tylko zainstalujesz instancję roboczą usługi, i aktualizować go za każdym razem, gdy ponownie kompilujesz witrynę i wdrażasz instancję roboczą usługi.
Jeśli wolisz unikać wstępnego buforowania całego kodu HTML (np. dlatego, że użytkownicy zazwyczaj przechodzą tylko do podzbioru adresów URL w Twojej witrynie), możesz użyć strategii buforowania w czasie wykonywania stale-while-revalidate. Zachowaj jednak ostrożność, ponieważ każdy pojedynczy dokument HTML jest przechowywany w pamięci podręcznej i aktualizowany osobno. Korzystanie z buforowania kodu HTML jest najbardziej odpowiednie, jeśli masz niewielką liczbę adresów URL, które są często odwiedzane przez ten sam zestaw użytkowników, i jeśli czujesz się komfortowo z faktem, że te adresy URL są weryfikowane niezależnie od siebie.
Aplikacje jednostronicowe
Architektura jednostronicowa jest często używana w przypadku nowoczesnych aplikacji internetowych. W ramach tej metody kod JavaScript po stronie klienta modyfikuje kod HTML w odpowiedzi na działania użytkownika. Ten model wykorzystuje interfejs History API do modyfikowania bieżącego adresu URL w miarę interakcji użytkownika z aplikacją internetową, co prowadzi do „symulowanej” nawigacji. Kolejne przejścia mogą być „fałszywe”, ale pierwsze przejście jest prawdziwe i nadal ważne jest, aby upewnić się, że nie jest ono blokowane w sieci.
Jeśli używasz architektury jednoprzebiegowej, możesz skorzystać z prostego wzorca, który pozwoli Ci wyświetlać początkową nawigację z poziomu pamięci podręcznej: powłoki aplikacji. W tym modelu usługa worker odpowiada na żądania nawigacji, zwracając ten sam plik HTML, który został już wstępnie zapisany w pamięci podręcznej, niezależnie od żądanego adresu URL. Kod HTML powinien być podstawowy i zawierać ogólny wskaźnik wczytywania lub szkielet treści. Gdy przeglądarka załaduje kod HTML z pamięci podręcznej, przejmuje go istniejący kod JavaScript po stronie klienta, który renderuje odpowiedni kod HTML dla adresu URL z pierwotnego żądania nawigacji.
Workbox udostępnia narzędzia potrzebne do wdrożenia tego podejścia. navigateFallback
optionumożliwia określenie, którego dokumentu HTML użyć jako powłoki aplikacji, a także opcjonalnej listy dozwolonych i zablokowanych adresów URL, aby ograniczyć to działanie do podzbioru adresów URL.
Aplikacje wielostronicowe
Jeśli serwer WWW generuje kod HTML witryny dynamicznie lub masz ponad kilkadziesiąt stron unikalnych, znacznie trudniej jest uniknąć sieci podczas obsługi żądań nawigacji. Prawdopodobnie dotyczy Cię wszystkie inne informacje.
W przypadku niektórych podzbiorów aplikacji wielostronicowych możesz jednak wdrożyć skrypt service worker, który w pełni odwzorowuje logikę używaną przez serwer WWW do generowania kodu HTML. Najlepiej działa to, jeśli możesz udostępniać informacje o przekierowywaniu i szablonach między środowiskami serwera i usług, zwłaszcza jeśli Twój serwer WWW używa JavaScriptu (bez korzystania z funkcji Node.js, takich jak dostęp do systemu plików).
Jeśli Twój serwer internetowy należy do tej kategorii i chcesz poznać jedno z podejść do przeniesienia generowania kodu HTML poza sieć i do usługi internetowej, zapoznaj się z wskazówkami w artykule Beyond SPAs: alternative architectures for your PWA (ang. „Beyond SPAs: alternative architectures for your PWA”) (ang. „Beyond SPAs: alternative architectures for your PWA”) (ang. „Beyond SPAs: alternative architectures for your PWA”).
Wszystkie pozostałe
Jeśli nie możesz odpowiadać na żądania nawigacji za pomocą HTML-a z pamięci podręcznej, musisz podjąć odpowiednie działania, aby dodanie do witryny pracownika usługi (do obsługi innych żądań niż HTML) nie spowolniło nawigacji. Uruchomienie skryptu service worker bez używania go do obsługi żądania nawigacji spowoduje niewielkie opóźnienie (jak wyjaśniono w artykule Tworzenie szybszych i bardziej odpornych aplikacji za pomocą skryptu Service Worker). Możesz ograniczyć ten nakład, włączając funkcję wstępnego pobierania nawigacji, a następnie korzystając z odpowiedzi z sieci, która została wstępnie pobrana w obiekcie fetch.
Workbox zawiera pomocniczą bibliotekę, która wykrywa, czy funkcja wstępnego ładowania nawigacji jest obsługiwana. Jeśli tak, upraszcza proces informowania skryptu service worker o użyciu odpowiedzi sieci.
Zdjęcie: Aaron Burden z Unsplash