Pamięć podręczna stanu strony internetowej

Philip Walton

Barry Pollard

Data publikacji: 25 maja 2023 r., ostatnia aktualizacja: 2 lipca 2026 r.

Pamięć podręczna stanu strony internetowej (bfcache) to rodzaj optymalizacji przeglądarki, która umożliwia błyskawiczną nawigację w obu kierunkach. Znacznie ułatwia użytkownikom przeglądanie stron – zwłaszcza w przypadku wolniejszych sieci i urządzeń.

Jako deweloperzy stron internetowych musimy wiedzieć, jak optymalizować strony pod kątem pamięci podręcznej typu „wstecz/do przodu”, aby użytkownicy mogli korzystać z jej zalet.

Zgodność z przeglądarką

Wszystkie główne przeglądarki, w tym Chrome od wersji 96, Firefox i Safari, mają pamięć podręczną wstecz/do przodu.

Podstawy pamięci podręcznej stanu strony internetowej

W przypadku pamięci podręcznej wstecz/dalej (bfcache) zamiast niszczyć stronę, gdy użytkownik z niej wychodzi, odkładamy zniszczenie i wstrzymujemy wykonywanie kodu JavaScript. Jeśli użytkownik szybko wróci, ponownie wyświetlimy stronę i wznowimy wykonywanie kodu JavaScript. Dzięki temu użytkownik może niemal natychmiast przejść do innej strony.

Ile razy zdarzyło Ci się odwiedzić witrynę i kliknąć link, aby przejść do innej strony, a potem zorientować się, że nie o to Ci chodziło, i kliknąć przycisk Wstecz? W takiej sytuacji pamięć podręczna stanu strony internetowej może znacznie przyspieszyć wczytywanie poprzedniej strony:

Obejrzyj ten film, aby zobaczyć, jak działa pamięć podręczna stanu strony internetowej i jak może przyspieszyć nawigację:

W filmie przykład z pamięcią podręczną bfcache jest znacznie szybszy niż przykład bez niej.

Pamięć podręczna bfcache nie tylko przyspiesza nawigację, ale też zmniejsza zużycie danych, ponieważ zasoby nie muszą być pobierane ponownie.

Dane dotyczące korzystania z Chrome pokazują, że 1 na 10 nawigacji na komputerze i 1 na 5 na urządzeniu mobilnym to nawigacja wstecz lub do przodu. Dzięki włączonej pamięci podręcznej przeglądarki mogłyby codziennie eliminować przesyłanie danych i czas ładowania miliardów stron internetowych.

Jak działa „pamięć podręczna”

„Pamięć podręczna” używana przez bfcache różni się od pamięci podręcznej HTTP, która odgrywa własną rolę w przyspieszaniu powrotów na poprzednią stronę. Pamięć podręczna stanu strony internetowej to migawka całej strony w pamięci, w tym sterty JavaScriptu, natomiast pamięć podręczna HTTP zawiera tylko odpowiedzi na wcześniej wysłane żądania. Bardzo rzadko zdarza się, aby wszystkie żądania potrzebne do załadowania strony były realizowane z pamięci podręcznej HTTP, dlatego powtórne wizyty z użyciem przywracania z pamięci podręcznej stanu strony internetowej są zawsze szybsze niż nawet najlepiej zoptymalizowane nawigacje bez użycia tej pamięci.

Zamrożenie strony, aby później móc ją ponownie włączyć, jest dość skomplikowane, jeśli chodzi o najlepszy sposób zachowania kodu w trakcie wykonywania. Na przykład jak obsługujesz setTimeout() wywołania, w których upłynął limit czasu, gdy strona znajdowała się w pamięci podręcznej przeglądarki?

Odpowiedź jest taka, że przeglądarki wstrzymują wszystkie oczekujące timery lub nierozwiązane obietnice na stronach w pamięci podręcznej, w tym prawie wszystkie oczekujące zadania w kolejkach zadań JavaScript, i wznawiają przetwarzanie zadań, jeśli strona zostanie przywrócona z pamięci podręcznej.

W niektórych przypadkach, np. w przypadku limitów czasu i obietnic, ryzyko jest dość niskie, ale w innych może to prowadzić do niejasnego lub nieoczekiwanego działania. Jeśli na przykład przeglądarka wstrzyma zadanie wymagane w ramach transakcji IndexedDB, może to wpłynąć na inne otwarte karty w tej samej domenie, ponieważ do tych samych baz danych IndexedDB może mieć dostęp wiele kart jednocześnie. W rezultacie przeglądarki zwykle nie będą próbować zapisywać w pamięci podręcznej stron w trakcie transakcji IndexedDB ani podczas korzystania z interfejsów API, które mogą mieć wpływ na inne strony.

