Zalety i wady stosowania spójnej lub innej logiki wygaśnięcia w pamięci podręcznej mechanizmu Service Worker i w warstwie pamięci podręcznej HTTP.
Skrypty service worker i PWA stają się standardem nowoczesnych aplikacji internetowych, buforowanie zasobów stały się bardziej złożone niż kiedykolwiek wcześniej. W tym artykule znajdziesz ogólny opis pamięci podręcznej przeglądarki, w tym:
- Przypadki użycia i różnice między buforowaniem skryptu service worker i buforowaniem HTTP.
- Zalety i wady różnych strategii wygaśnięcia buforowania w mechanizmach Service Worker w porównaniu ze zwykłymi Strategie buforowania HTTP.
Omówienie procesu buforowania
Ogólnie rzecz biorąc, przeglądarka wysyła żądanie zasobu w takiej kolejności:
- Pamięć podręczna skryptu service worker: mechanizm Service Worker sprawdza, czy zasób znajduje się w pamięci podręcznej i decyduje o zwróceniu zasobu na podstawie strategii zaprogramowanego buforowania. Notatka że nie dzieje się to automatycznie. Musisz utworzyć moduł obsługi zdarzeń pobierania w skrypt service worker i przechwytywanie żądań sieciowych, aby były one obsługiwane przez usługę pamięci podręcznej instancji roboczej, a nie sieci.
- Pamięć podręczna HTTP: jeśli zasób znajduje się w pliku HTTP i jeszcze nie wygasła, przeglądarka automatycznie używa z pamięci podręcznej HTTP.
- Po stronie serwera: jeśli nie ma nic w pamięci podręcznej mechanizmu Service Worker ani HTTP, łączy się z siecią, aby zażądać zasobu. Jeśli zasób nie jest przechowywany w pamięci podręcznej w sieci CDN, musi dochodzić aż do serwera pierwotnego.
Warstwy pamięci podręcznej
Buforowanie skryptu service worker
Skrypt service worker przechwytuje żądania HTTP typu sieci i używa strategia buforowania aby określić, które zasoby powinny być zwracane do przeglądarki. Pamięć podręczna mechanizmu Service Worker i protokół HTTP Pamięć podręczna ma ten sam ogólny cel, ale pamięć podręczna mechanizmu Service Worker oferuje większe możliwości np. szczegółową kontrolę nad tym, co jest zapisywane w pamięci podręcznej i w jaki sposób.
Kontrolowanie pamięci podręcznej skryptu service worker
Skrypt service worker przechwytuje żądania HTTP ze zdarzeniem
detektory (zwykle jest to zdarzenie fetch). Ten
fragment kodu demonstruje logikę tagu
Najpierw pamięć podręczna
buforowanie.
Zdecydowanie zalecamy korzystanie z Workbox, aby unikać: zrewolucjonizowaniem koła. Możesz na przykład: rejestrować ścieżki adresów URL zasobów za pomocą jednego wiersza kodu wyrażenia regularnego.
import {registerRoute} from 'workbox-routing';
registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);
Strategie buforowania skryptu service worker i przypadki użycia
W następnej tabeli są opisane typowe strategie buforowania skryptu service worker oraz sytuacje, w których każda z nich jest przydatna.
| Strategie | Uzasadnienie aktualności | Przypadki użycia |
|---|---|---|
| Sieć tylko | Zawartość musi być zawsze aktualna. |
|
| Sieć lub wracam do pamięci podręcznej | Lepiej wyświetlać aktualne treści. Jeśli jednak sieć ulegnie awarii lub będzie niestabilna, mogą zawierać nieco stare treści. |
|
| Wyprzedaż w trakcie ponownej weryfikacji | Treści z pamięci podręcznej można wyświetlać od razu, ale zaktualizowane treści z pamięci podręcznej powinny być używane w przyszłości. |
|
| Najpierw pamięć podręczna, a później wracanie do sieci | Treść jest niekrytyczna i może być wyświetlana z pamięci podręcznej w celu zwiększenia wydajności, ale mechanizm Service Worker powinien od czasu do czasu sprawdzać dostępność aktualizacji. |
|
| Tylko pamięć podręczna | Zawartość rzadko się zmienia. |
|
Dodatkowe korzyści z buforowania skryptu service worker
Oprócz szczegółowej kontroli logiki buforowania buforowanie skryptu service worker zapewnia też:
- Więcej pamięci i miejsca na dane dla źródła: przeglądarka przydziela pamięć podręczną HTTP zasobów z poszczególnych źródeł. W innym słowa, jeśli masz wiele subdomen, wszystkie będą korzystać z tej samej pamięci podręcznej HTTP. Brak zagwarantowanie, że treść Twojej strony źródłowej/domeny pozostanie przez długi czas w pamięci podręcznej HTTP. Dla: na przykład użytkownik może wyczyścić pamięć podręczną ręcznie, usuwając je w interfejsie ustawień przeglądarki. niepowodzenie ponownego wczytywania strony. Dzięki pamięci podręcznej mechanizmu Service Worker masz znacznie większą treści przechowywane w pamięci podręcznej. Zobacz Trwałe , aby dowiedzieć się więcej.
- Większa elastyczność w przypadku niestabilnych sieci lub środowiska offline: dzięki pamięci podręcznej HTTP ma tylko wartość binarną: zasób jest przechowywany w pamięci podręcznej, albo nie. Z pamięcią podręczną skryptu service worker można ograniczyć liczbę drobnych „czatek” (dzięki strategii „nieaktualne w trakcie ponownej weryfikacji”) brak możliwości korzystania ze wszystkich funkcji offline (z użyciem strategii „Tylko pamięć podręczna”), a nawet np. niestandardowe interfejsy, w których fragmenty strony pochodzą z pamięci podręcznej mechanizmu Service Worker, w odpowiednich przypadkach niektóre części zostają wykluczone (za pomocą strategii „Ustaw moduł obsługi żądań”).
Buforowanie HTTP
Po pierwszym wczytaniu strony internetowej i powiązanych zasobów przeglądarka zapisuje te zasoby Pamięć podręczna HTTP. Pamięć podręczna HTTP jest zazwyczaj włączana automatycznie przez przeglądarki, chyba że została przez użytkownika końcowego wyłączonej przez użytkownika.
Korzystanie z buforowania HTTP oznacza poleganie na serwerze w celu określenia, kiedy i jak buforować zasób .
Kontroluj wygasanie pamięci podręcznej HTTP za pomocą nagłówków odpowiedzi HTTP
Gdy serwer odpowiada na żądanie przeglądarki dotyczące zasobu, używa nagłówków odpowiedzi HTTP, aby i poinformują przeglądarkę, jak długo ma zapisywać zasób w pamięci podręcznej. Zobacz temat Nagłówki odpowiedzi: konfigurowanie stron internetowych , aby dowiedzieć się więcej.
Strategie buforowania HTTP i przypadki użycia
Buforowanie HTTP jest znacznie prostsze niż buforowanie skryptu service worker, ponieważ obsługujemy jedynie logika wygaśnięcia zasobów na podstawie czasu (TTL). Zobacz Których wartości nagłówków odpowiedzi użyjesz? i Podsumowanie, aby dowiedzieć się więcej o strategiach buforowania HTTP.
Projektowanie logiki wygaśnięcia pamięci podręcznej
W tej sekcji omawiamy wady i zalety stosowania spójnej logiki wygaśnięcia w środowisku service worker pamięci podręcznej i warstw pamięci podręcznej HTTP, a także zalety i wady oddzielnej logiki wygaśnięcia warstw.
Usterka poniżej pokazuje, jak buforowanie skryptu service worker i HTTP działa w działaniu różne scenariusze:
Spójna logika wygaśnięcia ważności wszystkich warstw pamięci podręcznej
Aby przedstawić zalety i wady, omówimy 3 scenariusze: długoterminowy, średnioterminowy będzie krótkoterminowa.
| Scenariusze | Długoterminowe buforowanie | Średnioterminowa pamięć podręczna | Krótkoterminowe buforowanie |
|---|---|---|---|
| Strategia buforowania skryptu service worker | Pamięć podręczna, wracam do sieci | Nieaktualne – w trakcie ponownej weryfikacji | Sieć przełącza się z powrotem na pamięć podręczną |
| TTL pamięci podręcznej instancji roboczej usługi | 30 dni | 1 dzień, | 10 minut |
| Maksymalny wiek pamięci podręcznej HTTP | 30 dni | 1 dzień, | 10 minut |
Scenariusz: długoterminowe buforowanie (pamięć podręczna, powrót do sieci)
- Gdy zasób z pamięci podręcznej jest ważny (<= 30 dni): mechanizm Service Worker zwraca natychmiast zasobów, bez konieczności łączenia się z siecią.
- Po wygaśnięciu zasobu w pamięci podręcznej (> 30 dni): skrypt service worker łączy się z siecią aby pobrać zasób. Przeglądarka nie ma kopii zasobu w swojej pamięci podręcznej HTTP, więc po stronie serwera dla zasobu.
Wada: w tym scenariuszu pamięć podręczna HTTP ma mniejszą wartość, ponieważ przeglądarka zawsze – przekazuje żądanie na po stronie serwera, gdy pamięć podręczna wygaśnie w skrypcie service worker.
Scenariusz: średnioterminowe buforowanie (nieużywanie w trakcie-ponownej weryfikacji)
- Gdy zasób z pamięci podręcznej jest prawidłowy (<= 1 dzień): mechanizm Service Worker zwraca zasób i łączy się z siecią, aby go pobrać. Przeglądarka ma kopię zasobu w swojej pamięci podręcznej HTTP, więc zwraca tę kopię do skryptu service worker.
- Po wygaśnięciu zasobu w pamięci podręcznej (> 1 dzień): mechanizm Service Worker zwraca zasób i łączy się z siecią, aby go pobrać. Przeglądarka nie ma jego kopii w swojej pamięci podręcznej HTTP, więc idzie po stronie serwera, aby go pobrać.
Wada: skrypt service worker wymaga dodatkowego pomijania pamięci podręcznej, aby zastąpić pamięć podręczną HTTP w aby jak najlepiej wykorzystać potencjał „ponownej weryfikacji” krok po kroku.
Scenariusz: krótkotrwałe buforowanie (powrót sieci do pamięci podręcznej)
- Gdy zasób z pamięci podręcznej jest prawidłowy (<= 10 min): mechanizm Service Worker łączy się z siecią. aby pobrać zasób. Przeglądarka ma kopię zasobu w swojej pamięci podręcznej HTTP, więc zwraca do mechanizmu Service Worker bez przechodzenia po stronie serwera.
- Po wygaśnięciu zasobu w pamięci podręcznej (> 10 minut): mechanizm Service Worker zwraca zasób i łączy się z siecią, aby go pobrać. Przeglądarka nie ma jego kopii w swojej pamięci podręcznej HTTP, więc idzie po stronie serwera, aby go pobrać.
Wada: podobnie jak w przypadku średnioterminowego scenariusza buforowania, mechanizm Service Worker wymaga dodatkowych to logika pomijania pamięci podręcznej, która pozwala zastąpić pamięć podręczną HTTP w celu pobrania najnowszego zasobu z po stronie serwera.
Skrypt service worker we wszystkich scenariuszach
We wszystkich scenariuszach pamięć podręczna skryptu service worker może nadal zwracać zasoby z pamięci podręcznej, gdy sieć niestabilna. Z drugiej strony pamięć podręczna HTTP jest zawodna, gdy sieć jest niestabilna lub nie działa.
Różni logika wygaśnięcia pamięci podręcznej w pamięci podręcznej instancji roboczej usługi i w warstwach HTTP
Aby przedstawić wady i zalety kampanii, ponownie przyjrzymy się metodom długoterminowym, średnioterminowym i krótkoterminowym. w różnych sytuacjach.
| Scenariusze | Długoterminowe buforowanie | Średnioterminowa pamięć podręczna | Krótkoterminowe buforowanie |
|---|---|---|---|
| Strategia buforowania skryptu service worker | Pamięć podręczna, wracam do sieci | Nieaktualne – w trakcie ponownej weryfikacji | Sieć przełącza się z powrotem na pamięć podręczną |
| TTL pamięci podręcznej instancji roboczej usługi | 90 dni | 30 dni | 1 dzień, |
| Maksymalny wiek pamięci podręcznej HTTP | 30 dni | 1 dzień, | 10 minut |
Scenariusz: długoterminowe buforowanie (pamięć podręczna, powrót do sieci)
- Gdy zasób z pamięci podręcznej jest prawidłowy w pamięci podręcznej instancji roboczej (<= 90 dni): usługa instancja robocza natychmiast zwraca zasób z pamięci podręcznej.
- Gdy zasób z pamięci podręcznej wygasł w pamięci podręcznej instancji roboczej usługi (przez ponad 90 dni): usługa komunikuje się z siecią, aby pobrać zasób. Przeglądarka nie ma kopii pliku w swojej pamięci podręcznej HTTP, przekazuje ją po stronie serwera.
Zalety i wady:
- Za: użytkownicy widzą natychmiastową odpowiedź, ponieważ mechanizm Service Worker zwraca zasoby z pamięci podręcznej natychmiast.
- Pro: skrypt service worker ma dokładniejszą kontrolę nad tym, kiedy używać pamięci podręcznej, a kiedy aby wysyłać żądania nowych wersji zasobów.
- Wada: wymagana jest dobrze zdefiniowana strategia buforowania skryptu service worker.
Scenariusz: buforowanie w średnim okresie (nieaktualne-podczas-ponownej weryfikacji)
- Gdy zasób z pamięci podręcznej jest prawidłowy w pamięci podręcznej instancji roboczej (<= 30 dni): usługa instancja robocza natychmiast zwraca zasób z pamięci podręcznej.
- Gdy zasób z pamięci podręcznej wygasł w pamięci podręcznej instancji roboczej usługi (przez ponad 30 dni): usługa instancja robocza łączy się z siecią, do której należy zasób. Przeglądarka nie ma kopii zasobu w: jej pamięć podręczną HTTP, a więc trafia ona po stronie serwera.
Zalety i wady:
- Za: użytkownicy widzą natychmiastową odpowiedź, ponieważ mechanizm Service Worker zwraca zasoby z pamięci podręcznej natychmiast.
- Zaawansowane: mechanizm Service Worker może zapewnić, że następne żądanie dla danego adresu URL nowa odpowiedź z sieci, dzięki której ponowna weryfikacja odbywa się „w tle”.
- Wada: wymagana jest dobrze zdefiniowana strategia buforowania skryptu service worker.
Scenariusz: krótkotrwałe buforowanie (powrót sieci do pamięci podręcznej)
- Gdy zasób z pamięci podręcznej jest prawidłowy w pamięci podręcznej instancji roboczej usługi (<= 1 dzień): usługa instancja robocza łączy się z siecią, do której należy zasób. Przeglądarka zwraca zasób z żądania HTTP. pamięci podręcznej, jeśli jest ona dostępna. Jeśli sieć nie działa, skrypt service worker zwraca zasób z metody pamięć podręczna skryptu service worker
- Gdy zasób z pamięci podręcznej wygasł w pamięci podręcznej instancji roboczej usługi (> 1 dzień): usługa komunikuje się z siecią, aby pobrać zasób. Przeglądarka pobiera zasoby przez , ponieważ wersja z pamięci podręcznej HTTP wygasła.
Zalety i wady:
- Wersja Pro: gdy sieć jest niestabilna lub wyłączona, mechanizm Service Worker zwraca pamięć podręczną i zasobów użytkowników.
- Wada: skrypt service worker wymaga dodatkowego pomijania pamięci podręcznej, aby zastąpić pamięć podręczną HTTP i ustaw opcję „Najpierw sieć” żądań.
Podsumowanie
Ze względu na złożoność kombinacji scenariuszy buforowania nie można zaprojektować jednej reguły który obejmuje wszystkie przypadki. Jednakże na podstawie wniosków zawartych w poprzednich sekcjach które warto wziąć pod uwagę przy projektowaniu strategii buforowania:
- Logika buforowania skryptu service worker nie musi być spójna z wygaśnięciem buforowania HTTP logikę logiczną. Jeśli to możliwe, użyj dłuższego czasu wygaśnięcia skryptu service worker, aby przyznać skryptowi service worker większą kontrolę.
- Buforowanie HTTP nadal odgrywa ważną rolę, ale nie jest niezawodne, gdy sieć jest niestabilne lub niestabilne.
- Sprawdź strategie buforowania dla każdego zasobu, aby upewnić się, że pamięć podręczna skryptu service worker zapewnia swoją wartość, nie powodując konfliktów z pamięcią podręczną HTTP.