Pamięć podręczna stanu strony internetowej

Philip Walton

Barry Pollard

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ń.

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

Zgodność z przeglądarką

Wszystkie popularne przeglądarki zawierają pamięć podręczną Bfcache, w tym Chrome od wersji 96 oraz Firefox i Safari.

Podstawy dotyczące pamięci podręcznej stanu strony internetowej

W przypadku pamięci podręcznej wstecz/w przód (bfcache) zamiast usuwać stronę, gdy użytkownik ją opuszcza, opóźniamy usunięcie i wstrzymujemy wykonywanie kodu JS. Jeśli użytkownik szybko wróci, ponownie wyświetlimy stronę i wznowimy wykonywanie kodu JS. Dzięki temu użytkownik może niemal natychmiast przejść na inną stronę.

Ile razy zdarzyło Ci się odwiedzić witrynę i kliknąć link, aby przejść na inną stronę, a potem zorientować się, że to nie to, czego szukasz, i kliknąć przycisk Wstecz? W takim przypadku pamięć podręczna stanu strony internetowej może znacznie przyspieszyć wczytywanie poprzedniej strony:

Obejrzyj film pokazujący działanie pamięci podręcznej stanu strony internetowej (bfcache), aby dowiedzieć się, jak może ona przyspieszyć nawigację:

W filmie przykład z bfcache jest znacznie szybszy niż przykład bez niego.

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.

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 swoją rolę w przyspieszaniu powtarzających się nawigacji. bfcache to migawka całej strony w pamięci, w tym stosu JavaScriptu, podczas gdy pamięć podręczna HTTP zawiera tylko odpowiedzi na wcześniejsze żądania. Ponieważ bardzo rzadko zdarza się, aby wszystkie żądania wymagane do załadowania strony były realizowane z pamięci podręcznej HTTP, powtarzające się wizyty korzystające z przywracania bfcache są zawsze szybsze niż nawet najlepiej zoptymalizowane nawigacje bez korzystania z bfcache.

Zamrożenie strony w celu jej późniejszego ponownego włączenia wiąże się z pewnymi trudnościami związanymi z zachowaniem kodu w trakcie tworzenia. Jak na przykład obsłużyć wywołania setTimeout(), gdy osiągnięto limit czasu, a strona jest w pamięci podręcznej bfcache?

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 limitów czasu i obietnic, jest to niewielkie ryzyko, ale w innych przypadkach może prowadzić do mylącego 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żna uzyskać dostęp jednocześnie z kilku kart. W związku z tym przeglądarki zazwyczaj nie próbują umieszczać w pamięci podręcznej stron w środku 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 sposoby korzystania z interfejsu API wpływają na to, czy dana strona kwalifikuje się do korzystania z pamięci podręcznej stanu strony internetowej, znajdziesz w artykule Optymalizacja stron pod kątem pamięci podręcznej stanu strony internetowej.

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

Jeśli strona zawiera osadzone elementy iframe, same elementy iframe nie kwalifikują się do korzystania z pamięci podręcznej stanu strony internetowej. Jeśli na przykład przejdziesz do innej strony w ramce iframe, a potem wrócisz, przeglądarka przejdzie „wstecz” w ramce iframe, a nie w ramce głównej. Przejście wstecz w ramce iframe nie spowoduje użycia pamięci podręcznej przeglądarki.

Użycie pamięci podręcznej stanu strony internetowej może być zablokowane w ramce głównej, jeśli osadzony element iframe korzysta z interfejsów API, które blokują tę funkcję. Aby tego uniknąć, możesz ustawić zasady dotyczące uprawnień w ramce głównej lub użyć atrybutów sandbox.

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

Ponieważ bfcache działa z nawigacją zarządzaną przez przeglądarkę, nie działa w przypadku „miękkiej nawigacji” w aplikacji jednostronicowej (SPA). bfcache może jednak pomóc, gdy wracasz do SPA, zamiast ponownie inicjować aplikację od początku.

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

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łówne zdarzenia używane do obserwowania bfcache to zdarzenia przejścia na inną 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 wchodzą do bfcache lub z niego wychodzą, a także w niektórych innych sytuacjach, np. gdy karta w tle jest zamrażana, aby zminimalizować wykorzystanie procesora. Te zdarzenia są obsługiwane tylko w przeglądarkach opartych na Chromium.

Obserwowanie, kiedy strona jest przywracana z bfcache

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 ma wartość true, jeśli strona została przywrócona z pamięci podręcznej stanu strony internetowej, i wartość false w przeciwnym razie. Aby odróżnić zwykłe wczytywanie stron od przywracania z pamięci podręcznej stanu strony internetowej, możesz użyć 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 (natychmiast przed zdarzeniem pageshow) oraz gdy użytkownik ponownie otwiera zamrożoną kartę na drugim planie. Jeśli chcesz zaktualizować stan strony po jej zamrożeniu (co obejmuje strony w pamięci podręcznej bfcache), możesz użyć zdarzenia resume. Jeśli jednak chcesz zmierzyć współczynnik trafień do pamięci podręcznej bfcache w witrynie, musisz użyć zdarzenia pageshow. W niektórych przypadkach może być konieczne użycie obu.

Więcej informacji o sprawdzonych metodach pomiaru w przypadku pamięci podręcznej stanu strony internetowej znajdziesz w artykule Wpływ pamięci podręcznej stanu strony internetowej na pomiary i skuteczność.

Obserwowanie, kiedy strona wchodzi do bfcache

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

Wydarzenie pagehide ma też właściwość persisted. Jeśli to false, masz pewność, że strona nie wpisze Bfcache. persisted bycie true nie gwarantuje jednak, że strona zostanie zapisana w pamięci podręcznej. Oznacza to, że przeglądarka zamierza umieścić stronę w pamięci podręcznej, ale mogą wystąpić inne czynniki, które uniemożliwiają jej umieszczenie 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

Nie wszystkie strony są przechowywane w pamięci podręcznej stanu strony internetowej. Nawet jeśli tak się stanie, nie będą tam przechowywane przez nieograniczony czas. 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 znajdziesz sprawdzone metody, które pozwolą przeglądarce jak najskuteczniej przechowywać 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 jest problematyczne dla przeglądarek, ponieważ jest starsze niż bfcache, a wiele stron w internecie działa na podstawie (uzasadnionego) założenia, ż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ą więc przed dylematem: muszą wybrać coś, co może poprawić komfort użytkownika, 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 jednocześnie dyskwalifikuje wiele stron. Safari będzie próbować zapisywać w pamięci podręcznej niektóre strony za pomocą odbiornika zdarzeń unload, ale aby zmniejszyć ryzyko wystąpienia problemów, nie będzie uruchamiać zdarzenia unload, gdy użytkownik przejdzie na inną stronę. W związku z tym zdarzenie to jest bardzo niepewne.

Na urządzeniach mobilnych Chrome i Safari będą próbować przechowywać w pamięci podręcznej strony z odbiorcą zdarzeń unload, ponieważ ryzyko wystąpienia błędu jest mniejsze ze względu na to, że zdarzenie unload zawsze było bardzo niestabilne 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, który wymaga, aby wszystkie przeglądarki używały silnika renderowania WebKit, i działa więc tak jak Safari.

Zamiast zdarzenia unload użyj zdarzenia pagehide. Zdarzenie pagehide jest wywoływane we wszystkich przypadkach, gdy jest wywoływane zdarzenie unload, a również, gdy strona jest umieszczana w BFCache.

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

Ze względu na niestabilność i wpływ na wydajność bfcache Chrome planuje wycofanie zdarzenia unload.

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

Witryny, które nie używają modułów obsługi zdarzeń unload, mogą zadbać o to, aby nie były one dodawane, korzystając z zasad dotyczących uprawnień.

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.

Dodawaj warunkowo tylko beforeunload słuchaczy

Zdarzenie beforeunload nie spowoduje, że Twoje strony nie będą kwalifikować się do przechowywania w pamięci podręcznej stanu strony internetowej w nowoczesnych przeglądarkach. Wcześniej tak było, ale nadal nie jest to niezawodne rozwiązanie. Unikaj więc używania tej metody, chyba że jest to absolutnie konieczne.

W odróżnieniu od zdarzenia unload zdarzenie beforeunload może być jednak używane w uzasadnionych celach. Gdy na przykład chcesz ostrzegać użytkownika, że ma niezapisane zmiany, utraci on, gdy opuści stronę. W takim przypadku zalecamy dodawanie odbiorców beforeunload tylko wtedy, gdy użytkownik ma niezapisana zmiany, a następnie usuwanie ich 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);
});

Zminimalizuj wykorzystanie 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ż pamięć podręczna stanu strony internetowej nie jest pamięcią podręczną HTTP, w przeszłości, gdy parametr Cache-Control: no-store był ustawiony w samym zasobie strony (w przeciwieństwie do podzasobu), przeglądarki nie przechowywały strony w pamięci podręcznej stanu strony internetowej, więc strony korzystające z parametru Cache-Control: no-store mogły nie kwalifikować się do korzystania z tej pamięci. Pracujemy nad zmianą tego sposobu działania Chrome w sposób zapewniający ochronę prywatności.

Tag Cache-Control: no-store ogranicza możliwość korzystania ze strony z pamięci podręcznej stanu strony internetowej, dlatego należy go ustawiać tylko na stronach zawierających informacje poufne, na których nie powinno się używać żadnego rodzaju pamięci podręcznej.

W przypadku stron, które zawsze muszą wyświetlać aktualne treści (bez informacji poufnych) użyj tagu 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 to, czy strona kwalifikuje się do korzystania z bfcache.

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, ale ponieważ przywrócenie funkcji bfcache odbywa się natychmiast, a strony nie pozostają w pamięci podręcznej stanu strony internetowej bardzo długo, więc mało prawdopodobne jest, że ich zawartość jest nieaktualna. Jeśli jednak Twoje treści zmieniają się z minuty na minutę, możesz pobierać aktualizacje za pomocą zdarzenia pageshow, jak opisano w następnej sekcji.

Aktualizowanie nieaktualnych lub poufnych danych po przywróceniu bfcache

Jeśli Twoja witryna przechowuje stan użytkownika, zwłaszcza poufne informacje o nim, dane te muszą zostać zaktualizowane lub usunięte po przywróceniu strony z pamięci podręcznej bfcache.

Jeśli na przykład użytkownik przejdzie na stronę płatności, a potem zaktualizuje koszyk, powrót do poprzedniej strony może spowodować wyświetlenie nieaktualnych informacji, jeśli z pamięci podręcznej zostanie przywrócona nieaktualna strona.

Innym, bardziej krytycznym przykładem jest sytuacja, gdy użytkownik wyloguje się z witryny na komputerze publicznym, a następny użytkownik klika przycisk Wstecz. Może to spowodować ujawnienie danych prywatnych, które użytkownik uważał za usunięte po wylogowaniu się.

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 jest aktualizować treści na miejscu, ale w przypadku niektórych zmian może być konieczne wymuszenie pełnego ponownego załadowania. Ten kod sprawdza obecność pliku cookie związanego z witryną w zdarzeniu pageshow i ładuje ponownie, jeśli pliku nie ma:

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.

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

Możesz chcieć uniknąć korzystania z pamięci podręcznej stanu strony internetowej (bfcache), aby wyświetlać nowy zestaw reklam przy każdym powrocie do poprzedniej strony. Nie jest jednak jasne, czy takie działanie wpływa na skuteczność reklam i czy prowadzi do zwiększenia zaangażowania w reklamę. Użytkownicy mogli zauważyć reklamę, do której chcieli wrócić, aby ją kliknąć, ale zamiast odświeżyć stronę, wczytali ją ponownie, co uniemożliwiło im to. Zanim zaczniesz formułować założenia, przetestuj ten scenariusz (najlepiej za pomocą testu A/B).

W przypadku witryn, które chcą odświeżać reklamy podczas przywracania bfcache, odświeżanie tylko reklam w przypadku zdarzenia pageshow, gdy event.persisted = true, pozwala na odświeżanie bez wpływu na wydajność strony. Skontaktuj się z dostawcą reklam, ale tutaj znajdziesz przykład, jak to zrobić za pomocą tagu wydawcy Google.

Unikaj odniesień do 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 odwołań window.opener. W tym celu możesz używać rel="noopener" (obecnie jest to 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łania się do obiektu okna, ani otwarte okno, ani okno otwierające nie będą mogły korzystać z bfcache.

Zamknij otwarte połączenia, zanim użytkownik przejdzie do innej strony

Jak już wspomnieliśmy, gdy strona jest przechowywana w pamięci podręcznej bfcache, wstrzymuje wszystkie zaplanowane zadania JavaScript i wznacza je ponownie, gdy strona zostanie usunięta z pamięci podręcznej.

Jeśli te zaplanowane zadania JavaScriptu uzyskują dostęp tylko do interfejsów DOM API lub innych interfejsów API odizolowanych tylko do bieżącej strony, wstrzymanie tych zadań, 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 tym samym pochodzeniu (np. IndexedDB, Web Locks, WebSockets), może to stanowić problem, ponieważ wstrzymanie tych zadań może uniemożliwić uruchomienie kodu na innych kartach.

W efekcie niektóre przeglądarki nie będą próbować umieszczać strony w BFCache w tych scenariuszach:

• strony z otwartym połączeniem IndexedDB;
• strony z uruchomioną funkcją 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. Pozwala to przeglądarce 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());

Testowanie, czy strony można przechowywać w pamięci podręcznej

Narzędzie Chrome DevTools może pomóc Ci przetestować strony, aby sprawdzić, czy są one zoptymalizowane pod kątem bfcache, i zidentyfikować problemy, które mogą uniemożliwić ich zakwalifikowanie.

Aby przetestować stronę:

1. Otwórz stronę w Chrome.
2. W Narzędziach deweloperskich kliknij Aplikacja -> Pamięć podręczna wstecz i wprzód.
3. Kliknij przycisk Uruchom test. Następnie Narzędzia deweloperskie próbują przejść do innej strony i z powrotem, aby ustalić, czy można przywrócić stronę z pamięci podręcznej bfcache.

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 przyczyna jest taka, którą możesz rozwiązać jako deweloper, panel oznacza ją jako Możliwość 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ć, przechodząc z unload na pagehide:

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

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

Lighthouse 10.0 zawiera też audyt bfcache, który przeprowadza podobny test. Więcej informacji znajdziesz w dokumentacji kontroli bfcache.

Jak bfcache wpływa na pomiary analityczne i wydajnoś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ż teraz masz za mało zliczanych wyświetleń stron z innych przeglądarek, które implementują bfcache, ponieważ wiele popularnych bibliotek analitycznych nie mierzy odświeżeń bfcache jako nowych wyświetleń stron.

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

W tym przykładzie pokazujemy, jak to zrobić w Google Analytics. Inne narzędzia analityczne prawdopodobnie używają podobnej logiki:

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

Pomiar współczynnika trafień w 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. Aby to zrobić, zmierz typ nawigacji w przypadku wczytywania stron:

// 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ń bfcache, używając liczby przejść back_forward i back_forward_cache.

Pamiętaj, że istnieje wiele scenariuszy, na które nie mają wpływu właściciele witryn, gdy nawigacja Wstecz/Do przodu nie będzie korzystać z pamięci podręcznej. Do takich sytuacji należą:

• gdy użytkownik zamyka przeglądarkę i uruchamia ją ponownie.
• gdy użytkownik powieli kartę.
• gdy użytkownik zamknie kartę i ponownie ją otworzy.

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ęć.

Właściciele witryn nie powinni więc oczekiwać, że współczynnik trafień w przypadku pamięci podręcznej bfcache będzie wynosił 100% w przypadku wszystkich przejść back_forward. Pomiar tego współczynnika może jednak być przydatny do identyfikowania stron, które same uniemożliwiają korzystanie z pamięci podręcznej stanu strony internetowej w przypadku dużej liczby przekierowań do tyłu i do przodu.

Zespół Chrome dodał interfejs NotRestoredReasons API, aby pomóc deweloperom zrozumieć, dlaczego strony nie korzystają z bfcache. Dzięki temu deweloperzy mogą zwiększyć współczynnik trafień bfcache. Zespół Chrome dodał do CrUX nowe typy nawigacji, dzięki czemu można zobaczyć liczbę nawigacji w pamięci podręcznej bfcache nawet bez samodzielnego pomiaru.

Pomiar skuteczności

bfcache może też negatywnie wpływać na dane dotyczące wydajności zebrane w polu, zwłaszcza na dane dotyczące czasu wczytywania strony.

Ponieważ przejścia z użyciem bfcache przywracają istniejącą stronę, a nie inicjują wczytywania nowej strony, po włączeniu bfcache łączna liczba zarejestrowanych wczytań stron spadnie. Najważniejsze jest jednak to, że wczytywanie stron zastępowane przez przywracanie z pamięci podręcznej bfcache prawdopodobnie należało do najszybszych w Twoim zbiorze danych. Dzieje się tak, ponieważ przejścia do poprzedniej i następnej strony to według definicji ponowne wizyty, a ponowne wczytywanie stron jest zazwyczaj szybsze niż wczytywanie stron przez nowych użytkowników (z powodu zapamiętywania w pamięci podręcznej HTTP, o którym wspominaliśmy wcześniej).

W efekcie w Twoim zbiorze danych będzie mniej przypadków szybkiego wczytania strony, co prawdopodobnie spowoduje wolniejsze odchylenie od normalności – mimo że wydajność dla użytkownika prawdopodobnie się poprawiła.

Ten problem można rozwiązać na kilka sposobów. Jedną z nich jest dodawanie adnotacji do wszystkich danych o wczytywaniu strony z odpowiednim typem nawigacji: navigate, reload, back_forward lub prerender. Dzięki temu możesz nadal sprawdzać skuteczność w przypadku tych typów nawigacji, nawet jeśli ogólna dystrybucja jest ujemna. Zalecamy to podejście w przypadku danych dotyczących wczytywania stron, które nie są związane z użytkownikiem, np. czasu do pierwszego bajtu (TTFB).

W przypadku danych dotyczących użytkowników, takich jak podstawowe wskaźniki internetowe, lepszym rozwiązaniem jest podanie 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. W końcu użytkownik nie musi wiedzieć, czy włączona jest pamięć podręczna stanu strony internetowej, ważne jest tylko, aby nawigacja była szybka.

Narzędzia, które zbierają dane podstawowe wskaźniki internetowe i tworzą na ich podstawie raporty, np. Raport na temat użytkowania Chrome, traktują przywracanie pamięci podręcznej jako osobne wizyty na stronie w swoim 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żyj różnicy między sygnaturą czasową zdarzenia pageshow a sygnaturą czasową następnego wyrenderowanego kadru, ponieważ wszystkie elementy w ramce zostaną 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 tym, jak bfcache wpływa na poszczególne dane, znajdziesz na stronach z poszczególnymi wskazówkami dotyczącymi danych Core Web Vitals. Przykład implementacji wersji bfcache tych danych znajdziesz w pull request dodającym je do biblioteki JS web-vitals.

Biblioteka JavaScript web-vitals obsługuje przywracanie pamięci podręcznej bfcache w raportowanych danych.

Dodatkowe materiały

• Pamięć podręczna w Firefoksie (bfcache w Firefoksie)
• Pamięć podręczna strony (bfcache w Safari)
• Pamięć podręczna stanu wstecz/w przód: zachowanie w przypadku stron internetowych (różnice w przypadku pamięci podręcznej stanu wstecz/w przód w różnych przeglądarkach)
• Tester bfcache (testowanie wpływu różnych interfejsów API i zdarzeń na bfcache w przeglądarkach)
• Performance Game Changer: Browser Back/Forward Cache (przypadek z Smashing Magazine pokazujący znaczne poprawy wskaźników Core Web Vitals dzięki włączeniu pamięci podręcznej stanu strony internetowej)