Więcej informacji o tym, jak korzystanie z różnych interfejsów API wpływa na możliwość korzystania ze stanu strony internetowej w pamięci podręcznej, znajdziesz w artykule Optymalizowanie stron pod kątem pamięci podręcznej stanu strony internetowej.

Pamięć podręczna stanu strony internetowej i elementy iframe

Jeśli strona zawiera umieszczone elementy iframe, nie kwalifikują się one oddzielnie do korzystania z pamięci podręcznej stanu strony internetowej. Jeśli na przykład przejdziesz do innego adresu URL w elemencie iframe, poprzednia treść nie zostanie zapisana w pamięci podręcznej, a gdy cofniesz się, przeglądarka „cofnie się” w elemencie iframe, a nie w ramce głównej. Przechodzenie wstecz w elemencie iframe nie będzie jednak korzystać z pamięci podręcznej.

Gdy jednak ramka główna zostanie przywrócona z pamięci podręcznej stanu strony internetowej, osadzone elementy iframe zostaną przywrócone w stanie, w jakim były, gdy strona została zapisana w pamięci podręcznej stanu strony internetowej.

Główna ramka może też zostać zablokowana przed użyciem pamięci podręcznej stanu strony internetowej, jeśli osadzona ramka iframe używa interfejsów API, które to blokują. Aby tego uniknąć, możesz użyć zasady dotyczącej uprawnień ustawionej w głównej ramce lub sandboxatrybutów.

Pamięć podręczna wstecz i do przodu oraz aplikacje jednostronicowe

Pamięć podręczna bfcache działa w przypadku nawigacji zarządzanej przez przeglądarkę, więc nie działa w przypadku „miękkiej nawigacji” w aplikacji jednostronicowej (SPA). Pamięć podręczna bfcache może jednak pomóc w przypadku powrotu do aplikacji SPA, zamiast ponownego pełnego inicjowania jej od początku.

Interfejsy API do obserwowania pamięci podręcznej stanu strony internetowej

Chociaż bfcache to optymalizacja, którą przeglądarki wykonują automatycznie, deweloperzy powinni wiedzieć, kiedy to się dzieje, aby mogli zoptymalizować pod tym kątem swoje strony i odpowiednio dostosować wszelkie dane lub pomiary wydajności.

Głównymi zdarzeniami używanymi do obserwowania bfcache są zdarzenia przejścia strony pageshow i pagehide, które są obsługiwane przez większość przeglądarek.

Nowsze zdarzenia cyklu życia strony – freeze i resume – są też wysyłane, gdy strony wchodzą do pamięci podręcznej lub ją opuszczają, a także w innych sytuacjach, np. gdy karta w tle zostaje zamrożona, aby zminimalizować zużycie procesora. Te zdarzenia są obsługiwane tylko w przeglądarkach opartych na Chromium.

Obserwowanie, kiedy strona jest przywracana z pamięci podręcznej typu „wstecz/do przodu”

Zdarzenie pageshow jest wywoływane bezpośrednio po zdarzeniu load podczas początkowego wczytywania strony i za każdym razem, gdy strona jest przywracana z pamięci podręcznej typu „wstecz/do przodu”. Zdarzenie pageshow ma właściwość persisted, która przyjmuje wartość true, jeśli strona została przywrócona z pamięci podręcznej stanu strony internetowej, a w przeciwnym razie – false. Właściwość persisted umożliwia odróżnienie zwykłego wczytywania strony od przywracania z pamięci podręcznej stanu strony internetowej. Na przykład:

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    console.log('This page was restored from the bfcache.');
  } else {
    console.log('This page was loaded normally.');
  }
});

W przeglądarkach obsługujących interfejs Page Lifecycle API zdarzenie resume jest uruchamiane, gdy strony są przywracane z pamięci podręcznej (bezpośrednio przed zdarzeniem pageshow) oraz gdy użytkownik ponownie odwiedza zamrożoną kartę w tle. Jeśli chcesz zaktualizować stan strony po jej zamrożeniu (dotyczy to też stron w pamięci podręcznej przeglądarki), możesz użyć zdarzenia resume, ale jeśli chcesz zmierzyć współczynnik trafień w pamięci podręcznej przeglądarki, musisz użyć zdarzenia pageshow. W niektórych przypadkach może być konieczne użycie obu tych metod.

