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 błyskawiczną nawigację do przodu i do tyłu. Znacznie poprawia komfort przeglądania internetu, zwłaszcza u użytkowników korzystających z wolniejszych sieci lub urządzeń.

Na tej stronie opisujemy, jak zoptymalizować strony pod kątem pamięci podręcznej stanu strony internetowej we wszystkich przeglądarkach.

Zgodność z przeglądarką

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

Począwszy od wersji 86, u niewielkiego odsetka użytkowników Chrome włączał pamięć podręczną przeglądarki na potrzeby nawigacji w różnych witrynach na Androidzie. W kolejnych wersjach stopniowo wprowadzamy dodatkową obsługę. Od wersji 96 pamięć podręczna jest włączona dla wszystkich użytkowników Chrome korzystających z komputerów i urządzeń mobilnych.

Podstawowe informacje o pamięci podręcznej stanu strony internetowej

bfcache to działająca w pamięci pamięć podręczna, w której jest przechowywana pełna migawka strony, gdy użytkownik ją opuszcza. Gdy w pamięci znajduje się cała strona, przeglądarka może ją szybko przywrócić, gdy użytkownik zechce ją wrócić, bez konieczności powtarzania wszystkich żądań sieciowych niezbędnych do wczytania strony.

Poniższy film pokazuje, o ile bufor strony pfcache może przyspieszyć nawigację:

Korzystanie z pamięci podręcznej stanu strony internetowej znacznie przyspiesza wczytywanie stron podczas nawigacji wstecz i do przodu.

Dane o korzystaniu z Chrome wskazują, że 1 na 10 nawigacji na komputerze i 1 na 5 na urządzeniach mobilnych korzysta z nawigacji wstecz lub do przodu. Z tego powodu bfcache może pomóc zaoszczędzić dużo czasu i transmisji danych.

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 szybszym przyspieszeniu wielokrotnych nawigacji. Bfcache to zapis całej strony w pamięci, łącznie ze stertą JavaScriptu. Pamięć podręczna HTTP zawiera tylko odpowiedzi na wcześniej wysłane żądania. Bardzo rzadko zdarza się, by żądania wczytania strony były możliwe do wypełnienia z pamięci podręcznej HTTP, więc powtórne wizyty z użyciem przywracania bfcache są zawsze szybsze niż nawet najlepiej zoptymalizowane nawigację bez pamięci podręcznej.

Utworzenie zrzutu strony w pamięci wymaga jednak pewnej złożoności, jeśli chodzi o możliwość zachowania kodu w toku. Na przykład jak obsługujesz wywołania setTimeout(), gdy limit czasu został przekroczony, gdy strona znajduje się w pamięci podręcznej stanu strony internetowej?

Odpowiedź brzmi: przeglądarki wstrzymują wszystkie oczekujące liczniki czasu i nierozstrzygnięte obietnice dotyczące stron w pamięci podręcznej stanu strony internetowej, w tym niemal wszystkich oczekujących zadań w kolejkach zadań JavaScript, oraz wznawiają zadania przetwarzania, gdy strona zostanie przywrócona z pamięci podręcznej stanu strony internetowej.

W niektórych przypadkach, na przykład w przypadku przekroczenia limitu czasu i obietnic, jest to dość niewielkie ryzyko, ale w innych może prowadzić do niejasnego lub nieoczekiwanego działania. Jeśli na przykład przeglądarka wstrzyma zadanie wymagane do wykonania transakcji IndexedDB, może to mieć wpływ na inne otwarte karty w tym samym źródle, ponieważ do tych samych baz danych IndexedDB można uzyskać dostęp jednocześnie przez wiele kart. W efekcie przeglądarki zwykle nie próbują zapisywać stron w pamięci podręcznej w trakcie transakcji IndexedDB ani podczas korzystania z interfejsów API, które mogą wpływać na inne strony.

Więcej informacji o tym, jak użycie interfejsu API wpływa na kwalifikowanie się strony do buforowania treści na potrzeby pamięci podręcznej, znajdziesz w artykule Optymalizacja stron pod kątem buforowania bfcache.

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

Ponieważ bufor bfcache działa w nawigacji zarządzanych przez przeglądarkę, nie działa w przypadku „pozornej nawigacji” w aplikacji jednostronicowej (SPA). Jest on jednak przydatny przy wychodzeniu i powrocie do SPA.

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

