Pamięć podręczna stanu strony: jak bfcache przyspiesza powrót przyciskiem Wstecz

Czym jest pamięć podręczna stanu strony

Pamięć podręczna stanu strony to funkcja przeglądarki, która zamiast niszczyć stronę po przejściu pod inny adres, odkłada ją w całości do pamięci urządzenia. Skrót bfcache pochodzi od angielskiej nazwy back/forward cache, czyli pamięci podręcznej nawigacji wstecz i dalej. Gdy użytkownik wraca, przeglądarka nie pobiera niczego z sieci i niczego nie buduje od nowa, tylko pokazuje zachowany obraz strony.

Zgodnie z opisem w serwisie web.dev w pamięci ląduje pełny stan strony, łącznie z obszarem pamięci używanym przez JavaScript. Wykonywanie skryptów zostaje wstrzymane, a po powrocie wznowione dokładnie w tym miejscu, w którym się zatrzymało. Dotyczy to także odliczanych czasomierzy i obietnic (promise), które jeszcze nie zostały rozstrzygnięte. Dla odwiedzającego oznacza to, że formularz pozostaje wypełniony, lista jest przewinięta do tego samego miejsca, a rozwinięte filtry nadal są rozwinięte.

Funkcję mają wszystkie główne przeglądarki. Web.dev wymienia Chrome (od wersji 96), Firefoksa i Safari. Właściciel strony niczego nie włącza i niczego nie instaluje. Przeglądarka sama ocenia, czy dana strona nadaje się do zachowania, i rezygnuje, jeśli uzna to za ryzykowne. Praca nad bfcache polega więc na usuwaniu przeszkód, a nie na dodawaniu nowego rozwiązania.

Jak często użytkownicy korzystają z przycisku Wstecz

Częściej, niż mogłoby się wydawać. Web.dev powołuje się na dane o korzystaniu z Chrome, z których wynika, że mniej więcej jedna na dziesięć nawigacji na komputerach i jedna na pięć na urządzeniach mobilnych to przejście wstecz lub dalej. Wystarczy przypomnieć sobie typowe zakupy w sklepie internetowym: lista kategorii, karta produktu, powrót do listy, kolejna karta, znowu powrót. Podobnie wygląda czytanie bloga firmowego albo porównywanie ofert kilku wykonawców w wynikach wyszukiwania.

Dla hipotetycznego sklepu z Poznania, w którym klient ogląda kilkanaście produktów z jednej kategorii, każdy powrót do listy bez bfcache oznacza ponowne pobranie dokumentu, uruchomienie skryptów i ułożenie strony. Z działającą pamięcią stanu lista pojawia się od razu, w tym samym miejscu przewinięcia.

Jak długo strona czeka w pamięci

Niezbyt długo, bo pamięć urządzenia jest ograniczona. Przeglądarki usuwają zachowane strony, aby oszczędzać zasoby. Dokumentacja Chrome dotycząca stron z nagłówkiem no-store podaje, że zwykła strona może czekać w pamięci do dziesięciu minut, a strona z tym nagłówkiem do trzech minut. Z tego powodu nie każdy powrót skończy się przywróceniem z pamięci i nie należy oczekiwać stuprocentowej skuteczności.

Czym bfcache różni się od zwykłej pamięci podręcznej przeglądarki

Zwykła pamięć podręczna, nazywana pamięcią HTTP, przechowuje pojedyncze pliki, a bfcache przechowuje gotową, działającą stronę. To dwie niezależne warstwy i jedna nie zastępuje drugiej.

Pamięć HTTP zapisuje odpowiedzi na wcześniejsze zapytania: arkusze stylów, skrypty, obrazy, czasem sam dokument. Dzięki temu przeglądarka nie musi pobierać ich drugi raz, ale nadal musi przeanalizować kod, uruchomić skrypty i narysować stronę. Zasady tej pamięci ustawia się nagłówkami, które omawiamy we wpisie o nagłówkach Cache-Control. W przypadku bfcache cała ta praca jest pomijana, ponieważ w pamięci czeka efekt końcowy. Web.dev podkreśla, że właśnie dlatego przywrócenie z bfcache jest szybsze nawet od najlepiej ustawionej pamięci HTTP.