Szczegółowe informacje o sprawdzonych metodach pomiaru pamięci podręcznej stanu strony internetowej znajdziesz w artykule Jak pamięć podręczna stanu strony internetowej wpływa na analitykę i pomiar skuteczności.

Obserwowanie, kiedy strona wchodzi do pamięci podręcznej typu „wstecz/do przodu”

Zdarzenie pagehide jest wywoływane, gdy strona jest wyładowywana lub gdy przeglądarka próbuje umieścić ją w pamięci podręcznej.

Zdarzenie pagehide ma też właściwość persisted. Jeśli jest to false, możesz mieć pewność, że strona nie zostanie wkrótce zapisana w pamięci podręcznej stanu strony internetowej. persistedtrue nie gwarantuje jednak, że strona zostanie zapisana w pamięci podręcznej. Oznacza to, że przeglądarka zamierza zapisać stronę w pamięci podręcznej, ale mogą wystąpić inne czynniki, które to uniemożliwiają.

window.addEventListener('pagehide', (event) => {
  if (event.persisted) {
    console.log('This page *might* be entering the bfcache.');
  } else {
    console.log('This page will unload normally and be discarded.');
  }
});

Podobnie zdarzenie freeze jest wywoływane natychmiast po zdarzeniu pagehide, jeśli wartość persisted to true, ale oznacza to tylko, że przeglądarka zamierza zapisać stronę w pamięci podręcznej. Może jednak odrzucić zgłoszenie z kilku powodów, które wyjaśnimy później.

Optymalizacja stron pod kątem pamięci podręcznej typu „wstecz/do przodu”

Nie wszystkie strony są przechowywane w pamięci podręcznej stanu strony internetowej, a nawet jeśli tak się stanie, nie pozostaną tam bezterminowo. Aby zmaksymalizować współczynnik trafień w pamięci podręcznej, deweloperzy muszą wiedzieć, co sprawia, że strony kwalifikują się do korzystania z pamięci podręcznej typu „wstecz/do przodu” (i co je z niej wyklucza).

W sekcjach poniżej znajdziesz sprawdzone metody, które zwiększą prawdopodobieństwo, że przeglądarka będzie mogła zapisywać Twoje strony w pamięci podręcznej.

Nigdy nie używaj zdarzenia unload

Najważniejszym sposobem optymalizacji pod kątem pamięci podręcznej typu „wstecz/do przodu” we wszystkich przeglądarkach jest nigdy nieużywanie zdarzenia unload. Nigdy!

Zdarzenie unload jest problematyczne dla przeglądarek, ponieważ jest starsze niż pamięć podręczna typu „wstecz/do przodu”. Wiele stron w internecie działa w oparciu o (rozsądne) założenie, że strona przestanie istnieć po wywołaniu zdarzenia unload. Stanowi to problem, ponieważ wiele z tych stron zostało również zbudowanych z założeniem, że zdarzenie unload będzie wywoływane za każdym razem, gdy użytkownik opuści stronę, co nie jest już prawdą (i nie było prawdą od dłuższego czasu).

Przeglądarki stają więc przed dylematem: muszą wybrać między czymś, co może poprawić wygodę użytkowników, ale może też spowodować nieprawidłowe działanie strony.

Na komputerach Chrome i Firefox sprawiają, że strony, które dodają odbiornik unload, nie kwalifikują się do pamięci podręcznej typu „wstecz/do przodu”. Jest to mniej ryzykowne, ale dyskwalifikuje wiele stron. Safari próbuje zapisywać w pamięci podręcznej niektóre strony z detektorem zdarzeń unload, ale aby zmniejszyć ryzyko awarii, nie uruchamia zdarzenia unload, gdy użytkownik opuszcza stronę, co sprawia, że zdarzenie jest bardzo zawodne.

Na urządzeniach mobilnych Chrome i Safari będą próbować zapisywać w pamięci podręcznej strony z detektorem zdarzenia unload, ponieważ ryzyko wystąpienia problemów jest mniejsze ze względu na to, że zdarzenie unload zawsze było bardzo zawodne na urządzeniach mobilnych. Firefox traktuje strony, które używają unload, jako niekwalifikujące się do korzystania z pamięci podręcznej stanu strony internetowej, z wyjątkiem systemu iOS, w którym wszystkie przeglądarki korzystają z silnika renderowania WebKit, a więc działają jak Safari.