Chociaż buforowanie bfcache to optymalizacja wykonywana automatycznie przez przeglądarki, ważne jest, aby deweloperzy wiedzieli, kiedy się to dzieje, aby mogli zoptymalizować strony pod kątem tej funkcji i odpowiednio dostosować wszelkie dane lub pomiary wydajności.

Głównymi zdarzeniami służącymi do obserwowania pamięci podręcznej są zdarzenia przejścia na stronę pageshow i pagehide, które są obsługiwane przez większość przeglądarek.

Nowsze zdarzenia Cykl życia strony (freeze i resume) są też wysyłane, gdy strony otwierają lub opuszczają pamięć podręczną, a także w innych sytuacjach, np. gdy karta w tle zostaje zablokowana, aby zminimalizować wykorzystanie procesora. Te zdarzenia są obsługiwane tylko w przeglądarkach opartych na Chromium.

Obserwuj, kiedy strona zostaje przywrócona z pamięci podręcznej stanu strony internetowej

Zdarzenie pageshow jest uruchamiane zaraz po zdarzeniu load, gdy strona wczytuje się po raz pierwszy i za każdym razem, gdy strona jest przywracana z pamięci podręcznej stanu strony internetowej. Zdarzenie pageshow ma właściwość persisted równą true, jeśli strona została przywrócona z pamięci podręcznej stanu strony internetowej, a w innym przypadku false. Do odróżniania zwykłego wczytywania stron od przywracania pamięci podręcznej (bfcache) możesz używać właściwości persisted. 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 wywoływane, gdy strony są przywracane z pamięci podręcznej stanu strony internetowej (bezpośrednio przed zdarzeniem pageshow) i gdy użytkownik ponownie otworzy zablokowaną kartę w tle. Jeśli chcesz zaktualizować stan strony po jej zablokowaniu (w tym stron w pamięci podręcznej stanu strony internetowej), możesz użyć zdarzenia resume, ale jeśli chcesz mierzyć częstotliwość trafień strony bfcache, musisz użyć zdarzenia pageshow. W niektórych przypadkach konieczne może być użycie obu.

Szczegółowe informacje o sprawdzonych metodach dotyczących pomiarów pamięci podręcznej stanu strony internetowej znajdziesz w artykule Jak bfcache wpływa na statystyki i pomiar skuteczności.

Obserwuj, kiedy 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ć ją w pamięci podręcznej stanu strony internetowej.

Zdarzenie pagehide ma też właściwość persisted. Jeśli jest to false, możesz mieć pewność, że ta strona nie zostanie umieszczona w pamięci podręcznej stanu strony internetowej. Wartość persisted true nie gwarantuje jednak, że strona będzie przechowywana w pamięci podręcznej. Oznacza to, że przeglądarka intends zapisywać stronę w pamięci podręcznej, ale mogą istnieć inne czynniki, które uniemożliwiają jej zapisanie.

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 uruchamia się bezpośrednio po zdarzeniu pagehide, jeśli persisted ma wartość true, ale oznacza to tylko, że przeglądarka intends zapisać stronę w pamięci podręcznej. Z różnych powodów, które wyjaśnimy w dalszej części prezentacji, konieczne może być jej odrzucenie.

Zoptymalizuj strony 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 strona zostanie tam zapisana, nie będzie istnieć bez końca. Na kolejnych stronach opisujemy, co sprawia, że strony mogą korzystać z pamięci podręcznej stanu strony internetowej, oraz przedstawiamy sprawdzone metody maksymalizacji możliwości zapisywania strony w pamięci podręcznej w przeglądarce, aby polepszyć współczynnik odrzuceń.

Używaj pagehide zamiast unload

Najważniejszym sposobem optymalizowania pamięci podręcznej we wszystkich przeglądarkach jest nieużywanie detektorów zdarzeń unload. Zamiast tego nasłuchuj parametru pagehide, ponieważ uruchamia się on zarówno wtedy, gdy strona wchodzi do pamięci podręcznej, jak i przy każdym uruchomieniu unload.

unload to starsza funkcja, która uruchamiała się za każdym razem, gdy użytkownik opuścił stronę. Obecnie tak się nie dzieje, ale wiele stron internetowych wciąż opiera się na założeniu, że przeglądarki używają unload w ten sposób i że po wywołaniu unload niewczytywana strona przestaje istnieć. Może to spowodować uszkodzenie pamięci podręcznej, jeśli przeglądarka spróbuje zapisać niewczytaną stronę w pamięci podręcznej.

