Pamięć podręczna stanu strony internetowej

Philip Walton

Barry Pollard

Pamięć podręczna stanu strony internetowej (bfcache) to optymalizacja przeglądarki, która umożliwia nawigacji wstecz i do przodu. Znacznie usprawnia przeglądanie, zwłaszcza użytkownikom korzystającym z wolniejszych sieci i urządzeń.

Osoby tworzące strony internetowe powinny wiedzieć, jak zoptymalizować strony pod kątem pamięci podręcznej stanu strony internetowej, tak aby użytkownicy odnieśli korzyści.

Zgodność z przeglądarką

Funkcja bfcache od wielu lat jest obsługiwana zarówno w Firefoksie, jak i w Safari na komputerach i urządzeniach mobilnych.

Począwszy od wersji 86 Chrome włączył funkcję Bfcache w przypadku nawigacji w innych witrynach na Androidzie u niewielkiego odsetka użytkowników. W kolejnych wersjach stopniowo wdrażaliśmy dodatkową obsługę. Od wersji 96 funkcja bfcache jest włączona dla wszystkich użytkowników Chrome na komputerach i urządzeniach mobilnych.

podstawy Bfcache

bfcache to pamięć podręczna, która przechowuje pełny zrzut ekranu strony (w tym stertę JavaScriptu) podczas opuszczania aplikacji. Po zapamiętywaniu całej strony przeglądarka może ją szybko przywrócić, jeśli użytkownik zdecyduje się do niej wrócić.

Ile razy zdarzyło Ci się odwiedzić witrynę i kliknąć link prowadzący do innej strony, a potem zdać sobie sprawę, że to nie jest to, o co Ci chodzi, i kliknąć przycisk Wstecz? Wtedy bfcache może mieć duży wpływ na szybkość wczytywania poprzedniej strony:

Obejrzyj ten film o działaniu funkcji bfcache, aby dowiedzieć się, jak przyspiesza ona nawigację:

Na tym filmie przykład z pamięcią bfcache jest nieco szybszy niż bez niej.

Funkcja bfcache nie tylko przyspiesza nawigację, ale też zmniejsza wykorzystanie danych, ponieważ zasobów nie trzeba ponownie pobierać.

Dane o korzystaniu z Chrome wskazują, że 1 na 10 stron nawigacyjnych na komputerze i 1 na 5 na urządzeniach mobilnych wyświetla się wstecz lub do przodu. Po włączeniu funkcji bfcache przeglądarki mogą wyeliminować czas przesyłania danych i spędzania czasu na ładowaniu miliardów stron internetowych każdego dnia.

Działanie „pamięci podręcznej” działa

Pamięć podręczna używana przez bfcache różni się od pamięci podręcznej HTTP, która odgrywa swoją rolę w przyspieszaniu powtórzeń nawigacji. Parametr bfcache to zrzut całej strony w pamięci, łącznie z stertą JavaScriptu, podczas gdy pamięć podręczna HTTP zawiera tylko odpowiedzi na wcześniej wysłane żądania. Ze względu na to, że wszystkie żądania wczytywania strony z pamięci podręcznej HTTP są bardzo rzadko realizowane, powtórne wizyty z wykorzystaniem funkcji przywracania pamięci podręcznej stanu strony internetowej są zawsze szybsze niż nawet najbardziej zoptymalizowana nawigacja niekorzystająca z pamięci podręcznej stanu strony internetowej.

Tworzenie zrzutu strony w pamięci wiąże się jednak z pewnością złożoności sposobów zachowania najlepszego kodu w toku. Jak na przykład obsługiwać wywołania funkcji setTimeout(), w przypadku których przekroczono limit czasu, gdy strona znajduje się w pamięci podręcznej stanu strony internetowej?

Odpowiedzią jest to, że przeglądarki wstrzymują wszystkie oczekujące liczniki czasu lub niespełnione obietnice dotyczące stron w pamięci podręcznej stanu strony internetowej, w tym niemal wszystkie oczekujące zadania w kolejkach zadań JavaScript, i wznawiają zadania przetwarzania po przywróceniu strony z pamięci podręcznej stanu strony internetowej.

