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.

Skrypty service worker i PWA stają się standardem nowoczesnych aplikacji internetowych, ale buforowanie zasobów stało się bardziej złożone niż kiedykolwiek wcześniej. 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 wygasania buforowania przez mechanizmy Service Worker w porównaniu ze zwykłymi strategiami buforowania HTTP.

Omówienie procesu buforowania

Ogólnie rzecz biorąc, gdy przeglądarka prosi o zasób, stosuje następującą kolejność:

  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 przechowywania w pamięci podręcznej. 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 w pamięci podręcznej usługi lub w pamięci podręcznej HTTP nie znaleziono niczego, przeglądarka wysyła żądanie zasobu do sieci. Jeśli zasób nie jest przechowywany w pamięci podręcznej w CDN, żądanie musi wrócić do serwera źródłowego.

Proces zapisywania w pamięci podręcznej

Zapisywanie warstw w pamięci podręcznej

Buforowanie skryptu service worker

Usługa workera przechwytuje żądania HTTP typu sieciowego i korzysta z strategii buforowania, aby określić, jakie zasoby należy zwrócić do przeglądarki. Pamięć podręczna usługi i pamięć podręczna HTTP służą do tych samych ogólnych celów, ale pamięć podręczna usługi oferuje więcej funkcji buforowania, takich jak szczegółowa kontrola nad tym, co dokładnie jest buforowane i jak odbywa się buforowanie.

Sterowanie pamięci podręcznej usługi workera

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 korzystanie z Workbox, by uniknąć wymyślania koła na nowo. 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 i przypadki użycia dotyczące buforowania skryptu service worker

W następującej tabeli przedstawiono typowe strategie buforowania w usługach workerów i okoliczności, w których są one przydatne.

Strategie Uzasadnienie dotyczące aktualności Przypadki użycia
Tylko sieć Treści muszą być zawsze aktualne.
  • Płatności i płatności
  • Wyciągi z salda
Sieć używająca pamięci podręcznej Lepiej jest wyświetlać aktualne treści. Jeśli jednak sieć nie działa lub jest niestabilna, możesz wyświetlać nieco starsze treści.
  • Dane aktualne
  • Ceny i stawki (wymaga wyłączenia odpowiedzialności)
  • Stany zamówień
Nieaktualny w czasie 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 informacjami o produktach,
  • Wiadomości
Najpierw pamięć podręczna, a później wracanie do sieci Treści nie są krytyczne i mogą być dostarczane z poziomu pamięci podręcznej, aby zwiększyć wydajność, ale pracownik obsługi powinien od czasu do czasu sprawdzać dostępność aktualizacji.
  • Powłoki aplikacji
  • Zasoby wspólne
Tylko pamięć podręczna Treści rzadko się zmieniają.
  • 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. Innymi słowy, jeśli masz wiele subdomen, wszystkie będą korzystać z tej samej pamięci podręcznej HTTP. Nie ma gwarancji, że treści domeny źródłowej pozostaną przez długi czas w pamięci podręcznej HTTP. Użytkownik może na przykład wyczyścić pamięć podręczną, ręcznie usuwając dane z interfejsu ustawień przeglądarki lub inicjując twarde ponowne załadowanie strony. Dzięki pamięci podręcznej usługi workera jest znacznie większe prawdopodobieństwo, że treści w pamięci podręcznej pozostaną 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. Dzięki buforowaniu w usługach workerów możesz łatwiej łagodzić drobne „problemy” (za pomocą strategii „nieaktualne, ale z potwierdzeniem”) oraz oferować pełne działanie w trybie offline (za pomocą strategii „tylko bufor”) lub nawet coś pośredniego, np. dostosowane interfejsy użytkownika z częściami strony pochodzącymi z bufora usługi workera i z niektórych częściami wykluczonymi (za pomocą strategii „Ustaw uchwyt za pomocą obsługi wyjątków”) w odpowiednich przypadkach.

Pamięć podręczna HTTP

Przy pierwszym wczytaniu strony internetowej i powiązanych zasobów przeglądarka zapisuje te zasoby w swojej pamięci podręcznej HTTP. Pamięć podręczna HTTP jest zwykle włączana automatycznie przez przeglądarki, chyba że użytkownik w wyraźny sposób ją wyłączy.

Korzystanie z buforowania HTTP oznacza, że serwer określa, kiedy i jak długo buforować zasób.

Kontrolowanie daty wygaśnięcia pamięci podręcznej HTTP za pomocą nagłówków odpowiedzi HTTP

Gdy serwer odpowiada na żądanie zasobu wysłane przez przeglądarkę, używa nagłówków odpowiedzi HTTP, aby poinformować przeglądarkę, jak długo ma przechowywać zasób w pamięci podręcznej. Więcej informacji znajdziesz w artykule Nagłówki odpowiedzi: konfigurowanie serwera WWW.

Strategie i przypadki użycia dotyczące buforowania HTTP

Buforowanie HTTP jest znacznie prostsze niż buforowanie skryptu service worker, ponieważ buforowanie HTTP obsługuje tylko logikę wygaśnięcia zasobów opartą na czasie (TTL). Aby dowiedzieć się więcej o strategiach buforowania HTTP, przeczytaj artykuły Których wartości nagłówka odpowiedzi należy używać?Podsumowanie.

Projektowanie logiki wygasania pamięci podręcznej

W tej sekcji opisano zalety i wady stosowania spójnej logiki wygasania na poziomie pamięci podręcznej service workera i pamięci podręcznej HTTP oraz zalety i wady stosowania oddzielnej logiki wygasania na tych poziomach.

Glitch poniżej pokazuje, jak działa buforowanie w usługach workera i buforowanie HTTP w różnych scenariuszach:

