Buforowanie skryptu service worker i buforowanie HTTP

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.

Jonathan Chen

Chociaż serwisy i aplikacje PWA stają się standardem w przypadku nowoczesnych aplikacji internetowych, buforowanie zasobów stało się bardziej skomplikowane niż kiedykolwiek. Z tego artykułu dowiesz się więcej o pamięci podręcznej przeglądarki, w tym:

  • Przypadki użycia i różnice między buforowaniem w usługach workera a buforowaniem HTTP.
  • Zalety i wady różnych strategii dotyczących wygasania pamięci podręcznej usługi w porównaniu ze standardowymi strategiami dotyczącymi pamięci podręcznej HTTP.

Omówienie procesu buforowania

Ogólnie rzecz biorąc, przeglądarka wysyła żądanie zasobu w takiej kolejności:

  1. Pamięć podręczna usługi: usługa sprawdza, czy zasób znajduje się w pamięci podręcznej, i decyduje, czy zwrócić sam zasób na podstawie zaprogramowanych strategii buforowania. Pamiętaj, że nie dzieje się to automatycznie. W serwisie workera musisz utworzyć element obsługi zdarzenia pobierania i przechwytywać żądania sieciowe, aby były one obsługiwane z poziomu pamięci podręcznej serwisu workera, a nie z sieci.
  2. Pamięć podręczna HTTP (zwana też pamięcią podręczną przeglądarki): jeśli zasób znajduje się w pamięci podręcznej HTTP i nie wygasł, przeglądarka automatycznie używa zasobu z pamięci podręcznej HTTP.
  3. Po stronie serwera: jeśli nie ma nic w pamięci podręcznej mechanizmu Service Worker ani w pamięci podręcznej 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.

Proces zapisywania w pamięci podręcznej

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 dokładnie jest zapisywane w pamięci podręcznej i w jaki sposób.

Kontrolowanie pamięci podręcznej skryptu service worker

Usługa robocza przechwytuje żądania HTTP za pomocą obsługujących zdarzeń (zazwyczaj zdarzenia fetch). Ten fragment kodu pokazuje logikę strategii buforowania Cache-First.

Diagram pokazujący, jak skrypty service worker przechwytują żądania HTTP

Zdecydowanie zalecamy używanie Workbox, aby uniknąć wymyślania koła na nowo. Możesz na przykład zarejestrować ścieżki adresów URL zasobów za pomocą pojedynczego 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 Treści muszą być zawsze aktualne.
  • Płatności i płatności
  • Wyciągi z salda
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.
  • Aktualne dane
  • ceny i stawki (wymagają wyłączenia odpowiedzialności);
  • Stany zamówień
Wyprzedaż w trakcie ponownej weryfikacji Możesz od razu wyświetlać treści z pamięci podręcznej, ale w przyszłości używaj zaktualizowanych treści z pamięci podręcznej.
  • kanały wiadomości,
  • Strony z listą produktów
  • Wiadomoś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.
  • Powłoki aplikacji
  • Typowe zasoby
Tylko pamięć podręczna Zawartość rzadko się zmienia.
  • Zawartość statyczna

Dodatkowe zalety buforowania w usługach workerów

Oprócz precyzyjnej kontroli logiki buforowania buforowanie w ramach skryptu service worker zapewnia też:

  • Więcej pamięci i miejsca na dane dla punktu początkowego: przeglądarka przydziela zasoby pamięci podręcznej HTTP na podstawie źródła. 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. Na potrzeby 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 usługi znacznie zwiększa się prawdopodobieństwo, że treści będą przechowywane w pamięci podręcznej. Więcej informacji znajdziesz w artykule o trwałym miejscu na dane.
  • Większa elastyczność w przypadku niestabilnych sieci lub korzystania z urządzenia offline: w przypadku pamięci podręcznej HTTP masz tylko 2 możliwości: zasób jest przechowywany w pamięci podręcznej lub 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 pamięci podręcznej HTTP oznacza, że serwer decyduje, kiedy i jak długo ma przechowywać zasób w pamięci podręcznej.

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 poinformować przeglądarkę, jak długo ma przechowywać zasób w pamięci podręcznej. Zobacz temat Nagłówki odpowiedzi: konfigurowanie witryn , aby dowiedzieć się więcej.

Strategie i przypadki użycia dotyczące buforowania HTTP

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 wygasania dla wszystkich warstw pamięci podręcznej;

Aby przedstawić zalety i wady, omówimy 3 scenariusze: długoterminowy, średnioterminowy będzie krótkoterminowa.