Zamiast zdarzenia unload używaj zdarzenia pagehide. Zdarzenie pagehide jest aktywowane we wszystkich przypadkach, w których aktywowane jest zdarzenie unload, a także wtedy, gdy strona jest umieszczana w pamięci podręcznej przeglądarki.

Lighthouse ma no-unload-listeners audyt, który ostrzega deweloperów, jeśli jakikolwiek kod JavaScript na ich stronach (w tym pochodzący z bibliotek innych firm) dodaje unload detektor zdarzeń.

Ze względu na jego zawodność i wpływ na wydajność pamięci podręcznej Chrome planuje wycofać zdarzenie unload.

Używanie zasady dotyczącej uprawnień, aby uniemożliwić używanie na stronie procedur obsługi wyładowywania

Witryny, które nie używają modułów obsługi zdarzeń unload, mogą zapobiec ich dodawaniu, korzystając z zasad dotyczących uprawnień.

Permissions-Policy: unload=()

Zapobiega to również spowalnianiu witryny przez firmy zewnętrzne lub rozszerzenia, które dodają procedury obsługi zwalniania i powodują, że witryna nie kwalifikuje się do korzystania z pamięci podręcznej.

Warunkowe dodawanie tylko beforeunload odbiorców

Zdarzenie beforeunload nie powoduje, że strony nie kwalifikują się do pamięci podręcznej stanu strony internetowej w nowoczesnych przeglądarkach, ale wcześniej tak było i nadal jest ono zawodne, więc unikaj jego używania, chyba że jest to absolutnie konieczne.

W odróżnieniu od zdarzenia unload istnieją jednak uzasadnione przypadki użycia zdarzenia beforeunload. Może to być na przykład ostrzeżenie, że użytkownik ma niezapisane zmiany, które utraci, jeśli opuści stronę. W takim przypadku zalecamy dodawanie beforeunload detektorów tylko wtedy, gdy użytkownik ma niezapisane zmiany, a następnie natychmiastowe usuwanie ich po zapisaniu tych zmian.

window.addEventListener('beforeunload', (event) => {
  if (pageHasUnsavedChanges()) {
    event.preventDefault();
    return event.returnValue = 'Are you sure you want to exit?';
  }
});

function beforeUnloadListener(event) {
  event.preventDefault();
  return event.returnValue = 'Are you sure you want to exit?';
};

// A function that invokes a callback when the page has unsaved changes.
onPageHasUnsavedChanges(() => {
  window.addEventListener('beforeunload', beforeUnloadListener);
});

// A function that invokes a callback when the page's unsaved changes are resolved.
onAllChangesSaved(() => {
  window.removeEventListener('beforeunload', beforeUnloadListener);
});

Zminimalizuj użycie Cache-Control: no-store

Cache-Control: no-store to nagłówek HTTP, który serwery internetowe mogą ustawiać w odpowiedziach, aby poinstruować przeglądarkę, że nie ma ona przechowywać odpowiedzi w żadnej pamięci podręcznej HTTP. Jest on używany w przypadku zasobów zawierających poufne informacje o użytkownikach, np. stron wymagających logowania.

Chociaż pamięć podręczna stanu strony internetowej nie jest pamięcią podręczną HTTP, w przeszłości, gdy wartość Cache-Control: no-store była ustawiona w zasobie strony (w przeciwieństwie do dowolnego zasobu podrzędnego), przeglądarki nie przechowywały strony w pamięci podręcznej stanu strony internetowej, więc strony używające Cache-Control: no-store mogą nie kwalifikować się do korzystania z tej pamięci. Pracujemy nad zmianą tego zachowania w Chrome w sposób chroniący prywatność.

Ponieważ Cache-Control: no-store ogranicza możliwość korzystania przez stronę z pamięci podręcznej stanu strony internetowej, należy go ustawiać tylko na stronach zawierających informacje poufne, w przypadku których buforowanie w jakiejkolwiek formie jest niewłaściwe.

W przypadku stron, które muszą zawsze wyświetlać aktualne treści (i nie zawierają informacji poufnych), używaj tagów Cache-Control: no-cache lub Cache-Control: max-age=0. Te dyrektywy nakazują przeglądarce ponowne sprawdzenie treści przed ich wyświetleniem i nie mają wpływu na kwalifikowanie się strony do pamięci podręcznej typu „wstecz/do przodu”.