W niektórych przypadkach, np. w przypadku przekroczenia czasu oczekiwania lub obietnic, jest to dość niewielkie ryzyko, ale w innych może prowadzić do dezorientacji lub nieoczekiwanego działania. Jeśli na przykład przeglądarka wstrzymuje zadanie wymagane w ramach IndexedDB transakcja, może mieć wpływ na inne otwarte karty w tym samym punkcie, ponieważ dostęp do tych samych baz danych IndexedDB jest możliwy jednocześnie na wielu kartach. W związku z tym przeglądarki zwykle nie próbują 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 różne wykorzystanie interfejsu API wpływa na możliwość obsługi pamięci podręcznej stanu strony internetowej (bfcache), znajdziesz w artykule Optymalizacja stron pod kątem pamięci podręcznej stanu strony internetowej.

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

Jeśli strona zawiera umieszczone elementy iframe, same elementy iframe nie kwalifikują się do umieszczenia w pamięci podręcznej stanu strony internetowej. Jeśli na przykład przejdziesz do innej strony w elemencie iframe, a następnie na nią wrócisz, przeglądarka przełączy się na „Wstecz” w elemencie iframe, a nie w ramce głównej, ale nawigacja wstecz w ramach elementu iframe nie będzie używać parametru bfcache.

Możliwość korzystania z pamięci podręcznej stanu strony głównej można też zablokować, jeśli umieszczony element iframe używa interfejsów API, które to blokują. Aby tego uniknąć, można użyć zasad dotyczących uprawnień ustawionych w ramce głównej lub użyć atrybutów sandbox.

Pamięć podręczna i aplikacje na jednej stronie (SPA)

Funkcja bfcache działa z nawigacjami zarządzanymi przez przeglądarkę, dlatego nie działa w przypadku „miękkiej nawigacji”. w aplikacji jednostronicowej (SPA). Jednak pole bfcache może być pomocne w przypadku powrotu do SPA zamiast ponownego pełnego inicjowania tej aplikacji od początku.

Interfejsy API do obserwowania funkcji bfcache

Choć bfcache to optymalizacja, którą przeglądarki wykonują automatycznie, ważne jest, aby deweloperzy wiedzieli, kiedy ma to miejsce, aby mogli zoptymalizować swoje strony i odpowiednio dostosować wszelkie dane lub pomiary wydajności.

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

Najnowsze zdarzenia cyklu życia strony – freeze i resume – są również wysyłane, gdy strona otwiera lub opuszcza pamięć podręczną bfcache, a także w innych sytuacjach, na przykład gdy karta w tle się zawiesza, aby zminimalizować wykorzystanie procesora. Te zdarzenia są obsługiwane tylko w przeglądarkach opartych na Chromium.

Obserwuj, kiedy strona jest przywracana z pamięci podręcznej stanu strony internetowej

Zdarzenie pageshow jest uruchamiane bezpośrednio po zdarzeniu load, gdy strona wczytuje się na początku i za każdym razem, gdy zostanie przywrócona z pamięci podręcznej stanu strony internetowej. Zdarzenie pageshow ma właściwość persisted, która wynosi true, jeśli strona została przywrócona z pamięci podręcznej stanu strony internetowej, lub false w innym przypadku. Możesz użyć właściwości persisted, aby odróżnić zwykłe wczytywanie strony od przywracania bfcache. 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, które obsługują interfejs Page Lifecycle API, zdarzenie resume jest uruchamiane, gdy strony zostaną przywrócone z pamięci podręcznej stanu strony (bezpośrednio przed zdarzeniem pageshow) i gdy użytkownik ponownie otworzy zablokowaną kartę w tle. Jeśli chcesz zaktualizować stan strony po tym, jak została zablokowana (obejmuje strony w pamięci podręcznej stanu strony internetowej), możesz użyć zdarzenia resume, ale jeśli chcesz zmierzyć współczynnik trafień bfcache w witrynie, musisz użyć zdarzenia pageshow. W niektórych przypadkach może być konieczne użycie obu.