Chrome i Firefox na komputerach sprawiają, że strony z detektorami unload nie kwalifikują się do korzystania z pamięci podręcznej stanu strony internetowej. Pozwala to zmniejszyć ryzyko, ale powoduje też, że wiele stron nie jest zapisywanych w pamięci podręcznej i w konsekwencji ładowanie odbywa się znacznie wolniej. Safari próbuje buforować niektóre strony z detektorami zdarzeń unload, ale aby zmniejszyć liczbę potencjalnych problemów, nie uruchamia zdarzenia unload, gdy użytkownik opuści stronę, co powoduje, że detektory unload są niestabilne.

Na urządzeniach mobilnych Chrome i Safari starają się zapisywać strony w pamięci podręcznej z detektorami zdarzeń unload, ponieważ zawodność unload na urządzeniach mobilnych zmniejsza ryzyko awarii. Przeglądarka mobilna Firefox traktuje strony, które używają unload, jako niekwalifikujące się do korzystania z pamięci podręcznej stanu strony internetowej. Nie dotyczy to systemu iOS, w którym wszystkie przeglądarki muszą korzystać z mechanizmu renderowania WebKit, dlatego działają jak Safari.

Aby sprawdzić, czy kod JavaScript na Twoich stronach używa unload, zalecamy skorzystanie z audytu no-unload-listeners w Lighthouse.

Informacje o planowanym wycofaniu przez Chrome parametru unload znajdziesz w artykule Wycofywanie zdarzenia wyładowania.

Aby zapobiec używaniu na stronie modułów obsługi unload, użyj zasad dotyczących uprawnień

Niektóre skrypty i rozszerzenia innych firm mogą dodawać do strony moduły obsługi unload, co spowalnia działanie witryny, ponieważ uniemożliwia jej użycie w pamięci podręcznej stanu strony internetowej. Aby temu zapobiec w Chrome 115 i nowszych wersjach, użyj zasady uprawnień.

Permission-Policy: unload()

Dodaj tylko beforeunload detektorów warunkowo

Zdarzenie beforeunload nie sprawia, że Twoje strony nie kwalifikują się do korzystania z pamięci podręcznej stanu strony internetowej. Jest jednak zawodna, więc zalecamy korzystanie z niej tylko wtedy, gdy jest to absolutnie konieczne.

Przykładowym przypadkiem użycia właściwości beforeunload jest ostrzeżenie użytkownika, że ma niezapisane zmiany, które utraci, jeśli opuści stronę. W takim przypadku zalecamy dodanie detektorów beforeunload tylko wtedy, gdy użytkownik ma niezapisane zmiany, a następnie usunięcie ich natychmiast po zapisaniu niezapisanych zmian, jak w tym kodzie:

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);
});

Minimalizowanie użycia funkcji Cache-Control: no-store

Cache-Control: no-store to nagłówek HTTP, który można ustawić dla odpowiedzi informujących przeglądarkę, by nie zapisywała odpowiedzi w żadnej pamięci podręcznej HTTP. Jest używany w przypadku zasobów zawierających poufne dane użytkownika, np. strony wymagające logowania.

Chociaż bfcache nie jest pamięcią podręczną HTTP, przeglądarki wykluczały wcześniej strony z pamięci podręcznej stanu strony internetowej, gdy w zasobie strony ustawiono Cache-Control: no-store (ale nie w żadnym zasobie podrzędnym). Pracujemy nad zmianą tego działania przy zachowaniu prywatności użytkowników. Domyślnie jednak strony używające Cache-Control: no-store nie kwalifikują się do korzystania z pamięci podręcznej stanu strony internetowej.

Aby zoptymalizować pod kątem pamięci podręcznej stanu strony internetowej, używaj zasady Cache-Control: no-store tylko na stronach zawierających informacje poufne, które nie mogą być przechowywane w pamięci podręcznej.

W przypadku stron, które zawsze wyświetlają aktualne treści, ale nie zawierają informacji poufnych, użyj właściwości Cache-Control: no-cache lub Cache-Control: max-age=0. Informują one przeglądarkę o ponownej weryfikacji treści przed jej wyświetleniem. Nie wpływają one na zgodność strony z pamięci podręcznej stanu strony internetowej, ponieważ przywracanie strony z pamięci podręcznej stanu strony internetowej nie obejmuje pamięci podręcznej HTTP.