Pamiętaj, że gdy strona jest przywracana z pamięci podręcznej stanu strony internetowej, jest przywracana z pamięci, a nie z pamięci podręcznej HTTP. W rezultacie dyrektywy takie jak Cache-Control: no-cache czy Cache-Control: max-age=0 nie są brane pod uwagę i przed wyświetleniem treści użytkownikowi nie następuje ponowna weryfikacja.

Zapewnia to jednak prawdopodobnie większy komfort użytkownikom, ponieważ przywracanie z pamięci podręcznej jest natychmiastowe, a strony nie pozostają w niej zbyt długo, więc jest mało prawdopodobne, że treści będą nieaktualne. Jeśli jednak Twoje treści zmieniają się z minuty na minutę, możesz pobrać aktualizacje za pomocą zdarzenia pageshow, jak opisano w następnej sekcji.

Aktualizowanie nieaktualnych lub danych wrażliwych po przywróceniu z pamięci podręcznej

Jeśli witryna przechowuje stan użytkownika, zwłaszcza poufne informacje o nim, dane te muszą zostać zaktualizowane lub wyczyszczone po przywróceniu strony z pamięci podręcznej typu „wstecz/do przodu”.

Jeśli na przykład użytkownik przejdzie na stronę płatności, a następnie zaktualizuje koszyk na zakupy, przechodzenie wstecz może spowodować wyświetlenie nieaktualnych informacji, jeśli z pamięci podręcznej bfcache zostanie przywrócona nieaktualna strona.

Inny, ważniejszy przykład to sytuacja, w której użytkownik wyloguje się z witryny na komputerze publicznym, a następnie kolejny użytkownik kliknie przycisk Wstecz. Może to potencjalnie ujawnić dane prywatne, które użytkownik uznał za usunięte po wylogowaniu.

Aby uniknąć takich sytuacji, zawsze aktualizuj stronę po zdarzeniu pageshow, jeśli event.persisted ma wartość true:

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // Do any checks and updates to the page
  }
});

Najlepiej byłoby aktualizować treści w miejscu, ale w przypadku niektórych zmian możesz wymusić pełne ponowne wczytanie. Poniższy kod sprawdza obecność pliku cookie specyficznego dla witryny w zdarzeniu pageshow i ponownie wczytuje stronę, jeśli plik cookie nie zostanie znaleziony:

window.addEventListener('pageshow', (event) => {
  if (event.persisted && !document.cookie.match(/my-cookie)) {
    // Force a reload if the user has logged out.
    location.reload();
  }
});

Odświeżanie ma tę zaletę, że zachowuje historię (aby umożliwić nawigację do przodu), ale w niektórych przypadkach przekierowanie może być bardziej odpowiednie.

Reklamy i przywracanie z pamięci podręcznej typu „wstecz/do przodu”

Jako wydawca możesz chcieć odświeżać reklamy przy każdym przejściu do poprzedniej lub następnej strony. Uniemożliwianie korzystania z pamięci podręcznej stanu strony internetowej za pomocą Cache-Control: no-store to złe podejście, które pogarsza wydajność dla użytkowników.

Zamiast tego możesz zachować kwalifikowanie się stron do pamięci podręcznej typu „wstecz/do przodu” i odświeżać tylko reklamy. Niektóre biblioteki tagów reklam, np. tag wydawcy Google (GPT), automatycznie odświeżają aktywnie wyświetlane boksy reklamowe, gdy użytkownik powróci na stronę za pomocą przywracania z pamięci podręcznej wstecz/dalej. Jeśli Twoja biblioteka tagów reklam nie wykonuje tej czynności, a chcesz, aby reklamy były odświeżane, możesz użyć zdarzenia pageshow, aby wykrywać przywracanie z pamięci podręcznej przeglądarki i wywoływać odświeżanie reklamy.

Unikaj odniesień do window.opener

W starszych przeglądarkach, jeśli strona została otwarta za pomocą window.open() z linku z atrybutem target=_blank bez określenia atrybutu rel="noopener", strona otwierająca miała odniesienie do obiektu okna otwartej strony.

Oprócz zagrożenia dla bezpieczeństwa strona z odwołaniem window.opener o wartości innej niż null nie może być bezpiecznie umieszczona w pamięci podręcznej przeglądarki, ponieważ mogłoby to spowodować uszkodzenie stron, które próbują uzyskać do niej dostęp.