Scenariusze Buforowanie długoterminowe Pamięć podręczna średnioterminowa Pamięć podręczna krótkoterminowa
Strategia dotycząca pamięci podręcznej 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
Czas ważności 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 pamięci podręcznej HTTP, więc pobiera go po stronie serwera.

Wady: w tym scenariuszu buforowanie HTTP jest mniej przydatne, ponieważ przeglądarka zawsze przekaże żądanie po stronie serwera, gdy pamięć podręczna w skrypcie service worker wygaśnie.

Scenariusz: średnioterminowe buforowanie (nieużywanie w trakcie-ponownej weryfikacji)

  • Gdy zasób w pamięci podręcznej jest ważny (do 1 dnia): usługa robocza zwraca zasob z pamięci podręcznej natychmiast i przechodzi do sieci, aby pobrać zasób. Przeglądarka ma kopię zasobu w swojej pamięci podręcznej HTTP, więc zwraca tę kopię do skryptu service worker.
  • Gdy zasób w pamięci podręcznej wygasa (> 1 dzień): usługa robocza zwraca zasób w pamięci podręcznej natychmiast i pobiera go z sieci. 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 w pamięci podręcznej jest ważny (do 10 minut): usługa robocza łączy się z siecią, aby pobrać zasób. Przeglądarka ma kopię zasobu w pamięci podręcznej HTTP, więc zwraca ją skryptowi service worker bez korzystania z 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ć.

Wady: podobnie jak w przypadku średnioterminowego buforowania, usługa workera wymaga dodatkowej logiki buforowania, aby zastąpić bufor HTTP i pobrać najnowszy zasób po stronie serwera.

Usługa w ramach wszystkich scenariuszy

W każdym przypadku pamięć podręczna skryptu service worker może zwracać zasobów z pamięci podręcznej, gdy sieć jest niestabilna. Z drugiej strony pamięć podręczna HTTP nie jest niezawodna, gdy sieć jest niestabilna lub nie działa.

Różni logika wygasania 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 Buforowanie długoterminowe Pamięć podręczna średnioterminowa Pamięć podręczna krótkoterminowa
Strategia dotycząca pamięci podręcznej 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ń
Czas ważności 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 instancja robocza łączy się z siecią, aby pobrać zasób. Przeglądarka nie ma kopii zasobu w pamięci podręcznej HTTP, więc żądanie jest wysyłane po stronie serwera.

Zalety i wady:

  • Zalety: użytkownicy otrzymują natychmiastową odpowiedź, ponieważ usługa workera zwraca zasobów 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 pośrednie (sprawdzanie poprawności po upływie określonego czasu)

  • Gdy zasób w pamięci podręcznej jest prawidłowy w pamięci podręcznej usługi (do 30 dni): usługa worker zwraca zasobów z pamięci podręcznej natychmiast.
  • Gdy zasób w pamięci podręcznej w usługach workera wygaśnie (ponad 30 dni): usługa workera łączy się z siecią w celu pobrania zasobu. Przeglądarka nie ma kopii zasobu w pamięci podręcznej HTTP, więc żądanie jest wysyłane po stronie serwera.

Zalety i wady:

  • Zalety: użytkownicy mogą korzystać z natychmiastowych odpowiedzi, ponieważ usługa workera zwraca zasobów 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”.
  • Wady: wymagana jest dobrze zdefiniowana strategia buforowania usługi.

Scenariusz: krótkotrwałe buforowanie (powrót sieci do pamięci podręcznej)

  • Gdy zasób w pamięci podręcznej jest prawidłowy w pamięci podręcznej usługi (do 1 dnia): usługa workera łączy się z siecią w celu uzyskania zasobu. Przeglądarka zwraca zasób z żądania HTTP. pamięci podręcznej, jeśli ona jest. 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 instancja robocza łączy 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óra obejmowałaby wszystkie przypadki. Jednakże na podstawie wniosków zawartych w poprzednich sekcjach które warto wziąć pod uwagę przy projektowaniu strategii buforowania:

  • Logika buforowania w usługach workera nie musi być zgodna z logiką wygasania buforowania HTTP. Jeśli to możliwe, użyj w skrypcie service worker dłuższej logiki wygasania, aby zapewnić mu większą kontrolę.
  • Buforowanie HTTP nadal odgrywa ważną rolę, ale nie jest niezawodne, gdy sieć jest niestabilna lub niedostępna.
  • Sprawdź strategie buforowania dla każdego zasobu, aby upewnić się, że strategia buforowania skryptu usługi zapewnia odpowiednią wartość, nie kolidując z buforem HTTP.

Więcej informacji