Odpowiadaj na żądania nawigacji bez oczekiwania na sieć, używając skryptu service worker.
Żądania nawigacji to żądania 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. W tym przypadku skrypty service worker mają największy wpływ na wydajność: jeśli używasz skryptu service worker do odpowiadania na żądania nawigacji bez czekania na sieć, możesz mieć pewność, że nawigacja będzie niezawodnie szybka, a także odporna na brak dostępu do sieci. To największa korzyść związana z wydajnością, jaką można uzyskać dzięki skryptowi service worker, w porównaniu z tym, co jest możliwe dzięki buforowaniu HTTP.
Jak opisano w przewodniku Identyfikowanie zasobów wczytywanych z sieci, żądanie nawigacji jest pierwszym z potencjalnie wielu żądań wysyłanych w „wodospadzie” ruchu w sieci. Kod HTML wczytywany przez żądanie nawigacji rozpoczyna przepływ wszystkich innych żądań dotyczących zasobów podrzędnych, takich jak obrazy, skrypty i style.
W module obsługi zdarzeń fetch skryptu service worker możesz określić, czy żądanie jest nawigacją, sprawdzając właściwość request.mode w FetchEvent. Jeśli jest ustawiona na 'navigate', jest to żądanie nawigacji.
Zasadniczo nie używaj długotrwałego Cache-Control headers do buforowania odpowiedzi HTML na żądanie nawigacji. Zwykle powinny być one obsługiwane przez sieć, z Cache-Control: no-cache, aby mieć pewność, że kod HTML wraz z łańcuchem kolejnych żądań sieciowych jest (w miarę) aktualny. Niestety, odpytywanie sieci za każdym razem, gdy użytkownik przechodzi na nową stronę, może spowalniać nawigację. W najlepszym przypadku oznacza to, że nie będzie niezawodnie szybka.
Różne podejścia do architektur
Ustalenie, jak odpowiadać na żądania nawigacji, unikając sieci, może być trudne. Właściwe podejście zależy w dużej mierze od architektury witryny i liczby unikalnych adresów URL, do których użytkownicy mogą przechodzić.
Nie ma jednego uniwersalnego rozwiązania, ale te ogólne wskazówki powinny pomóc Ci zdecydować, które podejście jest najbardziej odpowiednie.
Małe witryny statyczne
Jeśli aplikacja internetowa składa się ze stosunkowo niewielkiej liczby (np. kilkudziesięciu) unikalnych adresów URL, a każdy z nich odpowiada innemu statycznemu plikowi HTML, jednym z możliwych rozwiązań jest zapisanie wszystkich tych plików HTML w pamięci podręcznej i odpowiadanie na żądania nawigacji za pomocą odpowiedniego pliku HTML z pamięci podręcznej.
Korzystając z wstępnego buforowania, możesz buforować kod HTML z wyprzedzeniem, zaraz po zainstalowaniu skryptu service worker, i aktualizować buforowany kod HTML za każdym razem, gdy przebudowujesz witrynę i ponownie wdrażasz skrypt service worker.
Jeśli jednak nie chcesz wstępnie zapisywać w pamięci podręcznej całego kodu HTML – na przykład dlatego, że użytkownicy zwykle przechodzą tylko do podzbioru adresów URL w Twojej witrynie – możesz użyć strategii buforowania w czasie działania stale-while-revalidate. Zachowaj jednak ostrożność, ponieważ każdy dokument HTML jest zapisywany w pamięci podręcznej i aktualizowany osobno. Korzystanie z buforowania w czasie działania w przypadku kodu HTML jest najbardziej odpowiednie, jeśli masz niewielką liczbę adresów URL, które są często odwiedzane przez tę samą grupę użytkowników, i jeśli nie masz nic przeciwko temu, aby te adresy URL były ponownie sprawdzane niezależnie od siebie.
aplikacje jednostronicowe,
Architektura jednostronicowa jest często używana przez nowoczesne aplikacje internetowe. W tym przypadku kod JavaScript po stronie klienta modyfikuje kod HTML w odpowiedzi na działania użytkownika. Ten model używa interfejsu History API do modyfikowania bieżącego adresu URL, gdy użytkownik wchodzi w interakcję z aplikacją internetową, co prowadzi do „symulowanej” nawigacji. Kolejne nawigacje mogą być „fałszywe”, ale początkowa nawigacja jest prawdziwa i nadal ważne jest, aby nie była blokowana w sieci.
Jeśli jednak używasz architektury jednostronicowej, możesz skorzystać z prostego wzorca, który umożliwia obsługę początkowej nawigacji z pamięci podręcznej: powłoki aplikacji. W tym modelu skrypt service worker odpowiada na żądania nawigacji, zwracając ten sam, pojedynczy plik HTML, który został już wstępnie zapisany w pamięci podręcznej – niezależnie od żądanego adresu URL. Ten kod HTML powinien być bardzo prosty i zawierać na przykład ogólny wskaźnik wczytywania lub szkielet treści. Gdy przeglądarka wczyta ten kod HTML z pamięci podręcznej, istniejący kod JavaScript po stronie klienta przejmie kontrolę i wyrenderuje prawidłową treść HTML dla adresu URL z pierwotnego żądania nawigacji.
Workbox udostępnia narzędzia, które są potrzebne do wdrożenia tego podejścia. navigateFallback
option pozwala określić, który dokument HTML ma być używany jako powłoka aplikacji, oraz opcjonalną listę dozwolonych i zablokowanych, aby ograniczyć to zachowanie do podzbioru adresów URL.
Aplikacje wielostronicowe
Jeśli serwer WWW generuje kod HTML witryny dynamicznie lub jeśli masz więcej niż kilkadziesiąt unikalnych stron, znacznie trudniej jest uniknąć sieci podczas obsługi żądań nawigacji. W takim przypadku prawdopodobnie będą Cię dotyczyć porady z sekcji Wszystko inne.
Jednak w przypadku niektórych aplikacji wielostronicowych możesz wdrożyć skrypt service worker, który w pełni odtworzy logikę używaną przez serwer WWW do generowania kodu HTML. To rozwiązanie działa najlepiej, jeśli możesz udostępniać informacje o routingu i szablonach między środowiskami serwera i skryptu service worker, a zwłaszcza jeśli Twój serwer WWW używa JavaScriptu (bez korzystania z funkcji specyficznych dla Node.js, takich jak dostęp do systemu plików).
Jeśli Twój serwer WWW należy do tej kategorii i chcesz dowiedzieć się, jak przenieść generowanie kodu HTML z sieci do skryptu service worker, zapoznaj się ze wskazówkami w artykule Beyond SPAs: alternative architectures for your PWA (Poza aplikacjami jednostronicowymi: alternatywne architektury dla PWA).
Wszystkie pozostałe
Jeśli nie możesz odpowiadać na żądania nawigacji za pomocą HTML-a z pamięci podręcznej, musisz podjąć działania, aby dodanie skryptu service worker do witryny (w celu obsługi innych żądań, które nie są żądaniami HTML) nie spowolniło nawigacji. Uruchomienie skryptu service worker bez użycia go do odpowiedzi na żądanie nawigacji spowoduje niewielkie opóźnienie (jak wyjaśniono w artykule Building Faster, More Resilient Apps with Service Worker). Możesz zmniejszyć to obciążenie, włączając funkcję wstępnego wczytywania nawigacji, a następnie używając odpowiedzi sieci, która została wstępnie wczytana w module obsługi zdarzeń fetch.
Workbox udostępnia bibliotekę pomocniczą, która wykrywa, czy wstępne wczytywanie nawigacji jest obsługiwane, a jeśli tak, upraszcza proces informowania skryptu service worker o konieczności użycia odpowiedzi sieciowej.