Szczegółowe informacje o sprawdzonych metodach pomiaru pamięci podręcznej żądań znajdziesz w artykule Jak bfcache wpływa na analitykę i pomiary skuteczności.

Obserwuj, gdy strona wchodzi do pamięci podręcznej stanu strony internetowej

Zdarzenie pagehide jest wywoływane przy wyładowywaniu strony lub gdy przeglądarka próbuje umieścić je w pamięci podręcznej stanu strony internetowej.

Zdarzenie pagehide ma też właściwość persisted. Jeśli to false, masz pewność, że strona nie wpisze Bfcache. Jednak persisted true nie gwarantuje, że strona zostanie zapisana w pamięci podręcznej. Oznacza to, że przeglądarka zamierza zapisać stronę w pamięci podręcznej, ale mogą istnieć inne czynniki, które uniemożliwią jej zapisanie w pamięci podręcznej.

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 uruchamiane bezpośrednio po zdarzeniu pagehide, jeśli persisted ma wartość true, ale oznacza to tylko, że przeglądarka zamierza zapisać stronę w pamięci podręcznej. Nadal może być konieczne jego odrzucenie z różnych powodów, które przedstawimy później.

Optymalizacja stron pod kątem pamięci podręcznej stanu strony internetowej

Nie wszystkie strony są zapisywane w pamięci podręcznej stanu strony internetowej. Nawet jeśli taka strona zostanie tam zapisana, nie pozostanie tam bez końca. Deweloperzy muszą wiedzieć, co sprawia, że strony kwalifikują się (i nie kwalifikują się) do zapisywania w pamięci podręcznej stanu strony internetowej, aby zmaksymalizować współczynnik trafień w pamięci podręcznej.

W sekcjach poniżej opisujemy sprawdzone metody, które pozwalają maksymalnie zwiększyć prawdopodobieństwo, że przeglądarka może zapisać Twoje strony w pamięci podręcznej.

Nigdy nie używaj zdarzenia unload

Najważniejszym sposobem optymalizacji pod kątem bfcache we wszystkich przeglądarkach jest nieużywanie zdarzenia unload. Nigdy!

Zdarzenie unload stanowi problem dla przeglądarek, ponieważ wyprzedziło bfcache, a wiele stron w internecie działa przy założeniu, że po wywołaniu zdarzenia unload strona przestanie istnieć. Stanowi to wyzwanie, ponieważ wiele z nich zostało również utworzonych z założeniem, że zdarzenie unload będzie uruchamiane za każdym razem, gdy użytkownik opuści stronę, co już nie jest prawdą (i nie było stosowane od dłuższego czasu).

Przeglądarki stoją przed dylematem, dlatego muszą wybrać coś, co zwiększy wygodę użytkowników, ale może też spowodować uszkodzenie strony.

Przeglądarki Chrome i Firefox na komputerach zdecydowały, aby strony nie mogły korzystać z pamięci podręcznej stanu strony internetowej, jeśli dodały detektor unload. Jest to mniej ryzykowne, ale także dyskwalifikuje wiele stron. Safari spróbuje zapisać w pamięci podręcznej niektóre strony z detektorem zdarzeń unload, ale aby ograniczyć potencjalne awarie, nie uruchomi zdarzenia unload, gdy użytkownik opuści stronę, co sprawia, że jest ono bardzo zawodne.

Chrome i Safari na urządzeniach mobilnych spróbują zapisać w pamięci podręcznej strony z detektorem zdarzeń unload. Ryzyko awarii jest mniejsze, ponieważ zdarzenie unload zawsze działa bardzo niestabilnie na urządzeniach mobilnych. Firefox traktuje strony, które używają unload, jako niekwalifikujące się do umieszczenia w pamięci podręcznej stanu strony internetowej. Wyjątkiem jest iOS, który wymaga, by wszystkie przeglądarki korzystały z silnika renderowania WebKit, w związku z czym przeglądarka działa tak jak Safari.