Warto też odróżnić bfcache od pamięci po stronie serwera, wtyczek zapisujących gotowy kod HTML czy sieci dostarczania treści. Tamte rozwiązania skracają drogę od serwera do przeglądarki przy każdym wejściu. Szerzej opisujemy je we wpisie o rodzajach pamięci podręcznej strony. Pamięć stanu strony działa wyłącznie w przeglądarce jednego użytkownika i dotyczy jednej sytuacji: powrotu.

Dlaczego bfcache poprawia wskaźniki zbierane od użytkowników

Ponieważ przywrócenie strony z pamięci jest liczone jako osobna, bardzo szybka wizyta. Web.dev podaje, że raport o wrażeniach użytkowników Chrome, czyli zbiór danych CrUX, traktuje przywrócenia z bfcache jako odrębne wizyty. Im więcej powrotów obsługuje pamięć stanu, tym więcej bardzo dobrych pomiarów trafia do puli, z której wyliczane są wyniki strony.

Chodzi o trzy podstawowe wskaźniki internetowe, po angielsku Core Web Vitals. Według opisu na web.dev za dobry wynik uznaje się LCP, czyli czas wyświetlenia największego elementu, nie dłuższy niż 2,5 sekundy, INP, czyli czas reakcji na działanie użytkownika, nie dłuższy niż 200 milisekund, oraz CLS, czyli miarę przesunięć układu, nie większą niż 0,1. Ocenia się 75. percentyl wizyt, osobno na telefonach i na komputerach. Przy przywróceniu z pamięci największy element pojawia się praktycznie od razu, a układ nie ma powodu się przesuwać, bo strona jest już ułożona.

Web.dev opisuje też, jak te wartości liczy się dla przywróconej strony: LCP to czas od zdarzenia pageshow do narysowania kolejnej klatki, a INP i CLS zaczynają się od zera. Popularna biblioteka web-vitals uwzględnia takie przywrócenia. Sposoby pracy nad każdym ze wskaźników omawiamy we wpisie Core Web Vitals: jak poprawić LCP, INP i CLS na stronie firmy.

Dlaczego nie widać tego w zwykłym teście szybkości

Test laboratoryjny wczytuje stronę jeden raz, od zera, więc powrotów w ogóle nie bada. Korzyść z bfcache ujawnia się dopiero w danych zbieranych od prawdziwych odwiedzających, które Google pokazuje między innymi w raporcie Podstawowe wskaźniki internetowe w Search Console oraz w górnej części raportu PageSpeed Insights. Różnicę między obydwoma rodzajami pomiaru wyjaśniamy we wpisie o tym, dlaczego wynik testu różni się od danych od użytkowników.

Jest jeszcze jedna pułapka pomiarowa opisana przez web.dev. Jeśli własne narzędzie analityczne mierzy tylko pełne wczytania, to po uruchomieniu bfcache z puli znikają powroty, które zwykle należały do najszybszych wczytań. Średnie mogą wtedy wyglądać gorzej, chociaż odwiedzający odczuwają poprawę. Dlatego pomiary takie jak czas odpowiedzi serwera warto dzielić według rodzaju nawigacji.

Zdarzenie unload: najczęstsza przeszkoda po stronie skryptów

Strona, która nasłuchuje zdarzenia unload, w Chrome i Firefoksie na komputerach nie kwalifikuje się do pamięci stanu. Zdarzenie unload to sygnał wysyłany w chwili, gdy strona jest usuwana, a wiele starszych skryptów używa go do wysłania ostatnich danych lub posprzątania po sobie.