Spójna logika wygaśnięcia ważności wszystkich warstw pamięci podręcznej

Aby przedstawić wady i zalety programu, omówimy 3 scenariusze: długoterminowy, średnioterminowy i krótkoterminowy.

Scenariusze Buforowanie długoterminowe Pamięć podręczna średnioterminowa Pamięć podręczna krótkoterminowa
Strategia buforowania skryptu service worker Pamięć podręczna, wracam do sieci Nieaktualny podczas ponownego sprawdzania ważności Sieć przechodzi na pamięć podręczną
Czas życia danych w pamięci podręcznej skryptu service worker 30 dni 1 dzień 10 minut
max-age, HTTP Cache 30 dni 1 dzień 10 minut

Scenariusz: długoterminowe buforowanie (pamięć podręczna, powrót do sieci)

  • Gdy zasób w pamięci podręcznej jest ważny (do 30 dni): usługa robocza zwraca zasób w pamięci podręcznej natychmiast, bez łączenia się z siecią.
  • Po wygaśnięciu zasobu w pamięci podręcznej (> 30 dni): mechanizm 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: buforowanie na średnim dystansie (sprawdzanie poprawności po upływie określonego czasu)

  • 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 wysyła żądanie do sieci, aby pobrać zasób. Przeglądarka ma kopię zasobu w 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 kopii zasobu w swojej pamięci podręcznej HTTP, więc idzie po stronie serwera, aby pobrać zasób.

Wady: aby zapewnić optymalne działanie etapu „potwierdzania”, skrypt service worker wymaga dodatkowego usuwania danych z pamięci podręcznej, aby zastąpić pamięć podręczną HTTP.

Scenariusz: krótkoterminowe buforowanie (przejście do buforowania w sieci)

  • 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 pamięci podręcznej HTTP, więc zwraca ją skryptowi service worker bez korzystania z serwera.
  • Gdy zasób pamięci podręcznej wygaśnie (przez ponad 10 minut): mechanizm Service Worker natychmiast zwraca zasób z pamięci podręcznej i łączy się z siecią, aby go pobrać. Przeglądarka nie ma kopii zasobu w pamięci podręcznej HTTP, więc pobiera go po stronie serwera.

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 scenariuszu pamięć podręczna skryptu service worker może zwracać zapisane zasoby, gdy sieć jest niestabilna. Z drugiej strony pamięć podręczna HTTP jest zawodna, gdy sieć jest niestabilna lub nie działa.

Różna logika wygaszania pamięci podręcznej na poziomie pamięci podręcznej usługi i warstwy HTTP

Aby pokazać zalety i wady, ponownie przyjrzymy się scenariuszom długo-, średnio- i krótkoterminowym.

Scenariusze Buforowanie długoterminowe Pamięć podręczna średnioterminowa Pamięć podręczna krótkoterminowa
Strategia buforowania skryptu service worker Pamięć podręczna, wracam do sieci Nieaktualny podczas ponownego sprawdzania ważności Sieć przechodzi na pamięć podręczną
Czas życia danych w pamięci podręcznej skryptu service worker 90 dni 30 dni 1 dzień
Maksymalny wiek buforowania 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): skrypt service worker natychmiast zwraca zasób z pamięci podręcznej.
  • Gdy zasób w pamięci podręcznej w pliku usługi (>90 dni) wygaśnie: usługa workera łączy się z siecią, aby pobrać zasób. Przeglądarka nie ma kopii zasobu w pamięci podręcznej HTTP, więc idzie 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.
  • Zalety: usługa workera ma większą kontrolę nad tym, kiedy używać pamięci podręcznej, a kiedy żądać nowych wersji zasobów.
  • Wady: wymagana jest dobrze zdefiniowana strategia buforowania usługi.

Scenariusz: buforowanie w średnim okresie (nieaktywne podczas walidacji)

  • 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 jest on przesyłany po stronie serwera.

Zalety i wady:

  • Pro: użytkownicy widzą natychmiastową odpowiedź, ponieważ skrypt service worker natychmiast zwraca zasoby z pamięci podręcznej.
  • Pro: skrypt service worker może sprawić, że następne żądanie dotyczące danego adresu URL będzie korzystać z nowej odpowiedzi z sieci dzięki ponownej weryfikacji „w tle”.
  • Wady: wymagana jest dobrze zdefiniowana strategia buforowania usługi.

Scenariusz: krótkoterminowe buforowanie (przejście 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. Jeśli zasób znajduje się w pamięci podręcznej HTTP, przeglądarka zwraca go z niej. Jeśli sieć jest niedostępna, skrypt service worker zwraca zasób z pamięci podręcznej skryptu service worker.
  • Gdy zasób w pamięci podręcznej w usługach pracujących w tle wygaśnie (po ponad 1 dniu): usługa pracująca w tle łączy się z siecią, aby pobrać zasób. Przeglądarka pobiera zasoby z sieci, ponieważ wersja w pamięci podręcznej w pamięci podręcznej HTTP wygasła.

Zalety i wady:

  • Wersja Pro: gdy sieć jest niestabilna lub wyłączona, skrypt service worker natychmiast zwraca zasoby zapisane w pamięci podręcznej.
  • Wady: aby zastąpić pamięć podręczną HTTP i wykonać żądania „najpierw sieć”, skrypt service worker wymaga dodatkowego burzenia pamięci podręcznej.

Podsumowanie

Ze względu na złożoność kombinacji scenariuszy dotyczących buforowania nie jest możliwe zaprojektowanie jednej reguły obejmującej wszystkie przypadki. Na podstawie wniosków z poprzednich sekcji podajemy kilka sugestii dotyczących projektowania strategii dotyczących pamięci podręcznej:

  • 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