Zamiast zdarzenia unload używaj zdarzenia pagehide. Zdarzenie pagehide jest wywoływane we wszystkich przypadkach, w których jest wywoływane zdarzenie unload, i uruchamia się również po umieszczeniu strony w pamięci podręcznej stanu strony internetowej.

Lighthouse ma kontrolę no-unload-listeners, która ostrzega deweloperów, jeśli kod JavaScript na ich stronach (w tym z bibliotek zewnętrznych) dodaje detektor zdarzeń unload.

Ze względu na niezawodność i wpływ na wydajność pamięci podręcznej Chrome (bfcache) zamierza wycofać zdarzenie unload.

Używaj zasady uprawnień, aby uniemożliwić użycie na stronie modułów obsługi wyładowywania

Możesz mieć pewność, że witryny, które nie używają modułów obsługi zdarzeń unload, nie zostaną dodane, korzystając z zasad dotyczących uprawnień Chrome 115.

Permission-Policy: unload()

Zapobiega to także spowalnianiu strony przez inne firmy i rozszerzenia przez dodawanie modułów obsługi wyładowań i sprawi, że witryna nie będzie mogła korzystać z pamięci podręcznej stanu strony internetowej.

Warunkowo dodaj tylko detektory (beforeunload)

Zdarzenie beforeunload nie sprawi, że strony nie będą kwalifikować się do użycia pola bfcache w nowoczesnych przeglądarkach, ale wcześniej tak się stało i nadal jest zawodne. Nie używaj go, chyba że jest to absolutnie konieczne.

W przeciwieństwie do zdarzenia unload jednak istnieją pewne dopuszczalne przypadki użycia: beforeunload Gdy na przykład chcesz ostrzec użytkownika, że: niezapisane zmiany, które utracą, jeśli opuścicie stronę. W tym przypadku jest to zalecamy dodanie beforeunload detektora tylko wtedy, gdy użytkownik ma niezapisane ustawienia zmian, a następnie usunąć je natychmiast po zapisaniu niezapisanych 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);
});

Ogranicz korzystanie z Cache-Control: no-store

Cache-Control: no-store to serwery WWW w nagłówku HTTP, które można ustawiać w odpowiedziach, aby poinformować przeglądarkę, że nie ma zapisywać odpowiedzi w żadnej pamięci podręcznej HTTP. Jest używany w zasobach zawierających poufne informacje o użytkowniku, na przykład na stronach wymagających logowania.

Chociaż element bfcache nie jest pamięcią podręczną HTTP, do tej pory, gdy zasada Cache-Control: no-store została ustawiona w samym zasobie strony (a nie w żadnym zasobie podrzędnym), przeglądarki zdecydowały się nie zapisywać strony w pamięci podręcznej stanu strony internetowej. Pracujemy nad zmianą tego sposobu działania w Chrome w sposób zapewniający ochronę prywatności, ale obecnie żadne strony korzystające z interfejsu Cache-Control: no-store nie mogą korzystać z pamięci podręcznej stanu strony internetowej.

Ponieważ funkcja Cache-Control: no-store ogranicza możliwość korzystania z pamięci podręcznej stanu strony internetowej, powinna być ustawiona tylko na stronach zawierających informacje poufne, na których jakiekolwiek buforowanie nigdy nie jest odpowiednie.

W przypadku stron, które muszą zawsze wyświetlać aktualną treść i nie zawierają informacji poufnych, użyj właściwości Cache-Control: no-cache lub Cache-Control: max-age=0. Te dyrektywy instruują przeglądarkę, aby ponownie zweryfikowała treść przed jej wyświetleniem. Nie mają one wpływu na możliwość wyświetlania treści w pamięci podręcznej stanu strony internetowej.

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