Problem polega na tym, że unload zakłada, iż strona przestaje istnieć. Tymczasem strona odłożona do bfcache istnieje nadal i może wrócić. Web.dev opisuje, że Chrome i Firefox na komputerach rozwiązują tę sprzeczność, rezygnując z zachowania strony, natomiast Safari oraz Chrome na telefonach mogą stronę zachować, ale wtedy zdarzenie unload nie jest wywoływane w sposób niezawodny. W obu przypadkach skrypt oparty na unload działa źle: albo blokuje szybki powrót, albo nie wykonuje swojego zadania.

Z tego powodu zespół Chrome wycofuje to zdarzenie. W dokumencie o wycofywaniu unload czytamy, że na urządzeniach mobilnych zdarzenie często w ogóle się nie uruchamia, bo karty są przenoszone w tło i zamykane przez system, a na komputerach działa dość pewnie, lecz blokuje bfcache. Wycofanie jest wprowadzane stopniowo, wersja po wersji.

Czym zastąpić unload

Dokumentacja Chrome wskazuje trzy zdarzenia, z których każde ma inne zastosowanie. Zdarzenie visibilitychange uruchamia się przy przełączeniu karty, zminimalizowaniu okna lub przejściu na inną stronę, a moment, w którym strona staje się ukryta, jest ostatnią pewną okazją do zapisania danych, na przykład pomiarów analitycznych. Zdarzenie pagehide uruchamia się przy opuszczaniu strony, ponownym wczytaniu lub zamknięciu okna i nie blokuje pamięci stanu. Zdarzenie beforeunload służy do ostrzeżenia o niezapisanych zmianach. Według web.dev nie blokuje ono bfcache we współczesnych przeglądarkach, ale jest zawodne, dlatego zaleca się podłączać je tylko wtedy, gdy użytkownik rzeczywiście ma niezapisane zmiany.

// Wersja blokująca pamięć stanu strony
window.addEventListener('unload', () => {
  wyslijDane();
});

// Wersja zgodna z bfcache
window.addEventListener('pagehide', () => {
  wyslijDane();
});

Co zrobić, gdy unload dodaje obcy skrypt

W praktyce agencji przyczyną rzadko jest kod napisany przez właściciela strony. Częściej unload wnosi zewnętrzny dodatek: okno czatu, wtyczka, starsza biblioteka albo narzędzie pomiarowe. Pierwszym ruchem powinna być aktualizacja takiego dodatku, a jeśli to nie pomaga, zgłoszenie do jego producenta lub wymiana na inny. O kosztach takich dodatków piszemy we wpisie o tym, jak skrypty zewnętrzne spowalniają stronę.

Istnieje też rozwiązanie po stronie serwera. Web.dev i dokumentacja narzędzi deweloperskich Chrome opisują nagłówek zasad uprawnień, który zabrania rejestrowania obsługi unload na stronie, także skryptom zewnętrznym i rozszerzeniom przeglądarki.

Permissions-Policy: unload=()

Przed jego ustawieniem trzeba się upewnić, że żaden potrzebny skrypt nie opiera na unload ważnej funkcji.

Nagłówek Cache-Control: no-store

Nagłówek no-store ustawiony dla dokumentu HTML przez lata wykluczał stronę z pamięci stanu i w części przeglądarek nadal ją wyklucza. Dyrektywa ta mówi przeglądarce, że odpowiedzi nie wolno nigdzie zapisywać, więc odkładanie całej strony do pamięci byłoby z nią sprzeczne.

Skala zjawiska jest duża. Dokumentacja Chrome poświęcona stronom z no-store podaje, że był to najczęstszy powód niekorzystania z pamięci stanu: dotyczył około 17 procent nawigacji w historii na urządzeniach mobilnych i 7 procent na komputerach. Z obserwacji agencji wynika, że nagłówek często obejmuje cały serwis przez domyślne ustawienie systemu, wtyczki lub serwera, chociaż większość podstron nie zawiera niczego poufnego.