Jeśli treści zmieniają się z minutą na minutę, pobierz aktualizacje za pomocą zdarzenia pageshow, aby aktualizować stronę zgodnie z opisem w następnej sekcji.

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

Jeśli Twoja witryna przechowuje dane o stanie użytkownika, a zwłaszcza jeśli zawierają one poufne dane użytkownika, musisz je zaktualizować lub wyczyścić po przywróceniu strony z pamięci podręcznej stanu strony internetowej.

Jeśli na przykład użytkownik wyloguje się z witryny na komputerze publicznym, a następny użytkownik kliknie przycisk Wstecz, nieaktualne dane z pamięci podręcznej stanu strony internetowej mogą zawierać dane prywatne, które zgodnie z oczekiwaniami pierwszego użytkownika zostały 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
  }
});

W przypadku niektórych zmian możesz wymusić ponowne załadowanie do końca, by zachować historię nawigacji. Ten kod sprawdza, czy w zdarzeniu pageshow występuje plik cookie z konkretnej witryny, i wczytuje go ponownie w przypadku nieznalezienia pliku cookie:

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

Przywracanie reklam i pamięci podręcznej stanu strony internetowej

Rezygnacja z pamięci podręcznej stanu strony internetowej może być kusząca, aby wyświetlać na stronie nowy zestaw reklam przy każdej nawigacji wstecz i do przodu. Niekorzystnie wpływa to jednak na skuteczność witryny i nie powoduje stałego zwiększenia zaangażowania użytkowników w reklamę. Użytkownik może np. chcieć wrócić na stronę, by kliknąć reklamę, ale jeśli strona zostanie ponownie wczytana, a nie z pamięci podręcznej stanu strony internetowej, może wyświetlić się inna reklama. Aby określić najlepszą strategię dla Twojej strony, zalecamy przeprowadzanie testów A/B.

W przypadku witryn, które chcą odświeżać reklamy przy przywracaniu pamięci podręcznej, możesz odświeżyć tylko reklamy w zdarzeniu pageshow, gdy event.persisted ma wartość true, bez wpływu na wydajność strony, jak widać w przykładzie tagu publikowania Google. Aby uzyskać więcej informacji o sprawdzonych metodach dotyczących Twojej witryny, skontaktuj się ze swoim dostawcą reklam.

Unikaj odwołań do kategorii window.opener

W starszych przeglądarkach, jeśli strona została otwarta za pomocą window.open() z linku zawierającego target=_blank bez parametru rel="noopener", strona otwierająca będzie zawierać odwołanie do obiektu window otwartej strony.

Strony z odwołaniem o wartości niezerowej window.opener nie tylko stanowi zagrożenie dla bezpieczeństwa, lecz także nie da się bezpiecznie umieścić w pamięci podręcznej stanu strony internetowej, ponieważ może ona uszkodzić strony, które próbują uzyskać do niej dostęp.

Aby uniknąć tego ryzyka, użyj funkcji rel="noopener", która uniemożliwi utworzenie window.opener plików referencyjnych. Jest to domyślne działanie we wszystkich nowoczesnych przeglądarkach. Jeśli Twoja witryna musi otworzyć okno i kontrolować je za pomocą window.postMessage() lub przez bezpośrednie odwoływanie się do obiektu window, ani otwarte okno, ani otwierające nie kwalifikują się do korzystania z pamięci podręcznej stanu strony internetowej.

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

Jak już wspomnieliśmy, gdy strona zostanie umieszczona w pamięci podręcznej stanu strony internetowej, wstrzymuje ono wszystkie zaplanowane zadania JavaScriptu i wznawia je po wyjęciu strony z pamięci podręcznej.

Jeśli te zaplanowane zadania JavaScript mają dostęp tylko do interfejsów DOM API lub innych interfejsów API odizolowanych od bieżącej strony, wstrzymanie tych zadań w czasie, gdy strona nie jest widoczna dla użytkownika, nie spowoduje problemów.

Jeśli jednak te zadania są połączone z interfejsami API, które są też dostępne z innych stron w tym samym źródle (np. IndexedDB, Web Locks i WebSockets), wstrzymanie ich może spowodować uszkodzenie tych stron, uniemożliwiając uruchomienie kodu na tych stronach.

