Zalety i wady używania spójnej lub różnej logiki wygaśnięcia w warstwach pamięci podręcznej skryptu service worker i warstwie pamięci podręcznej HTTP.
Skrypty service worker i PWA stają się standardami nowoczesnych aplikacji internetowych, ale zapisywanie zasobów w pamięci podręcznej stało się bardziej złożone niż kiedykolwiek wcześniej. Ten artykuł opisuje ogólny obraz pamięci podręcznej przeglądarki, w tym:
- Przypadki użycia i różnice między buforowaniem skryptu service worker a buforowaniem HTTP.
- Zalety i wady różnych strategii wygaszania pamięci podręcznej skryptu service worker w porównaniu ze zwykłymi strategiami buforowania HTTP.
Omówienie procesu buforowania
Ogólnie rzecz biorąc, gdy przeglądarka żąda zasobu w pamięci podręcznej, postępuje zgodnie z podaną niżej kolejnością:
- Pamięć podręczna skryptu service worker: mechanizm Service Worker sprawdza, czy zasób znajduje się w pamięci podręcznej, i na podstawie swoich zaprogramowanych strategii buforowania decyduje, czy zwrócić sam zasób. Pamiętaj, że nie dzieje się to automatycznie. Musisz utworzyć w skrypcie service worker moduł obsługi zdarzeń pobierania i przechwytywać żądania sieciowe, aby były one obsługiwane przez pamięć podręczną skryptu service worker, a nie z sieci.
- Pamięć podręczna HTTP (znana też jako pamięć podręczna przeglądarki): jeśli zasób znajdzie się w pamięci podręcznej HTTP i jeszcze nie wygasł, przeglądarka automatycznie użyje go z pamięci podręcznej HTTP.
- Po stronie serwera: jeśli nic nie znajdzie się w pamięci podręcznej skryptu service worker ani w pamięci podręcznej HTTP, przeglądarka łączy się z siecią, aby zażądać zasobu. Jeśli zasób nie jest przechowywany w pamięci podręcznej w sieci CDN, żądanie musi wracać z powrotem do serwera pierwotnego.
Warstwy pamięci podręcznej
Buforowanie skryptu service worker
Skrypt service worker przechwytuje żądania HTTP typu sieciowe i używa strategii przechowywania w pamięci podręcznej, aby określić, które zasoby powinny zostać zwrócone do przeglądarki. Pamięć podręczna skryptu service worker i pamięci podręcznej HTTP służą do tego samego ogólnego przeznaczenia, ale pamięć podręczna tego procesu zapewnia więcej możliwości buforowania, na przykład szczegółową kontrolę nad tym, co jest zapisywane w pamięci podręcznej i jak odbywa się buforowanie.
Kontrolowanie pamięci podręcznej skryptu service worker
Skrypt service worker przechwytuje żądania HTTP za pomocą odbiorników (zwykle zdarzeń fetch). Ten fragment kodu ilustruje logikę strategii buforowania Cache-First.
Zdecydowanie zalecamy korzystanie z Workbox, aby uniknąć wymyślania nowych funkcji. Możesz na przykład zarejestrować ś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ępnej tabeli przedstawiono typowe strategie buforowania skryptu service worker oraz sposoby ich zastosowania.
| Strategie | Uzasadnienie aktualizacji | Przypadki użycia |
|---|---|---|
| Tylko sieć | Treści muszą być zawsze aktualne. |
|
| Sieć powraca do pamięci podręcznej | Zalecamy udostępnianie aktualnych treści. Jeśli jednak sieć ulegnie awarii lub będzie niestabilna, można wyświetlać nieco starsze treści. |
|
| Nieaktywny podczas ponownej weryfikacji | Treści z pamięci podręcznej można wyświetlać od razu, ale zaktualizowane treści z pamięci podręcznej należy używać w przyszłości. |
|
| Najpierw pamięć podręczna, a następnie wróć do sieci | Treść nie jest krytyczna i może być udostępniana z pamięci podręcznej w celu zwiększenia wydajności, ale skrypt service worker powinien od czasu do czasu sprawdzać dostępność aktualizacji. |
|
| Tylko pamięć podręczna | Treść rzadko się zmienia. |
|
Dodatkowe korzyści z buforowania skryptu service worker
Oprócz szczegółowej kontroli nad logiką buforowania działa też buforowanie:
- Więcej pamięci i miejsca na dane w przypadku źródła: przeglądarka przydziela zasoby pamięci podręcznej HTTP według źródła. Inaczej mówiąc, jeśli masz wiele subdomen, wszystkie korzystają z tej samej pamięci podręcznej HTTP. Nie ma gwarancji, że treść Twojego źródła/domeny pozostanie w pamięci podręcznej HTTP przez długi czas. Użytkownik może na przykład wyczyścić pamięć podręczną przez ręczne wyczyszczenie interfejsu ustawień przeglądarki lub uruchomienie trwałego ponownego załadowania strony. W przypadku pamięci podręcznej skryptu service worker jest większe prawdopodobieństwo, że treść przechowywana w pamięci podręcznej pozostanie w pamięci podręcznej. Więcej informacji znajdziesz w artykule Pamięć trwała.
- Większa elastyczność w przypadku niestabilnych sieci lub pracy w trybie offline: w przypadku pamięci podręcznej HTTP masz tylko możliwość wyboru: czy zasób jest buforowany, czy nie. Buforowanie skryptu service worker pozwala znacznie łatwiej ograniczyć drobnostki (dzięki strategii „stale- when-revalidate”) i zapewnić kompletne działanie offline (ze strategią „Tylko pamięć podręczna”) lub też coś pomiędzy, np. niestandardowe interfejsy z częściami strony pochodzącej z pamięci podręcznej skryptu service worker, a także – za pomocą strategii „Ustaw moduł obsługi przechwytywania” – w stosownych przypadkach.
Buforowanie HTTP
Przy pierwszym wczytywaniu strony internetowej i powiązanych z nią zasobów przeglądarka zapisuje te zasoby w pamięci podręcznej HTTP. Pamięć podręczna HTTP jest zazwyczaj włączana automatycznie przez przeglądarki, chyba że została wyraźnie wyłączona przez użytkownika.
Użycie buforowania HTTP oznacza poleganie na serwerze do określania, kiedy i jak długo zasób ma być buforowany.
Kontroluj wygaśnięcie 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 ona buforować zasób. Więcej informacji znajdziesz w artykule Nagłówki odpowiedzi: konfigurowanie serwera WWW.
Strategie buforowania HTTP i przypadki użycia
Buforowanie HTTP jest znacznie prostsze niż buforowanie skryptu service worker, ponieważ buforowanie HTTP dotyczy tylko logiki wygaśnięcia zasobów zależnej od czasu (TTL). Aby dowiedzieć się więcej o strategiach buforowania HTTP, przeczytaj artykuły Jakich wartości nagłówków odpowiedzi użyć? i Podsumowanie.
Projektowanie logiki wygaśnięcia pamięci podręcznej
W tej sekcji opisujemy wady i zalety stosowania spójnej logiki wygaśnięcia w warstwach pamięci podręcznej skryptu service worker i warstwy pamięci podręcznej HTTP, a także wady i zalety poszczególnych warstw związanych z wygaśnięciem.
Poniżej pokazujemy, jak buforowanie skryptu service worker i buforowanie HTTP działa w różnych scenariuszach:
Spójna logika wygaśnięcia ważności dla wszystkich warstw pamięci podręcznej
Aby przedstawić wady i zalety, przyjrzymy się 3 scenariuszom: długoterminowym, średnioterminowym i krótkoterminowym.
| Scenariusze | Długoterminowe buforowanie | Średnioterminowe buforowanie | Krótkoterminowe buforowanie |
|---|---|---|---|
| Strategia buforowania skryptu service worker | Pamięć podręczna, z powrotem do sieci | Nieaktualny podczas ponownej weryfikacji | Sieć powraca do pamięci podręcznej |
| TTL pamięci podręcznej skryptu service worker | 30 dni | 1 dzień, | 10 minut |
| Maksymalny wiek pamięci podręcznej HTTP | 30 dni | 1 dzień, | 10 minut |
Scenariusz: długoterminowe zapisywanie w pamięci podręcznej (pamięć podręczna, powrót do sieci)
- Gdy zasób przechowywany w pamięci podręcznej jest prawidłowy (<= 30 dni): skrypt service worker zwraca zasób z pamięci podręcznej natychmiast bez łączenia się z siecią.
- Gdy zasób przechowywany w pamięci podręcznej wygaśnie (> 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, dlatego udostępnia zasób po stronie serwera.
Wada: w tym scenariuszu buforowanie HTTP ma mniejszą wartość, ponieważ przeglądarka zawsze przekazuje żądanie do strony serwera po wygaśnięciu pamięci podręcznej w skryptu service worker.
Scenariusz: średniotrwałe zapisywanie w pamięci podręcznej (brak podczas ponownej weryfikacji)
- Gdy zasób przechowywany w pamięci podręcznej jest prawidłowy (<= 1 dzień): skrypt service worker natychmiast zwraca zasób zapisany w pamięci podręcznej i przechodzi do sieci, by go pobrać. Przeglądarka ma kopię zasobu w pamięci podręcznej HTTP, więc zwraca tę kopię do skryptu service worker.
- Gdy zasób przechowywany w pamięci podręcznej wygaśnie (> 1 dzień): skrypt service worker natychmiast zwraca zasób zapisany w pamięci podręcznej i łączy się z siecią, aby go pobrać. Przeglądarka nie ma kopii zasobu w swojej pamięci podręcznej HTTP, więc pobiera zasób po stronie serwera.
Wada: skrypt service worker wymaga dodatkowego pomijania pamięci podręcznej w celu zastąpienia pamięci podręcznej HTTP, aby jak najlepiej wykorzystać krok „ponownej weryfikacji”.
Scenariusz: krótkoterminowe buforowanie (sieć powraca do pamięci podręcznej)
- Gdy zasób przechowywany w pamięci podręcznej jest prawidłowy (<= 10 min): mechanizm Service Worker dociera do sieci, aby pobrać zasób. Przeglądarka ma kopię zasobu w pamięci podręcznej HTTP, dlatego zwraca ją do mechanizmu Service Worker bez przechodzenia po stronie serwera.
- Gdy zasób zapisany w pamięci podręcznej wygaśnie (ponad 10 minut): mechanizm Service Worker natychmiast zwraca zasób zapisany w pamięci podręcznej i przechodzi do sieci, aby go pobrać. Przeglądarka nie ma kopii zasobu w swojej pamięci podręcznej HTTP, więc pobiera zasób po stronie serwera.
Wada: podobnie jak w przypadku średnioterminowego scenariusza buforowania, mechanizm Service Worker wymaga dodatkowej logiki pomijania pamięci podręcznej w celu zastąpienia pamięci podręcznej HTTP w celu pobrania najnowszego zasobu ze strony serwera.
Skrypt service worker we wszystkich scenariuszach
We wszystkich przypadkach pamięć podręczna skryptu service worker może zwracać zasoby 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.
Inna logika wygaśnięcia pamięci podręcznej w pamięci podręcznej skryptu service worker i warstwach HTTP
Aby zademonstrować jej wady i zalety, ponownie przyjrzymy się scenariuszom długoterminowym, średnioterminowym i krótkoterminowym.
| Scenariusze | Długoterminowe buforowanie | Średnioterminowe buforowanie | Krótkoterminowe buforowanie |
|---|---|---|---|
| Strategia buforowania skryptu service worker | Pamięć podręczna, z powrotem do sieci | Nieaktualny podczas ponownej weryfikacji | Sieć powraca do pamięci podręcznej |
| TTL pamięci podręcznej skryptu service worker | 90 dni | 30 dni | 1 dzień, |
| Maksymalny wiek pamięci podręcznej HTTP | 30 dni | 1 dzień, | 10 minut |
Scenariusz: długoterminowe zapisywanie w pamięci podręcznej (pamięć podręczna, powrót do sieci)
- Gdy zasób z pamięci podręcznej jest prawidłowy w pamięci podręcznej skryptu service worker (<= 90 dni): natychmiast zwraca zasób zapisany w pamięci podręcznej.
- Gdy zasób z pamięci podręcznej wygaśnie w pamięci podręcznej skryptu service worker (> 90 dni): mechanizm Service Worker dociera do sieci, aby pobrać zasób. Przeglądarka nie ma kopii zasobu w pamięci podręcznej HTTP, więc trafia po stronie serwera.
Zalety i wady:
- Zaawansowana: użytkownicy mają natychmiastową odpowiedź, ponieważ mechanizm Service Worker natychmiast zwraca zasoby zapisane w pamięci podręcznej.
- Zalety: skrypt service worker ma bardziej szczegółową kontrolę nad tym, kiedy używać pamięci podręcznej, a kiedy żądać nowych wersji zasobów.
- Wada: wymagana jest dobrze zdefiniowana strategia buforowania skryptu service worker.
Scenariusz: buforowanie w trakcie (gdy trwa ponowne zweryfikowanie)
- Gdy zasób przechowywany w pamięci podręcznej jest prawidłowy w pamięci podręcznej skryptu service worker (<= 30 dni): natychmiast zwraca zasób zapisany w pamięci podręcznej.
- Gdy zasób z pamięci podręcznej wygaśnie w pamięci podręcznej skryptu service worker (> 30 dni): skrypt service worker dociera do sieci, aby pobrać ten zasób. Przeglądarka nie ma kopii zasobu w pamięci podręcznej HTTP, więc trafia po stronie serwera.
Zalety i wady:
- Zaawansowana: użytkownicy mają natychmiastową odpowiedź, ponieważ mechanizm Service Worker natychmiast zwraca zasoby zapisane w pamięci podręcznej.
- Zaleta: dzięki mechanizmowi ponownej weryfikacji „w tle” mechanizm Service Worker może zadbać o to, aby następne żądanie dotyczące danego adresu URL używało nowej odpowiedzi z sieci.
- Wada: wymagana jest dobrze zdefiniowana strategia buforowania skryptu service worker.
Scenariusz: krótkoterminowe buforowanie (sieć powraca do pamięci podręcznej)
- Gdy zasób z pamięci podręcznej jest prawidłowy w pamięci podręcznej skryptu service worker (<= 1 dzień): skrypt service worker dociera do sieci, aby pobrać ten zasób. Przeglądarka zwraca zasób z pamięci podręcznej HTTP, jeśli on się tam znajduje. Jeśli sieć nie działa, skrypt service worker zwraca zasób z pamięci podręcznej skryptu service worker
- Gdy zasób z pamięci podręcznej wygaśnie w pamięci podręcznej skryptu service worker (> 1 dzień): skrypt service worker dociera do sieci, aby pobrać zasób. Przeglądarka pobiera zasoby przez sieć, ponieważ wersja przechowywana w pamięci podręcznej HTTP wygasła.
Zalety i wady:
- Zalety: gdy sieć jest niestabilna lub nie działa, skrypt service worker natychmiast zwraca zasoby zapisane w pamięci podręcznej.
- Wada: skrypt service worker wymaga dodatkowego pomijania pamięci podręcznej, aby zastąpić pamięć podręczną HTTP i wysyłać żądania typu „Najpierw sieć”.
Podsumowanie
Ze względu na złożoność kombinacji scenariuszy buforowania nie można zaprojektować jednej reguły, która obejmie wszystkie przypadki. Biorąc jednak pod uwagę ustalenia z poprzednich sekcji, przy projektowaniu strategii dotyczących pamięci podręcznej warto wziąć pod uwagę kilka sugestii:
- Logika buforowania skryptu service worker nie musi być spójna z logiką wygaśnięcia buforowania HTTP. Jeśli to możliwe, używaj w skrypcie service worker dłuższej logiki wygaśnięcia, aby dać mu większą kontrolę.
- Buforowanie HTTP nadal odgrywa ważną rolę, ale nie jest niezawodne, gdy sieć jest niestabilna lub wyłączona.
- Przejrzyj strategie buforowania dla każdego zasobu, aby upewnić się, że strategia buforowania skryptu service worker zwraca odpowiednią wartość bez konfliktu z pamięcią podręczną HTTP.