Chrome zmienia swoje zachowanie w tej sprawie. Według tej samej dokumentacji przeglądarka może przywrócić z pamięci także stronę z no-store, jeśli jest to bezpieczne. Strona zostaje jednak usunięta z pamięci, gdy zmienią się pliki cookie lub inne dane uwierzytelniające, a także gdy sama wyśle zapytanie i otrzyma odpowiedź z no-store. Czas przechowywania wynosi wtedy trzy minuty. Inne przeglądarki mogą nadal blokować takie strony, dlatego nie należy traktować tej zmiany jako rozwiązania problemu.

Kiedy zostawić no-store, a kiedy go zmienić

Web.dev zaleca stosowanie no-store wyłącznie na stronach z informacjami wrażliwymi. Panel klienta z danymi osobowymi, historia zamówień czy strona z wynikami badań w hipotetycznej przychodni to przykłady podstron, na których nagłówek powinien zostać. Lista usług kancelarii z Krakowa, wpis na blogu czy kategoria w sklepie takich danych nie zawierają.

Jeśli celem jest jedynie to, aby odwiedzający zawsze dostawał świeżą treść, wystarczą dyrektywy no-cache albo max-age=0. Nakazują one przeglądarce potwierdzić aktualność pliku na serwerze przed jego użyciem, ale nie zabraniają zachowania strony w pamięci stanu.

# Tylko dla stron z danymi wrażliwymi
Cache-Control: no-store

# Dla zwykłych podstron, które mają być zawsze aktualne
Cache-Control: no-cache

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl

Otwarte połączenia, odwołania między oknami i ramki

Strona, która w chwili opuszczania utrzymuje otwarte połączenie albo czeka na odpowiedź z sieci, może nie trafić do pamięci stanu. Web.dev wymienia tu otwarte połączenia z bazą IndexedDB, czyli bazą danych wbudowaną w przeglądarkę, trwające zapytania fetch i XMLHttpRequest oraz otwarte połączenia WebSocket i WebRTC, które służą do komunikacji na żywo, na przykład w oknach czatu czy rozmowach wideo. W przypadku WebSocket sytuacja zależy od przeglądarki: według web.dev Chrome od wersji 149 i Safari nie blokują z tego powodu, pozostałe przeglądarki tak.

Zalecane rozwiązanie jest zawsze to samo: zamykać połączenia i odłączać obserwatory w zdarzeniu pagehide, a otwierać je ponownie w zdarzeniu pageshow, kiedy strona wraca. Trzeba przy tym uważać, aby po powrocie nie powstały dwa równoległe połączenia.

window.addEventListener('pagehide', () => {
  if (dbPromise) {
    dbPromise.then(db => db.close());
    dbPromise = null;
  }
});

window.addEventListener('pageshow', () => openDB());

Odwołanie window.opener

Gdy strona została otwarta w nowej karcie przez inną stronę i zachowała do niej odwołanie, przeglądarka może zrezygnować z zachowania jej w pamięci. Web.dev zaleca dodawanie do linków otwieranych w nowej karcie atrybutu rel o wartości noopener, który we współczesnych przeglądarkach jest już ustawieniem domyślnym.

Ramki osadzone na stronie

Ramka, czyli element iframe z mapą, filmem, formularzem rezerwacji lub reklamą, nie jest zachowywana osobno, ale wpływa na stronę, w której jest osadzona. Jeśli skrypt wewnątrz ramki korzysta z funkcji blokujących, cała strona może stracić prawo do pamięci stanu. Web.dev proponuje ograniczanie takich ramek nagłówkiem zasad uprawnień na stronie głównej albo atrybutem sandbox.

Dla właściciela małej witryny praktyczny wniosek jest prosty: każdy osadzony dodatek to potencjalna przyczyna blokady, którą warto wykluczyć testem opisanym poniżej.

Jak przetestować stronę w panelu Aplikacja w narzędziach Chrome