Dzięki temu niektóre przeglądarki nie będą próbowały umieścić strony w pamięci podręcznej stanu strony internetowej, jeśli ma ona jeden z tych elementów:

Jeśli Twoja strona korzysta z któregokolwiek z tych interfejsów API, zdecydowanie zalecamy zamknięcie połączeń oraz usunięcie lub rozłączenie obserwatorów podczas zdarzenia pagehide lub freeze. Dzięki temu przeglądarka może bezpiecznie zapisywać stronę w pamięci podręcznej, nie ryzykując 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 ponownie się z nimi połączyć podczas zdarzenia pageshow lub resume.

Z przykładu poniżej dowiesz się, jak sprawdzić, czy strony korzystające z IndexedDB kwalifikują się do korzystania z pamięci podręcznej stanu strony internetowej przez zamknięcie otwartego połączenia 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 mogą być zapisywane w pamięci podręcznej

Narzędzia deweloperskie w Chrome pomogą Ci przetestować strony pod kątem optymalizacji pod kątem pamięci podręcznej (Bfcache) oraz zidentyfikować ewentualne 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 stanu strony internetowej.
  3. Kliknij przycisk Uruchom test. Następnie spróbują wyjść i z powrotem sprawdzić, czy stronę można przywrócić z pamięci podręcznej stanu strony internetowej.
Panel pamięci podręcznej stanu strony internetowej w Narzędziach deweloperskich
Panel Pamięć podręczna stanu strony internetowej w Narzędziach deweloperskich.

Jeśli test się powiedzie, w panelu pojawi się komunikat „Przywrócono z pamięci podręcznej stanu strony internetowej”. W przypadku niepowodzenia w panelu pojawi się przyczyna. Pełną listę przyczyn znajdziesz w sekcji Lista przyczyn nieprzywrócenia w Chromium.

Jeśli przyczyna jest taka, że możesz zająć się nią jako deweloper, w panelu oznaczy ją jako Praktyczne.

Nie udało się przywrócić strony z pamięci podręcznej stanu strony internetowej w Narzędziach deweloperskich
Nieudany test pamięci podręcznej stanu strony internetowej z praktycznym wynikiem.

Na tym obrazie 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 pagehide:

Tak
window.addEventListener('pagehide', ...);
Nie
window.addEventListener('unload', ...);

W Lighthouse 10.0 dodaliśmy też kontrolę pamięci podręcznej (bfcache), która przeprowadza podobny test. Więcej informacji znajdziesz w dokumentacji kontroli bfcache.

Jak bfcache wpływa na statystyki i pomiar skuteczności

Jeśli używasz narzędzia analitycznego do śledzenia wizyt w swojej witrynie, możesz zauważyć spadek łącznej liczby odsłon rejestrowanych przez Chrome, ponieważ Chrome udostępnia tę pamięć podręczną większej liczbie użytkowników.

Prawdopodobnie zaniżasz liczbę wyświetleń stron z innych przeglądarek, które korzystają z pamięci podręcznej stanu strony internetowej, ponieważ większość popularnych bibliotek analitycznych nie śledzi przypadków przywrócenia strony z pamięci podręcznej stanu strony internetowej jako nowych odsłon.

Aby w liczbie wyświetleń strony uwzględnić przypadki przywrócenia z pamięci podręcznej stanu strony internetowej, ustaw detektory zdarzenia pageshow i sprawdź właściwość persisted.

Poniższy przykład pokazuje, jak to zrobić za pomocą Google Analytics. Inne narzędzia analityczne wykorzystują prawdopodobnie 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');
  }
});

Mierz współczynnik trafień w pamięci podręcznej stanu strony internetowej

Aby zidentyfikować strony, które nie korzystają jeszcze z pamięci podręcznej stanu strony internetowej, zmierz typ nawigacji podczas wczytywania strony w ten sposób:

// 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ń dla pamięci podręcznej (bfcache) na podstawie liczników dla back_forward nawigacji i back_forward_cache nawigacji.

Powody, dla których nawigacja wstecz lub dalej może nie używać pamięci podręcznej stanu strony internetowej, to między innymi:

  • Zamknięcie i ponowne uruchomienie przeglądarki.
  • Duplikowanie karty.
  • Zamykanie i przywracanie karty.

W niektórych przypadkach przeglądarka może zachować pierwotny typ nawigacji i wyświetlić typ back_forward, pomimo że nie jest to nawigacja wstecz ani do przodu. Nawet jeśli typy nawigacji są raportowane prawidłowo, pamięć bfcache jest okresowo odrzucana w celu zaoszczędzenia pamięci.

Z tego powodu właściciele witryn nie mogą oczekiwać, że współczynnik trafień dotyczących pamięci podręcznej będzie równy 100% w przypadku wszystkich elementów nawigacyjnych (back_forward). Jednak zmierzenie ich współczynnika może pomóc w identyfikacji stron, które uniemożliwiają korzystanie z pamięci podręcznej stanu strony internetowej.

Zespół Chrome pracuje nad interfejsem API NotRestoredReasons, aby wskazać powody, dla których strony nie korzystają z pamięci podręcznej stanu strony internetowej. Dzięki temu deweloperzy mogą zwiększyć liczbę trafień związanych z pamięci podręcznej stanu strony internetowej.

Pomiar skuteczności

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

Ponieważ opcje nawigacyjne buforowania bfcache przywracają istniejącą stronę, po włączeniu tej pamięci łączna liczba zebranych wczytań stron zmniejsza się, zamiast rozpoczynać się od nowego wczytywania strony. W związku z tym, że powtórne wczytywanie strony, w tym nawigacja wstecz i w przód, zastępowanie pamięci podręcznej wczytywanych stron prawdopodobnie było jednym z najszybszych ładowania strony w związku z buforowaniem przez HTTP. Włączenie tej funkcji może więc spowodować wolniejsze ładowanie strony w statystykach pomimo poprawy wydajności witryny.

Istnieje kilka sposobów, które pomogą Ci radzić sobie z tym problemem. Pierwszym z nich jest dodanie adnotacji do wszystkich danych wczytywania strony z odpowiednimi typami nawigacji: navigate, reload, back_forward lub prerender. Dzięki temu możesz nadal monitorować wydajność w ramach tych typów nawigacji, nawet jeśli ogólny odchylenia dystrybucji odbiegają od normy. Zalecamy tę metodę w przypadku nieukierunkowanych na użytkownika wskaźników wczytywania strony, takich jak czas do pierwszego bajtu (TTFB).

W przypadku danych nastawionych na użytkownika, np. podstawowych wskaźników internetowych, lepiej jest zgłosić wartość, która dokładniej odzwierciedla wrażenia użytkowników.

Wpływ na podstawowe wskaźniki internetowe

Podstawowe wskaźniki internetowe pozwalają mierzyć wrażenia użytkownika na podstawie różnych wymiarów (szybkość wczytywania, interaktywność, stabilność wizualna). Ważne, aby podstawowe wskaźniki internetowe odzwierciedlały fakt, że u użytkowników pamięć podręczna przywracana jest szybciej niż w przypadku stron domyślnych.

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ą przywrócone pamięć podręczną jako osobne wizyty na stronie w swoim zbiorze danych. I chociaż nie istnieją specjalne interfejsy API do pomiaru wydajności w sieci po przywróceniu danych bfcache, możesz oszacować ich wartości za pomocą istniejących internetowych interfejsów API:

  • W przypadku największego wyrenderowania treści (LCP) użyj delta między sygnaturą czasową zdarzenia pageshow a sygnaturą sygnatury czasowej następnej wyrenderowanej klatki, ponieważ wszystkie elementy w ramce zostaną wyrenderowane w tym samym czasie. W przypadku przywracania pamięci podręcznej (bfcache) LCP i FCP są takie same.
  • W polu Interakcja do następnego wyrenderowania (INP) korzystaj z dotychczasowego obserwatora skuteczności, ale zresetuj bieżącą wartość CLS do 0.
  • W przypadku funkcji skumulowane przesunięcie układu (CLS) nadal używaj istniejącego obserwatora skuteczności, ale zresetuj obecną wartość CLS na 0.

Więcej informacji o tym, jak buforowanie bfcache wpływa na poszczególne wskaźniki, znajdziesz na stronach z poradami dotyczącymi wskaźników Core Web Vitals. Konkretny przykład implementacji wersji bfcache tych wskaźników znajdziesz w artykule o dodawaniu ich do biblioteki JS Web-vitals.

Dodatkowe materiały