Dlatego najlepiej unikać tworzenia odwołań window.opener. Możesz to zrobić, używając w miarę możliwości rel="noopener" (pamiętaj, że jest to teraz domyślne ustawienie we wszystkich nowoczesnych przeglądarkach). Jeśli Twoja witryna wymaga otwarcia okna i sterowania nim za pomocą window.postMessage() lub bezpośredniego odwoływania się do obiektu okna, ani otwarte okno, ani otwierająca je strona nie będą kwalifikować się do korzystania z pamięci podręcznej.

Zamykanie otwartych połączeń, zanim użytkownik opuści stronę

Jak wspomnieliśmy wcześniej, gdy strona jest przechowywana w pamięci podręcznej stanu strony internetowej, wszystkie zaplanowane zadania JavaScript są wstrzymywane i wznawiane, gdy strona jest wyjmowana z pamięci podręcznej.

Jeśli te zaplanowane zadania JavaScriptu mają dostęp tylko do interfejsów DOM API lub innych interfejsów API ograniczonych do bieżącej strony, wstrzymanie ich, gdy strona nie jest widoczna dla użytkownika, nie spowoduje żadnych problemów.

Jeśli jednak te zadania są powiązane z interfejsami API, które są też dostępne z innych stron w tej samej domenie (np. IndexedDB, Web Locks, WebSockets), może to być problematyczne, ponieważ wstrzymanie tych zadań może uniemożliwić uruchomienie kodu w innych kartach.

W związku z tym w tych sytuacjach niektóre przeglądarki nie będą próbować umieścić strony w pamięci podręcznej typu „wstecz/do przodu”:

• Strony z otwartym połączeniem IndexedDB.
• Strony z trwającym żądaniem fetch() lub XMLHttpRequest.
• Strony z otwartym połączeniem WebSocket lub WebRTC. Chrome (od wersji 149) i Safari nie blokują otwartych połączeń WebSocket, ale inne przeglądarki to robią.

Jeśli Twoja strona korzysta z któregoś z tych interfejsów API, zdecydowanie zalecamy zamykanie połączeń oraz usuwanie lub odłączanie obserwatorów podczas zdarzenia pagehide lub freeze. Dzięki temu przeglądarka może bezpiecznie zapisać stronę w pamięci podręcznej bez ryzyka wpływu na inne otwarte karty.

Jeśli strona zostanie przywrócona z pamięci podręcznej, możesz ponownie otworzyć lub połączyć się z tymi interfejsami API podczas zdarzenia pageshow lub resume albo skonfigurować ich automatyczne ponowne otwieranie za pomocą zdarzeń error lub close. Jeśli używasz wielu zdarzeń, nie otwieraj wielu połączeń.

Przykład poniżej pokazuje, jak zadbać o to, aby strony korzystające z IndexedDB kwalifikowały się do bfcache, zamykając otwarte połączenie w detektorze zdarzeń pagehide:

let dbPromise;
function openDB() {
  if (!dbPromise) {
    dbPromise = new Promise((resolve, reject) => {
      const req = indexedDB.open('my-db', 1);
      req.onupgradeneeded = () => req.result.createObjectStore('keyval');
      req.onerror = () => reject(req.error);
      req.onsuccess = () => resolve(req.result);
    });
  }
  return dbPromise;
}

// Close the connection to the database when the user leaves.
window.addEventListener('pagehide', () => {
  if (dbPromise) {
    dbPromise.then(db => db.close());
    dbPromise = null;
  }
});

// Open the connection when the page is loaded or restored from bfcache.
window.addEventListener('pageshow', () => openDB());

Sprawdzanie, czy strony można zapisywać w pamięci podręcznej

Narzędzia deweloperskie w Chrome mogą pomóc Ci przetestować strony, aby upewnić się, że są zoptymalizowane pod kątem pamięci podręcznej typu „wstecz/do przodu”, i wykryć problemy, które mogą uniemożliwiać ich kwalifikację.

Aby przetestować stronę:

1. Otwórz stronę w Chrome.
2. W Narzędziach deweloperskich otwórz Aplikacja –> Pamięć podręczna „wstecz-dalej”.
3. Kliknij przycisk Uruchom test. Narzędzia deweloperskie próbują następnie przejść do innej strony i wrócić, aby sprawdzić, czy można przywrócić stronę z pamięci podręcznej typu „wstecz/do przodu”.