Jest to prawdopodobnie lepsze rozwiązanie dla użytkowników, ponieważ przywrócenie funkcji Bfcache jest natychmiastowe, a ponieważ strony nie pozostają w pamięci podręcznej stanu strony internetowej bardzo długo, mało prawdopodobne jest, że ich zawartość jest nieaktualna. Jeśli jednak Twoje treści zmieniają się z minuty po minucie, możesz pobrać aktualizacje za pomocą zdarzenia pageshow, jak opisano w następnej sekcji.

Zaktualizuj nieaktualne lub wrażliwe dane po przywróceniu pamięci podręcznej stanu strony internetowej

Jeśli witryna zachowuje stan użytkownika, a zwłaszcza poufne informacje o użytkowniku, trzeba je zaktualizować lub wyczyścić po przywróceniu strony z pamięci podręcznej stanu strony internetowej.

Jeśli np. użytkownik otworzy stronę płatności, a potem zaktualizuje koszyk na zakupy, przejście wstecz może ujawnić nieaktualne informacje w przypadku przywrócenia nieaktualnej strony z pamięci podręcznej stanu strony internetowej.

Innym, poważniejszym przykładem jest sytuacja, w której użytkownik wylogowuje się z witryny na komputerze publicznym, a następny klika przycisk Wstecz. Może to potencjalnie ujawnić prywatne dane, które użytkownik uznał za wyczyszczone po wylogowaniu.

Aby uniknąć takich sytuacji, warto zawsze aktualizować 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
  }
});

Idealnie byłoby zaktualizować treść, ale w przypadku niektórych zmian możesz wymusić pełne ponowne załadowanie. Ten kod sprawdza, czy w zdarzeniu pageshow występuje plik cookie związany z konkretną witryną, i ładuje go ponownie, jeśli go nie znajdzie:

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

Ponowne załadowanie strony ma tę zaletę, że pozwala zachować historię (aby umożliwić nawigację do przodu), ale w niektórych przypadkach bardziej odpowiednie może być przekierowanie.

Reklamy i przywracanie pamięci podręcznej stanu strony internetowej

Być może warto unikać użycia pamięci podręcznej stanu strony internetowej (bfcache) do wyświetlania nowego zestawu reklam przy każdej nawigacji wstecz i do przodu. Podobnie jednak, gdy takie działanie wpływa na skuteczność reklam, wątpliwość, czy prowadzi do większego zaangażowania w reklamę. Użytkownicy mogli zauważyć reklamę, którą chcieli wrócić do kliknięcia, ale po ponownym załadowaniu strony, a nie w pamięci podręcznej stanu strony internetowej. Zanim zaczniesz wyciągać wnioski, warto przetestować ten scenariusz – najlepiej w ramach testu A/B.

W przypadku witryn, które chcą odświeżać reklamy przy przywracaniu pamięci podręcznej stanu strony internetowej, odświeżenie tylko reklam w zdarzeniu pageshow, gdy pole event.persisted ma wartość true, jest możliwe bez wpływu na wydajność strony. Skontaktuj się z dostawcą reklam, ale oto jeden przykład, jak to zrobić za pomocą tagu wydawcy Google.

Unikaj plików referencyjnych typu window.opener

W starszych przeglądarkach, jeśli strona została otwarta za pomocą narzędzia window.open() z linku z elementem target=_blank bez określenia rel="noopener", strona otwierająca będzie się odwoływać do obiektu window otwartej strony.

Oprócz zagrożenia dla bezpieczeństwa strony z niepustymwindow.opener odniesieniem nie można bezpiecznie umieścić w pamięci podręcznej stanu strony internetowej, ponieważ mogłoby to spowodować uszkodzenie wszystkich stron próbujących uzyskać do niej dostęp.

Dlatego najlepiej unikać tworzenia plików referencyjnych window.opener. W miarę możliwości służy do tego rel="noopener" (pamiętaj, że jest to teraz ustawienie domyślne we wszystkich nowoczesnych przeglądarkach). Jeśli Twoja witryna wymaga otwarcia okna i kontrolowania go za pomocą window.postMessage() lub bezpośredniego odwołania do obiektu window, ani okno otwarte, ani element otwierający nie kwalifikuje się do parametru Bfcache.

