Buforowanie skryptu service worker i buforowanie HTTP

Zalety i wady stosowania spójnej lub różnej logiki wygasania na poziomie pamięci podręcznej service workera i poziomu 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, 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 buforowania. Pamiętaj, że nie dzieje się to automatycznie. W serwisie workera musisz utworzyć moduł obsługi zdarzenia pobierania i przechwytywać żądania sieci, 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 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 i przypadki użycia dotyczące buforowania skryptów service worker

W następującej tabeli przedstawiono popularne 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 (wymagają wyłączenia odpowiedzialności),
  • Stany zamówień
Stale-while-revalidate 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, potem sieć 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ć, czy nie pojawiły się nowe aktualizacje.
  • 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 kilka subdomen, wszystkie korzystają z tego samego 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 wywołując twarde przeładowanie strony. Dzięki pamięci podręcznej usługi znacznie zwiększa się prawdopodobieństwo, że treści w pamięci podręcznej pozostaną w pamięci podręcznej. Więcej informacji znajdziesz w artykule na temat trwałego miejsca 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

Gdy przeglądarka po raz pierwszy wczytuje stronę internetową i powiązane z nią zasoby, zapisuje je 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 pamięci podręcznej HTTP oznacza, że serwer decyduje, kiedy i jak długo ma przechowywać zasób w pamięci podręcznej.

Kontrolowanie daty wygaśnięcia 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. 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 w ramach skryptu service worker, ponieważ zajmuje się tylko logiką wygasania 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ć? i 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.

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

spójna logika wygasania dla wszystkich warstw pamięci podręcznej;

Aby pokazać zalety i wady, przyjrzymy się 3 scenariuszom: długookresowemu, średnioterminowemu i krótkoterminowemu.

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, powrót 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
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 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ą.
  • Gdy zasób w pamięci podręcznej wygasa (> 30 dni): usługa robocza łą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 przechodzi do sieci, aby pobrać zasób. Przeglądarka ma kopię zasobu w pamięci podręcznej HTTP, więc zwraca ją 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 pamięci podręcznej HTTP, więc pobiera go po stronie serwera.

Wady: aby móc zastąpić pamięć podręczną HTTP, skrypt service worker wymaga dodatkowego usuwania danych z pamięci podręcznej, aby w pełni wykorzystać etap „potwierdzania”.

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

  • 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.
  • Gdy zasób w pamięci podręcznej wygasł (>10 minut): usługa robocza zwraca zasobów z pamięci podręcznej natychmiast i pobiera zasoby z sieci. 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 nie jest niezawodna, 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 dotycząca pamięci podręcznej skryptu service worker Pamięć podręczna, powrót 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ń
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 w pamięci podręcznej jest prawidłowy w pamięci podręcznej usługi (do 90 dni): usługa worker zwraca zasobów z pamięci podręcznej natychmiast.
  • Gdy zasób w pamięci podręcznej w pliku service workera wygaśnie (po ponad 90 dniach): service worker łą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 mogą korzystać z natychmiastowych odpowiedzi, 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 pośrednie (potwierdzanie 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 jest on przesyłany 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: dzięki temu, że walidacja odbywa się „w tle”, pracownik obsługi może zapewnić, aby następne żądanie określonego adresu URL używało nowej odpowiedzi z sieci.
  • Wady: wymagana jest dobrze zdefiniowana strategia buforowania usługi.

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

  • 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 w pamięci podręcznej usługi pracownika usługi wygasa (po ponad 1 dniu): pracownik usługi łą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:

  • Zalety: gdy sieć jest niestabilna lub niedostępna, usługa robocza natychmiast zwraca zapisane w pamięci podręcznej zasoby.
  • Wady: skrypt service worker wymaga dodatkowego burzenia pamięci podręcznej, aby zastąpić pamięć podręczną HTTP i wysyłać żądania „najpierw przez sieć”.

Podsumowanie

Ze względu na złożoność kombinacji scenariuszy buforowania nie można zaprojektować jednej reguły, która obejmowałaby 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ź ponownie 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