Test trwa kilka sekund i nie wymaga żadnych uprawnień do strony: wystarczy przeglądarka Chrome na komputerze i jej narzędzia deweloperskie. Według dokumentacji narzędzi deweloperskich Chrome należy przejść do panelu Aplikacja, a w grupie Usługi w tle wskazać pozycję poświęconą pamięci podręcznej stanu strony. W polskiej wersji jej nazwa bywa tłumaczona różnie, między innymi jako pamięć podręczna wstecz/wprzód, a w wersji angielskiej brzmi Back/forward cache.

1. Otwarcie badanej podstrony

   Test dotyczy jednego adresu, dlatego warto zacząć od szablonu, na który odwiedzający wracają najczęściej, na przykład listy produktów.

2. Przejście do panelu Aplikacja

   W narzędziach deweloperskich: Aplikacja, następnie Usługi w tle i pozycja pamięci podręcznej stanu strony.

3. Uruchomienie testu

   Po kliknięciu przycisku testu Chrome na chwilę przechodzi pod wewnętrzny adres chrome://terms/ i wraca na badaną stronę. Ten sam efekt daje ręczne użycie przycisków Wstecz i Dalej.

4. Odczytanie wyniku

   Powodzenie potwierdza komunikat o wyświetleniu strony z pamięci podręcznej stanu. W przeciwnym razie pojawia się lista przyczyn.

Co oznaczają trzy grupy przyczyn

Dokumentacja dzieli przyczyny niepowodzenia na trzy rodzaje. Pierwsza grupa to przyczyny, które właściciel strony może usunąć samodzielnie, na przykład obsługa zdarzenia unload. Druga to funkcje, których Chrome jeszcze nie obsługuje w połączeniu z bfcache, więc blokada powinna zniknąć wraz z rozwojem przeglądarki. Trzecia obejmuje przyczyny, na które strona nie ma wpływu. Pracę planuje się wyłącznie wokół pierwszej grupy.

Jeśli blokada pochodzi z osadzonej ramki, dokumentacja radzi rozwinąć sekcję Ramki, która pokazuje, w którym elemencie leży problem. Poprawkę nagłówka można wypróbować bez zmian na serwerze, korzystając z funkcji lokalnego zastępowania nagłówków odpowiedzi w tych samych narzędziach. Dodatkowo web.dev podaje, że Lighthouse od wersji 10.0 zawiera audyt pamięci stanu strony, a osobny audyt ostrzega o obsłudze unload.

Jak ustalić, co dzieje się u prawdziwych użytkowników

Test w narzędziach deweloperskich pokazuje jedną wizytę na jednym komputerze, a o wskaźnikach decyduje ruch na wielu różnych urządzeniach. Do zbierania przyczyn blokady w ruchu rzeczywistym służy właściwość notRestoredReasons, dostępna w Chrome od wersji 123.

Jak opisuje dokumentacja Chrome, właściwość ta jest częścią wpisu o nawigacji w interfejsie pomiaru wydajności. Zwraca adres strony, listę przyczyn oraz takie same dane dla zagnieżdżonych ramek z tej samej domeny. Wśród przykładowych wartości są unload-listener oraz response-cache-control-no-store. Dla ramek z obcych domen szczegóły są ukrywane, a strona główna otrzymuje jedynie ogólną przyczynę masked.

const wpisy = performance.getEntriesByType('navigation');
wpisy.forEach((wpis) => {
  console.log(wpis.notRestoredReasons);
});

Wartość null oznacza brak przyczyn blokady, ale nie potwierdza, że pamięć stanu została użyta. Do tego służy pole persisted w zdarzeniu pageshow: ma wartość true tylko wtedy, gdy strona wróciła z bfcache.

Odsłony w analityce