Zamknij otwarte połączenia, zanim użytkownik opuści stronę

Jak wspomnieliśmy, po umieszczeniu strony w pamięci podręcznej stanu strony wszystkie zaplanowane zadania JavaScriptu są wstrzymywane i wznawiane po wyjęciu strony z pamięci podręcznej.

Jeśli te zaplanowane zadania JavaScript uzyskują dostęp tylko do interfejsów API DOM lub innych interfejsów API, które są odizolowane tylko od bieżącej strony, wstrzymanie tych zadań do czasu, gdy strona nie będzie widoczne dla użytkownika, nie spowoduje żadnych problemów.

Jeśli jednak te zadania są połączone z interfejsami API, które są również dostępne z innych stron tego samego źródła (na przykład IndexedDB, Web Locks, WebSockets), może to stanowić problem, ponieważ ich wstrzymanie może uniemożliwić działanie kodu z innych kart.

W efekcie niektóre przeglądarki nie próbują umieszczać strony w pamięci podręcznej stanu strony internetowej w tych sytuacjach:

• strony z otwartym połączeniem IndexedDB.
• Strony z trwającym żądaniem fetch() lub XMLHttpRequest
• strony z otwartym połączeniem WebSocket lub WebRTC,

Jeśli Twoja strona korzysta z któregokolwiek z tych interfejsów API, zdecydowanie zalecamy zamknięcie połączeń i usunięcie lub odłączenie 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.

Następnie, jeśli strona zostanie przywrócona z pamięci podręcznej stanu strony internetowej, możesz ponownie otworzyć te interfejsy API lub połączyć się z nimi podczas zdarzenia pageshow lub resume.

Z przykładu poniżej dowiesz się, jak sprawdzić, czy strony korzystające z IndexedDB są odpowiednie do korzystania z pamięci podręcznej stanu strony internetowej, 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());

Przeprowadź test, aby upewnić się, że strony można buforować

Dzięki Narzędziach deweloperskich w Chrome możesz przetestować, czy Twoje strony są zoptymalizowane pod kątem pamięci podręcznej stanu strony internetowej, a także zidentyfikować problemy, które mogą uniemożliwiać ich stosowanie.

Aby przetestować stronę:

1. Otwórz stronę w Chrome.
2. W Narzędziach deweloperskich kliknij Aplikacja -> Pamięć podręczna stanu strony internetowej.
3. Kliknij przycisk Przeprowadź test. Narzędzia deweloperskie próbują następnie przejść na inną stronę i z powrotem w celu określenia, czy stronę można przywrócić z pamięci podręcznej stanu strony internetowej.

Jeśli test się powiedzie, w panelu pojawi się komunikat „Przywrócono z pamięci podręcznej stanu strony internetowej”.

W przypadku niepowodzenia panel poda przyczynę. Jeśli przyczyną jest coś, co może pomóc deweloperowi, panel oznaczy problem jako Możliwy do działania.

W tym przykładzie użycie detektora zdarzeń unload sprawia, że strona nie kwalifikuje się do korzystania z pamięci podręcznej stanu strony internetowej. Możesz to naprawić, przełączając się z unload na używanie pagehide:

window.addEventListener('pagehide', ...);

window.addEventListener('unload', ...);

W Lighthouse 10.0 dodano też kontrolę bfcache, która przeprowadza podobny test. Więcej informacji znajdziesz w dokumentacji kontroli bfcache.

Jak bfcache wpływa na analitykę i pomiary skuteczności

Jeśli używasz narzędzia analitycznego do pomiaru wizyt w witrynie, możesz zauważyć spadek łącznej liczby raportowanych wyświetleń strony, ponieważ Chrome włącza pamięć podręczną Bfcache dla większej liczby użytkowników.

Prawdopodobnie już zaniżasz liczbę wyświetleń stron w innych przeglądarkach, które stosują bfcache, ponieważ wiele popularnych bibliotek analitycznych nie mierzy przypadków przywrócenia pamięci podręcznej stanu bazy danych jako nowych odsłon.

Aby w liczbie wyświetleń strony uwzględnić przywracania bfcache, ustaw detektory zdarzenia pageshow i sprawdź właściwość persisted.

Poniższy przykład pokazuje, jak to zrobić w Google Analytics. Inne narzędzia analityczne prawdopodobnie stosują podobną logikę:

// Send a pageview when the page is first loaded.
gtag('event', 'page_view');

window.addEventListener('pageshow', (event) => {
  // Send another pageview if the page is restored from bfcache.
  if (event.persisted) {
    gtag('event', 'page_view');
  }
});

Zmierz współczynnik trafień pamięci podręcznej Bfcache

Możesz też sprawdzić, czy została użyta pamięć podręczna, aby zidentyfikować strony, które nie korzystają z pamięci podręcznej stanu strony internetowej. Możesz to zrobić, mierząc typ nawigacji dla wczytania strony:

// Send a navigation_type when the page is first loaded.
gtag('event', 'page_view', {
   'navigation_type': performance.getEntriesByType('navigation')[0].type;
});

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // Send another pageview if the page is restored from bfcache.
    gtag('event', 'page_view', {
      'navigation_type': 'back_forward_cache';
    });
  }
});

Oblicz współczynnik trafień w pamięci podręcznej stanu strony internetowej, korzystając z liczby nawigacji użytkownika back_forward i back_forward_cache.

Warto wiedzieć, że jest kilka sytuacji, które pozostają poza kontrolą właścicieli witryn, w których nawigacja Wstecz/dalej nie będzie korzystać z pamięci podręcznej stanu strony internetowej, w tym:

• gdy użytkownik zamyka przeglądarkę i uruchamia ją ponownie.
• gdy użytkownik duplikuje kartę.
• gdy użytkownik zamyka kartę i otwiera ją ponownie.

W niektórych przeglądarkach oryginalny typ nawigacji może zostać zachowany, więc może wyświetlać się typ back_forward, mimo że nie są to nawigacji Wstecz/Dalej.

Nawet bez tych wykluczeń pole bfcache zostanie po pewnym czasie odrzucone, aby oszczędzać pamięć.

Dlatego właściciele witryn nie powinni oczekiwać 100% współczynnika trafień w pamięci podręcznej stanu strony internetowej w przypadku wszystkich elementów nawigacyjnych strony back_forward. Pomiar ich współczynnika może jednak pomóc w identyfikacji stron, na których sama strona uniemożliwia użycie pamięci podręcznej Bfcache w przypadku znacznej części przechodzenia wstecz i do przodu.

Zespół Chrome dodał interfejs API NotRestoredReasons, aby wyjaśnić, dlaczego strony nie korzystają z pamięci podręcznej stanu strony internetowej. Dzięki temu deweloperzy mogą zwiększyć współczynnik trafień bfcache. Zespół Chrome dodał typy nawigacji do raportu CrUX, co pozwala zobaczyć liczbę nawigacji bfcache, nawet jeśli nie mierzy jej ręcznie.

Pomiar skuteczności

Parametr bfcache może też negatywnie wpływać na dane o wydajności zbierane w polu, a w szczególności na dane mierzące czas wczytywania strony.

Ponieważ nawigacja z pamięci podręcznej stanu strony internetowej (bfcache) przywraca istniejącą stronę zamiast inicjować jej nowe wczytywanie, łączna liczba zebranych załadowań stron zmniejszy się po włączeniu pola bfcache. Ważne jest jednak, że zastępowanie ładowanych stron przez przywracanie bfcache wiąże się prawdopodobnie z najszybszym ładowaniem stron w Twoim zbiorze danych. Dzieje się tak, ponieważ przejście wstecz i do przodu to z definicji powtórna wizyta, a powtórne wczytywanie strony przebiega zwykle szybciej niż wczytywanie strony przez pierwszego użytkownika (ze względu na wspomnianą wcześniej pamięć podręczną HTTP).

W rezultacie strony w zbiorze danych wczytują się szybciej, co prawdopodobnie spowalnia rozpowszechnianie, mimo że użytkownicy prawdopodobnie poprawili wydajność.

Możesz rozwiązać ten problem na kilka sposobów. Pierwszym z nich jest dodanie do wszystkich danych o wczytywaniu strony odpowiedniego typu nawigacji: navigate, reload, back_forward lub prerender. Dzięki temu możesz w dalszym ciągu monitorować skuteczność w tych typach nawigacji, nawet jeśli ogólny rozkład jest ujemny. Zalecamy tę metodę w przypadku wskaźników wczytywania stron, które nie są skupione na użytkownikach, takich jak Czas do pierwszego bajtu (TTFB).

W przypadku danych dotyczących użytkowników, takich jak podstawowe wskaźniki internetowe, lepszym rozwiązaniem jest zgłoszenie wartości, która lepiej odzwierciedla wrażenia użytkownika.

Wpływ na podstawowe wskaźniki internetowe

Podstawowe wskaźniki internetowe mierzą wrażenia użytkowników związane ze stroną internetową w różnych wymiarach (szybkość wczytywania, interaktywność, stabilność wizualna), a ponieważ buforowanie bfcache jest przywracane szybciej niż pełne wczytanie strony, ważne jest, aby odzwierciedlały to dane w Podstawowych wskaźnikach internetowych. Użytkownik nie obchodzi, czy funkcja bfcache została włączona, czy nie, tylko zależy mu na tym, aby nawigacja była szybka!

Narzędzia, które zbierają dane o podstawowych wskaźnikach internetowych i generują raporty na ich temat, takie jak Raport na temat użytkowania Chrome, traktują przywracanie funkcji bfcache jako osobne wizyty na stronie w zbiorze danych. Nie ma też specjalnych interfejsów API do mierzenia wydajności stron internetowych służących do pomiaru tych wskaźników po przywróceniu bufora bfcache, ale można oszacować ich wartości za pomocą istniejących interfejsów API:

• W przypadku największego wyrenderowania treści (LCP) używaj delta między sygnaturą czasową zdarzenia pageshow a sygnaturą czasową kolejnej wyrenderowanej klatki, bo wszystkie elementy w klatce są wyrenderowane w tym samym czasie. W przypadku przywracania bfcache, wartości LCP i FCP są takie same.
• W przypadku parametru Interakcja z następnym wyrenderowaniem (INP) nadal używaj obecnego narzędzia obserwatora wydajności, ale zresetuj bieżącą wartość INP do 0.
• W przypadku zastosowania skumulowanego przesunięcia układu (CLS) zachowaj dotychczasowy obserwator wydajności, ale zresetuj bieżącą wartość CLS do 0.

Więcej informacji o wpływie bfcache na poszczególne dane znajdziesz na stronach z przewodnikami po podstawowych wskaźnikach internetowych. Konkretny przykład implementacji wersji bfcache tych danych znajdziesz w artykule o dodawaniu ich do biblioteki Web Vitals do biblioteki JS przez PR.

Biblioteka JavaScript web- Vitals obsługuje przywracanie pamięci podręcznej stanu strony internetowej w raportowanych danych.

Dodatkowe materiały

• Pamięć podręczna przeglądarki Firefox (bfcache w Firefoksie)
• Pamięć podręczna stron (bfcache w Safari)
• Pamięć podręczna stanu strony internetowej: zachowanie ujawnione w internecie (różnice w pamięci podręcznej stanu strony internetowej w różnych przeglądarkach)
• tester pamięci podręcznej bfcache (przetestuj, jak różne interfejsy API i zdarzenia wpływają na pamięć podręczną stanu strony internetowej w przeglądarkach)
• Zupełnie nowe funkcje w grach: pamięć podręczna stanu strony internetowej i pamięci podręcznej przeglądarki (studium przypadku z magazynu Smashing pokazujące ogromne postępy w zakresie podstawowych wskaźników internetowych przez włączenie bfcache)