Przywrócenie z pamięci nie jest nowym wczytaniem, więc skrypt analityczny nie uruchamia się ponownie. Web.dev ostrzega, że wiele bibliotek nie liczy takich powrotów jako odsłon, co zaniża statystyki. Rozwiązaniem jest wysłanie odsłony w zdarzeniu pageshow, gdy pole persisted ma wartość true.

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    gtag('event', 'page_view');
  }
});

Przed dodaniem takiego kodu trzeba ustalić, czy używane narzędzie nie robi tego samo, aby nie liczyć odsłon podwójnie.

Co zrobić, żeby przywrócona strona nie pokazywała nieaktualnych danych

Strona wracająca z pamięci wygląda dokładnie tak, jak w chwili jej opuszczenia, więc wszystko, co zmieniło się w międzyczasie, trzeba odświeżyć skryptem. Web.dev zaleca robić to w zdarzeniu pageshow, po stwierdzeniu, że pole persisted ma wartość true.

Najbardziej typowy przypadek to koszyk. Klient hipotetycznego sklepu dodaje produkt na karcie produktu, po czym wraca przyciskiem Wstecz do listy. Lista pochodzi z pamięci, więc licznik koszyka w nagłówku pokazuje stan sprzed dodania. Wystarczy, aby po powrocie skrypt pobrał aktualną liczbę produktów i podmienił ją w nagłówku.

Drugi przypadek dotyczy bezpieczeństwa. Jeśli użytkownik wyloguje się na wspólnym komputerze, kolejna osoba nie powinna zobaczyć jego danych po użyciu przycisku Wstecz. Web.dev podaje wzorzec, w którym po przywróceniu strona sprawdza obecność oczekiwanego pliku cookie i w razie jego braku wczytuje się ponownie.

window.addEventListener('pageshow', (event) => {
  if (event.persisted && !document.cookie.match(/my-cookie/)) {
    location.reload();
  }
});

Typowe pomyłki i kolejność prac

Najczęstszą pomyłką jest przekonanie, że szybki serwer i dobrze ustawiona pamięć plików załatwiają sprawę powrotów. Tymczasem jeden nagłówek lub jeden stary skrypt potrafi wyłączyć pamięć stanu w całym serwisie, czego nie widać w zwykłym teście szybkości.

Często testuje się też wyłącznie stronę główną, chociaż powroty dotyczą głównie list: kategorii, wyników wyszukiwania w serwisie, archiwów bloga. Ryzykowne jest usunięcie no-store z całego serwisu jednym ruchem, razem z panelem klienta, w którym nagłówek miał uzasadnienie. Nie należy wreszcie oczekiwać, że każdy powrót będzie obsłużony z pamięci: web.dev zaznacza, że nie obejmuje ona na przykład ponownego otwarcia zamkniętej karty ani powielenia karty.

• Test w panelu Aplikacja wykonany osobno dla strony głównej, listy, karty produktu lub usługi oraz wpisu.
• Brak obsługi zdarzenia unload we własnym kodzie i w dodatkach zewnętrznych.
• Nagłówek no-store tylko na podstronach z danymi wrażliwymi.
• Połączenia zamykane w zdarzeniu pagehide i otwierane ponownie w pageshow.
• Linki otwierane w nowej karcie z atrybutem rel o wartości noopener.
• Koszyk i stan zalogowania odświeżane po przywróceniu strony.
• Odsłony po przywróceniu zliczane w analityce dokładnie raz.
• Ponowny test po każdej aktualizacji motywu, wtyczek i skryptów zewnętrznych.

Pomoc specjalisty przydaje się wtedy, gdy przyczyna leży w konfiguracji serwera, w kodzie motywu albo w dodatku, którego nie można po prostu wyłączyć. Zgodność z pamięcią stanu sprawdzamy podczas prac obejmujących SEO techniczne, a pełny obraz stanu witryny daje audyt SEO. Nie obiecujemy przy tym określonych pozycji w wynikach wyszukiwania: usunięcie blokad poprawia wygodę odwiedzających i dane o szybkości, a widoczność zależy od wielu innych czynników.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl