Pamięć podręczna wstecz/do przodu (bfcache)

TL;DR — Pamięć podręczna wstecz/do przodu (bfcache) to funkcja przeglądarki, która zamraża całą stronę w pamięci, gdy ją opuszczasz, więc naciśnięcie Wstecz lub Dalej może przywrócić ją natychmiast — bez przeładowania — o ile przeglądarka nie usunęła wcześniej tej zamrożonej strony. To funkcja przeglądarki, a nie czynnik rankingowy Google. Ale ponieważ przywrócona strona ładuje się niemal natychmiast, po cichu poprawia Twoje wskaźniki Core Web Vitals przy nawigacjach Wstecz/Dalej, które faktycznie zostają przywrócone, dlatego audyt wydajności może kazać Ci „naprawić kwalifikowalność bfcache”.

Czym jest bfcache

Kiedy klikniesz przycisk Wstecz w przeglądarce, dzieje się jedna z dwóch rzeczy. Albo przeglądarka odtwarza poprzednią stronę od zera — ponownie pobierając pliki, ponownie uruchamiając JavaScript, ponownie układając całą stronę — albo przywraca stronę natychmiast, dokładnie tak, jak ją zostawiłeś. Ta natychmiastowa wersja to pamięć podręczna wstecz/do przodu, czyli bfcache.

Oto trik: zamiast wyrzucać starą stronę, gdy z niej nawigujesz, przeglądarka zamraża całą stronę w pamięci — wszystko, łącznie z działającym JavaScriptem — i trzyma ją w lodzie. Jeśli wrócisz wkrótce i przeglądarka nadal ma tę zamrożoną stronę dostępną, rozmraża ją i pokazuje Ci dokładnie tę samą stronę ponownie — bez żądań sieciowych, bez czekania. To możliwe przywrócenie, a nie gwarancja: przeglądarka może usunąć zamrożoną stronę z pamięci, zanim naciśniesz Wstecz (niska pamięć, limit czasu, pewna aktywność), w takim przypadku po prostu dostajesz normalne przeładowanie.

Własny opis Google w jednym zdaniu mówi to wprost: bfcache to “a browser optimization that enables instant back and forward navigation.” (tłumaczenie) „optymalizacja przeglądarki, która umożliwia natychmiastową nawigację wstecz i do przodu”.

Dlaczego to nie jest „pamięć podręczna”, którą już znasz

To jest część, którą ludzie mylą. Kiedy słyszysz „pamięć podręczna”, prawdopodobnie myślisz o pamięci podręcznej przeglądarki lub pamięci podręcznej HTTP — plikach (obrazy, skrypty, arkusze stylów), które Twoja przeglądarka zapisuje, aby nie pobierać ich ponownie. Bfcache to nie to. Te pamięci podręczne przechowują pliki; bfcache przechowuje całą żywą stronę, stan JavaScriptu i wszystko, jako migawkę. Dokumentacja Chrome mówi to wprost: bfcache “differs from browser cache and HTTP cache.” (tłumaczenie) „różni się od pamięci podręcznej przeglądarki i pamięci podręcznej HTTP”.

To także nie dwie inne rzeczy, które ludzie czasem z tym mylą: pamięć podręczna zasobów w pamięci przeglądarki (skompilowane skrypty i zdekodowane obrazy, które przechowuje na czas bieżącej sesji) oraz Cache Storage service workera (pary żądań/odpowiedzi, które strona jawnie zarządza za pomocą caches.open()). Obie te rzeczy mogą być aktywne na tej samej stronie co bfcache — to po prostu osobne mechanizmy, a nie sam bfcache.

To także nie stara funkcja „zapisanej strony” lub „zapisanej migawki”, którą Google i Bing oferowały w wynikach wyszukiwania (mała lista rozwijana, która pokazywała Ci wersję strony, którą mieli w plikach). To była funkcja wyszukiwania i została wycofana. Bfcache to aktywna funkcja przeglądarki, która nie ma nic wspólnego z wynikami wyszukiwania.

Czy bfcache pomaga mojemu SEO?

Nie bezpośrednio. Bfcache nie jest czynnikiem rankingowym Google — własna dokumentacja Google dotycząca rankingu Core Web Vitals nigdy o tym nie wspomina. To, co robi, to sprawia, że Twoje nawigacje Wstecz/Dalej ładują się niemal natychmiast dla odwiedzających, którzy faktycznie otrzymują przywrócenie, a przeglądarki mierzą to jako doskonałe „ładowanie strony”. Więc jeśli wielu Twoich odwiedzających klika Wstecz i Dalej (zakupy, przeglądanie wyników wyszukiwania, czytanie artykułów jeden po drugim), bfcache może poprawić ogólne liczby terenowe Core Web Vitals Twojej witryny — co jest jedną z wielu rzeczy, które Google mówi, że są zgodne z tym, co nagradzają jego systemy rankingowe. Dwa kroki od „bfcache zwiększa rankingi” i to nie gwarantuje Twojego wskaźnika przywracania, ogólnej oceny Core Web Vitals ani Twoich rankingów — ale to realne i mierzalne.

Chcesz pełny obraz — dokładnie to, co blokuje bfcache, jak to przetestować i precyzyjny (nieprzereklamowany) związek z Core Web Vitals? Przełącz się na zakładkę Zaawansowane.

TL;DR — Bfcache to migawka całej strony przechowywana w pamięci (DOM + sterta JS + bieżący stan), a nie ponownie pobieralna odpowiedź HTTP, pamięciowa pamięć podręczna przeglądarki lub Cache Storage serwera service worker — to najważniejsze rozróżnienie koncepcyjne, które należy zrozumieć. Podczas nawigacji wstecz przeglądarka wstrzymuje JS i zamraża stronę; przy przycisku Wstecz/Dalej, jeśli ta zamrożona migawka jest nadal dostępna, rozmraża ją i natychmiast wyświetla ponownie bez żadnych żądań sieciowych — ale usunięcie z pamięci jest zawsze możliwe, więc traktuj przywrócenie jako prawdopodobne, a nie gwarantowane. To nie jest udokumentowany czynnik rankingowy Google Search (dokumentacja Search Central dotycząca Core Web Vitals nigdy go nie wspomina); jego znaczenie jest pośrednie i ograniczone, poprzez pomiar CWV w terenie (głównie LCP i CLS) w nawigacjach, które faktycznie zostają przywrócone — nie gwarantuje to Twojego wskaźnika przywracania, ogólnej oceny CWV, pozycji w wynikach wyszukiwania ani konwersji. Największą przeszkodą w kwalifikowalności jest procedura obsługi unload (~18 punktów procentowych wskaźnika trafień w Chrome); historycznie największą była Cache-Control: no-store (blokująca ~17% nawigacji mobilnych / ~7% nawigacji historii na komputerze), chociaż Chrome pozwala teraz na bfcache dla wielu stron no-store warunkowo (usuwane przy zmianie uwierzytelnienia/ciasteczek, nadal blokowane przez te same API otwartych połączeń) po swoim wdrożeniu w 2025 r. Otwarte połączenia, timery i obserwatory powinny być zamykane/wstrzymywane przy pagehide/freeze i ponownie ustanawiane przy pageshow/resume; window.opener, polityki uprawnień i ramki mogą również blokować — sprawdź powód per-ramka w DevTools lub notRestoredReasons, zamiast zakładać. Przetestuj jednorazowo w Chrome DevTools; diagnozuj w terenie za pomocą API notRestoredReasons dostępnego tylko w Chrome (wynik null nie jest dowodem przywrócenia, a tekst powodu nie jest stabilny). Każda przeglądarka ma własne zasady kwalifikowalności, a miękkie nawigacje w SPA nie otrzymują takiego samego traktowania.

Czym naprawdę jest bfcache (kręgosłup dokładności)

Najważniejsza rzecz do zrozumienia: bfcache to migawka całej strony przechowywana w pamięci, a nie buforowana odpowiedź HTTP. Gdy nawigujesz wstecz ze strony, zamiast ją niszczyć, przeglądarka wstrzymuje wykonywanie JavaScript i zamraża całą stronę — DOM, stertę JS, aktywne timery, wszystko — i trzyma ją w pamięci. Jeśli naciśniesz Wstecz lub Dalej, gdy ta zamrożona migawka jest nadal dostępna, przeglądarka ją rozmraża i ponownie wyświetla dokładnie tę stronę, którą opuściłeś, z zerową liczbą żądań sieciowych i zerowym ponownym renderowaniem. To możliwe przywrócenie, a nie gwarancja — przeglądarka może usunąć migawkę przed powrotem (presja pamięci, limit czasu, pewne zdarzenia) lub specyficzna dla przeglądarki reguła może wymusić świeże ładowanie, w którym to przypadku jest to po prostu zwykła nawigacja w historii. Kanoniczne ujęcie Google jest takie, że bfcache to “a browser optimization that enables instant back and forward navigation.” (tłumaczenie) „optymalizacja przeglądarki, która umożliwia natychmiastową nawigację wstecz i do przodu”.

Dlatego mylenie go z pamięcią podręczną HTTP/przeglądarki to powtarzający się błąd konkurencji. Pamięć podręczna HTTP przechowuje odpowiedzi na poprzednie żądania — pliki, które może ponownie serwować. Bfcache przechowuje żywą, działającą stronę. Dokumentacja Chrome DevTools wyraźnie to rozgranicza: bfcache “differs from browser cache and HTTP cache.” (tłumaczenie) „różni się od pamięci podręcznej przeglądarki i pamięci podręcznej HTTP”. Nie “włączasz” bfcache nagłówkami buforowania tak, jak konfigurujesz buforowanie HTTP — jedyne miejsce, w którym nagłówki wchodzą w grę, to to, że Cache-Control: no-store dyskwalifikowało stronę (więcej o tym poniżej).

To samo rozróżnienie dotyczy dwóch innych pamięci podręcznych, które ludzie czasami mylą z bfcache: pamięciowej pamięci podręcznej zasobów przeglądarki (skompilowane skrypty i zdekodowane obrazy przechowywane na bieżącą sesję) oraz Cache Storage serwera service worker (jawne pary żądanie/odpowiedź, które witryna zarządza sama przez caches.open()). Obie mogą być aktywne na tej samej stronie w tym samym czasie co bfcache — żadna z nich nie jest bfcache, które jest konkretnie zamrożoną instancją strony, a nie buforowanymi zasobami ani przechwyconymi odpowiedziami.

Jeszcze jedno rozróżnienie warto podać, bo wciąż powoduje zamieszanie: bfcache nie ma nic wspólnego ze starą funkcją „cached page” w wyszukiwarce, którą Google (i Bing) kiedyś pokazywały w wynikach. To był zapisany zrzut strony w indeksie wyszukiwarki i został wycofany. Bfcache to funkcja po stronie klienta, w silniku renderującym.

Jak częste są nawigacje wstecz/do przodu?

To nie jest niszowy przypadek brzegowy. Według web.dev, “1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward.” (tłumaczenie) „1 na 10 nawigacji na desktopie i 1 na 5 na mobile to nawigacje wstecz lub do przodu”. Na każdej stronie z powtarzającymi się przepływami wstecz/do przodu — e-commerce kategoria-produkt-i-z powrotem, wyniki wyszukiwania, paginowane treści, czytanie artykuł-po-artykule — to duża część realnych nawigacji, które możesz uczynić niemal natychmiastowymi.

Wsparcie przeglądarek

“All major browsers include a bfcache, including Chrome since version 96, Firefox and Safari.” (tłumaczenie) „Wszystkie główne przeglądarki mają bfcache, w tym Chrome od wersji 96, Firefox i Safari”. Firefox i Safari mają własne, dłużej działające implementacje bfcache; wszystkie przeglądarki oparte na Chromium (Edge, Brave, Opera, Arc) dziedziczą rozwiązanie Chrome. Dokumentacja polityki Microsoft Edge opisuje tę samą funkcję: gdy opuszczasz stronę, jej bieżący stan (drzewo dokumentu, skrypty itd.) może zostać zachowany w pamięci podręcznej wstecz/do przodu, a jeśli przeglądarka wróci do strony, może ją z niej przywrócić i wyświetlić w stanie sprzed zapisania. Jest domyślnie włączona w Edge; jedynym wyłącznikiem jest polityka firmowa kontrolowana przez administratora IT, a nie właściciela strony.

Ważne zastrzeżenie: bfcache każdej przeglądarki stosuje własne zasady kwalifikowalności. Strona, która przechodzi test „Test back/forward cache” w Chrome DevTools, nie jest gwarantowana jako kwalifikowalna w Firefox lub Safari. Traktuj pozytywny wynik w Chrome jako warunek konieczny, ale nie wystarczający.

Co blokuje kwalifikowalność bfcache

Zdarzenie unload — największy pojedynczy bloker

Jeśli zapamiętasz jedną rzecz z tego artykułu: przestań używać zdarzenia unload. web.dev podkreśla to z rzadkim naciskiem jak na dokument Google: “Never use the unload event. Ever!” (tłumaczenie) „Nigdy nie używaj zdarzenia unload. Nigdy!” W Chrome obsługa unload kosztuje około 18 punktów procentowych spadku współczynnika trafień bfcache — to zdecydowanie największy samookaleczający dyskwalifikator.

Są dwa powody, dla których Chrome aktywnie wycofuje to zdarzenie. Po pierwsze, to największy bloker bfcache. Po drugie, unload jest z natury bardzo zawodne: na mobile często w ogóle nie odpala, bo karty są zamykane w tle i zabijane, a przeglądarka priorytetyzuje bfcache nad odpalaniem unload. Więc zdarzenie, na którym polegasz przy „sprzątaniu”, często nigdy nie działa i blokuje realną poprawę wydajności.

Rozwiązania:

• Zastąp unload zdarzeniem pagehide. Zdarzenie pagehide odpala w każdym przypadku, w którym odpala unload, plus gdy strona trafia do bfcache — więc to czyste ulepszenie. Użyj visibilitychange do niezawodnego sprzątania przy „użytkownik opuszcza stronę”.
• Wykrywaj przywrócenie z bfcache za pomocą pageshow. Nasłuchuj pageshow i sprawdzaj event.persisted — jeśli jest true, strona została przywrócona z bfcache, co jest sygnałem do odświeżenia nieaktualnych danych lub ponownego zliczenia odsłony.
• Proaktywnie blokuj nasłuchiwacze unload nagłówkiem odpowiedzi Permissions-Policy: unload=(), który zapobiega rejestrowaniu jakichkolwiek obsług unload. Chrome stopniowo migruje domyślną politykę w kierunku odmowy (a Permissions-Policy dla unload pojawiła się w Chrome 115).

Cache-Control: no-store — historycznie największy, teraz bardziej zniuansowany

To jest punkt o świeżości, który większość konkurencyjnych treści podaje błędnie. Historycznie, Cache-Control: no-store był najczęstszą pojedynczą przyczyną wykluczania stron z bfcache — dane Chrome szacują to na około 17% nawigacji historycznych na mobile i 7% na desktopie. Wiele stron ustawia no-store defensywnie, aby uniknąć dostarczania nieaktualnej strony, ale argument Google jest taki, że to uzasadnienie słabnie przy bfcache: przywrócenie z bfcache nie polega na ładowaniu nieaktualnej odpowiedzi z pamięci podręcznej, lecz na ponownym wyświetleniu dokładnie tej samej żywej strony, prawie tak, jakby karta pozostała otwarta.

Tak więc Chrome zmienił zachowanie — ale warunkowo, nie uniwersalnie. Eksperymenty zaczęły się w Chrome 116, a ostateczne wdrożenie dla 100 % użytkowników nastąpiło w marcu i kwietniu 2025 r.: Chrome umożliwia teraz bfcache dla wielu stron z no-store, pod warunkiem spełnienia określonych warunków bezpieczeństwa, a nie całkowitego wyjątku. Według dokumentacji Chrome wiąże się to z realnymi ograniczeniami — strona jest usuwana z bfcache, jeśli zmieni się stan autoryzacji lub pliki cookie w czasie jej zamrożenia (więc wylogowany gość lub ten z wyczyszczonymi plikami cookie nie zobaczy nieaktualnego zrzutu zalogowanej strony), a stała lista interfejsów API — te same interfejsy otwartych połączeń omówione poniżej (IndexedDB, WebSocket, WebRTC i pozostałe) — nadal wykluczają stronę z no-store z bfcache w taki sam sposób, jak każdą inną stronę. To zachowanie specyficzne dla Chrome w określonym zakresie wersji, a nie reguła, którą można zakładać, że inne przeglądarki lub starsze wersje Chrome będą stosować — pobierz aktualny raport DevTools/notRestoredReasons dla przeglądarki i wersji, którą faktycznie testujesz, zamiast ufać stałej regule kciuka. Praktyczny wniosek: każdy przewodnik (w tym starsze wersje tego), który wymienia no-store jako bezwarunkowy, trwały bloker bfcache, jest nieaktualny — a także traktowanie go jako w pełni rozwiązanego problemu. Jeśli świeżość treści ma naprawdę znaczenie dla strony, dokumentacja Chrome sugeruje no-cache lub krótki max-age (np. max-age=60) zamiast no-store.

Otwarte połączenia, obserwatory i inne blokery

W momencie nawigacji niektóre otwarte zasoby mogą nadal blokować kwalifikowalność — a dokładnie które i czy blokują całkowicie, czy tylko są zamykane-i-ponownie-łączone, zależy od przeglądarki i wersji. Traktuj poniższą listę jako przykłady wzorca, a nie stałą, trwałą listę blokerów:

• Trwające żądania fetch() / XMLHttpRequest.
• Otwarte transakcje IndexedDB.
• Otwarte połączenia WebSocket / WebRTC, timery i obserwatory (MutationObserver, IntersectionObserver i podobne). To obszar aktywnie się rozwijający — najnowsze notatki z wydania Microsoft Edge pokazują, że otwarty WebSocket jest teraz zamykany, gdy strona wchodzi do bfcache (zamiast całkowicie blokować buforowanie), z zaleceniem ponownego połączenia za pomocą sprawdzenia event.persisted w zdarzeniu pageshow. To odzwierciedla szerszy trend Chrome w ograniczaniu liczby blokerów, a nie tylko wykluczaniu stron.

Ogólny wzorzec, do którego należy dążyć, zamiast zapamiętywania stałej listy: zamknij lub wstrzymaj otwarte połączenia, timery i obserwatory w obsłudze pagehide/freeze, a następnie przywróć je w obsłudze pageshow/resume, gdy event.persisted ma wartość true. Ten wzorzec przetrwa zmiany w przeglądarce dotyczące tego, które interfejsy API blokują kwalifikowalność całkowicie, a które tylko zawiesza i pozwala na ponowne połączenie.

window.opener, polityki uprawnień i ramki. Odwołanie window.opener, niektóre polityki uprawnień oraz osadzone ramki iframe (tego samego lub innego pochodzenia) mogą również wpływać na kwalifikowalność — to element listy kontrolnej, którą opracowałem w przewodniku Ahrefs po CLS oraz w dokumentacji Chrome. Ale nie zakładaj, która z nich jest faktyczną przyczyną na podstawie ogólnej listy kontrolnej: panel DevTools w Chrome i interfejs API notRestoredReasons raportują powody blokowania dla każdej ramki — osobno dla ramki głównej i każdej ramki iframe — ponieważ ramka faktycznie odpowiedzialna za blokadę nie zawsze jest stroną najwyższego poziomu. Pobierz prawdziwy powód z tego raportu na poziomie ramki dla testowanej przeglądarki, zamiast zgadywać na podstawie ogólnej listy.

Prawidłowa sekwencja zdarzeń/stanów cyklu życia

Pomylenie tego, co każde zdarzenie cyklu życia faktycznie dowodzi, a co jedynie sugeruje, to drugi najczęstszy błąd poprawności tutaj, po błędach kwalifikowalności powyżej:

Praktyczna zasada: traktuj pagehide.persisted jako zamiar, a nie dowód — strona może nadal zostać usunięta, zanim zobaczysz jakiekolwiek przywrócenie. Tylko pageshow.persisted === true jest dowodem, że przywrócenie nastąpiło. Wykonuj sprzątanie bezwarunkowo przy pagehide/freeze (jest tanie i bezpieczne nawet przy zwykłej nawigacji), a prace specyficzne dla przywrócenia wykonuj tylko przy pageshow/resume, z warunkiem na event.persisted, aby nie odświeżać danych ani nie podwajać widoku analitycznego przy zwykłym świeżym załadowaniu.

Jak testować i diagnozować bfcache

Laboratorium / jednorazowo: Chrome DevTools

Otwórz DevTools → Application → Background services → Back/forward cache, a następnie kliknij “Test back/forward cache.” Chrome automatycznie nawiguje do chrome://terms/ i z powrotem, a następnie raportuje sukces lub konkretną listę powodów blokowania. Dobre do sprawdzania jednego URL-a na raz.

Pole / produkcja: API notRestoredReasons

Wcześniej jedynym sposobem sprawdzenia kwalifikowalności był ten ręczny test w DevTools, jeden URL na raz — nie było sposobu, aby zobaczyć, dlaczego nawigacje prawdziwych użytkowników były blokowane. Właściwość notRestoredReasons na PerformanceNavigationTiming (dostępna w Chrome 123+) zamyka tę lukę: raportuje konkretne powody blokowania dla ramki głównej i iframe z tego samego pochodzenia w rzeczywistych danych polowych.

const nav = performance.getEntriesByType('navigation')[0];
console.log(nav.notRestoredReasons);

Kilka rzeczy, które warto zrobić dobrze, gdy z tego korzystasz, prosto z wytycznych API Chrome:

• To tylko Chrome (123+). Firefox i Safari nie udostępniają równoważnego API polowego, więc nadal potrzebujesz ręcznych testów punktowych w tych przeglądarkach, aby poznać wskaźnik przywracania.
• Wynik null jest niejednoznaczny, a nie zielonym światłem. Może oznaczać, że strona została przywrócona, lub że przeglądarka po prostu nie zebrała powodu — dokumentacja Chrome sama mówi, aby nie traktować null jako dowodu udanego przywrócenia.
• Tekst powodu nie jest stabilnym kontraktem. Nie koduj na sztywno dopasowań ciągów do niego; grupuj i analizuj trendy według powodu, ponieważ dokładne sformułowanie może się zmieniać między wersjami Chrome.

Praktycznie: pobieraj notRestoredReasons wraz ze wskaźnikami przywracania pageshow.persisted przed i po wdrożeniu poprawki, porównuj trend, a nie pojedynczy migawkowy pomiar, i łącz to z ręcznym przejściem DevTools/laboratoryjnym w Firefox i Safari dla przeglądarek, do których API nie dociera. To narzędzie, po które warto sięgnąć przy diagnozowaniu bfcache na dużą skalę w RUM/produkcji, zamiast sprawdzania URL-i jeden po drugim — tylko nie traktuj go jako pełnego obrazu.

Bfcache a Core Web Vitals — precyzyjna zależność

Oto niuans, który większość treści konkurencji zaciera, i kąt, który warto mieć na własność.

Jak mierzy się przywrócenie bfcache. Przeglądarki (a zatem i dane terenowe CrUX) liczą nawigację przywróconą z bfcache jako niezwykle szybkie “ładowanie strony” — niemal natychmiastowe LCP i, gdy strona jest zaimplementowana poprawnie (nic nie musi być ponownie układane), praktycznie zero dodatkowego CLS, ponieważ nie ma ponownego renderowania. W porównaniu DebugBear w rzeczywistych warunkach, strona przywrócona z bfcache osiągnęła LCP około 100 ms w porównaniu z ~427 ms dla niebuforowanego ładowania. To dokładnie dlatego bfcache pojawia się jako dźwignia na CLS i LCP w mojej własnej liście kontrolnej Ahrefs CLS, gdzie ująłem to prosto: “Make sure your pages are eligible for bfcache. The back/forward cache keeps pages in the browser cache. It allows for instant loading of a page that was already loaded, meaning no layout shifts will happen.” (tłumaczenie) „Dopilnuj, by strony kwalifikowały się do bfcache. Pamięć wstecz/do przodu przechowuje całe strony w pamięci przeglądarki, więc wcześniej otwarta strona wczytuje się natychmiast i nie powoduje przesunięć układu.”

Dwa zastrzeżenia dotyczące zakresu, które warto sprecyzować, ponieważ to tutaj treści konkurencji mają tendencję do przesadzania. Po pierwsze, dotyczy to tylko nawigacji, które CrUX klasyfikuje jako wstecz/do przodu (jego wymiar navigation-type) — nie mówi to nic o Twoich nawigacjach pierwszego odwiedzenia lub przeładowania, które stanowią większość ruchu na większości stron. Po drugie, przywrócenie poprawiające zmierzone doświadczenie użytkowników, którzy go otrzymują, nie jest tym samym co gwarancja: użytkownik, który został usunięty z bfcache (patrz tabela cyklu życia powyżej) nadal otrzymuje normalne, nieulepszone ładowanie, więc praca nad kwalifikowalnością bfcache przesuwa Twój wskaźnik przywracania wśród nawigacji wstecz/do przodu, a nie stały udział w całym ruchu — i nie gwarantuje Twojego zagregowanego wyniku terenowego Core Web Vitals, Twoich pozycji ani współczynnika konwersji. To realna, mierzalna dźwignia o konkretnym, ograniczonym zakresie, a nie ogólne rozwiązanie problemu wydajności lub SEO.

Czy bfcache jest czynnikiem rankingowym? Nie. To jest obronne, zróżnicowane twierdzenie. Własna dokumentacja Google dotycząca rankingu Core Web Vitals w ogóle nie wspomina o bfcache. Uczciwy łańcuch wpływów jest następujący: kwalifikowalność bfcache → lepsze terenowe wyniki CWV (głównie LCP/CLS) w nawigacjach wstecz/do przodu → Core Web Vitals jest jednym z wielu sygnałów “jakości strony”, które Google mówi, że są zgodne z tym, co już nagradzają jego systemy rankingowe. To znacznie słabsze, bardziej precyzyjne twierdzenie niż “bfcache zwiększa pozycje” — i to jest twierdzenie, które treści konkurencji powinny formułować, ale zwykle nie są w tym ostrożne. Bfcache jest również, słusznie, funkcją silnika renderującego, a nie funkcją robota indeksującego — nie ma to nic wspólnego z tym, jak Googlebot lub Bingbot indeksują Twoje strony, dlatego nie ma “podejścia Binga do bfcache dla SEO” tak jak w przypadku robots.txt lub sitemaps.

SPA i miękkie nawigacje. Bfcache działa na rzeczywistych zdarzeniach nawigacji i historii przeglądarki. Zmiana “miękkiej” trasy po stronie klienta w aplikacji jednostronicowej (zamiana widoku sterowana JS, która nie wyzwala rzeczywistej nawigacji przeglądarki) nie jest zdarzeniem bfcache i nie otrzymuje takiego samego traktowania. Próby niektórych narzędzi RUM, aby przypisać Core Web Vitals do miękkich nawigacji, mogą powodować rozbieżności pomiarowe CrUX-vs-RUM — warto to zaznaczyć, jeśli audytujesz witrynę opartą na frameworku JS.

Jak powszechne są blokery bfcache w praktyce?

HTTP Archive Web Almanac śledzi to i jest to żywy, zmieniający się obszar — a nie ustalona stara wiadomość. W edycji z 2022 roku co najmniej ~22% stron mobilnych było niekwalifikowalnych do bfcache ze względu na same kryteria unload i no-store. Od tego czasu użycie procedur obsługi unload spada we wszystkich poziomach witryn i urządzeń — ale użycie Cache-Control: no-store wzrosło (rozdział z 2025 roku szacuje je na około 23% witryn, w porównaniu z ~21% w 2024 roku, co przypisuje się częściowo większej liczbie uwierzytelnionych/spersonalizowanych doświadczeń i surowszym wymogom zgodności).

Kontrintuicyjne odkrycie, które warto przytoczyć: większe, bardziej ruchliwe serwisy nieproporcjonalnie częściej blokują własny bfcache. Wśród 1000 najpopularniejszych serwisów około 28% stron desktopowych i 20% stron mobilnych nadal używa handlerów unload, podczas gdy w wszystkich serwisach to tylko ~11% desktop / ~10% mobile — często dlatego, że większe serwisy mają więcej starszej analityki i kodu zależnego od unload. Serwisy, które mają najwięcej do stracenia na ruchu wstecz/do przodu, często same sobie przeszkadzają.

Gdzie to się znajduje

Bfcache to jedna z kilku dźwigni wydajności w tym klastrze. Jego korzyści widoczne są w danych terenowych Core Web Vitals — konkretnie w Cumulative Layout Shift i Largest Contentful Paint, ponieważ przywrócona strona wyświetla się natychmiast bez ponownego układu. Różni się to od caching, który przechowuje pliki, a nie migawkę żywej strony, mimo że oba mają wspólny nagłówek Cache-Control jako punkt styku. Nie ma bezpośredniego powiązania z Interaction to Next Paint, więc nie będę go wymuszać.

Podsumowanie AI

Skrócona wersja wersji Advanced:

• Bfcache = migawka całej strony w pamięci (DOM + sterta JS + stan działania), a nie odpowiedź HTTP możliwa do ponownego pobrania, pamięciowa pamięć podręczna zasobów przeglądarki ani Cache Storage service workera. Podczas nawigacji wstecz przeglądarka wstrzymuje JS i zamraża stronę; przy Back/Forward, jeśli ta zamrożona migawka jest nadal dostępna, rozmraża ją i wyświetla ponownie natychmiast, bez żadnych żądań sieciowych — wykluczenie jest zawsze możliwe, więc przywrócenie jest prawdopodobne, a nie gwarantowane. Dokumentacja Chrome: to „różni się od pamięci podręcznej przeglądarki i pamięci podręcznej HTTP”. To również nie jest stara, wycofana funkcja wyszukiwania „cached page”.
• Nie jest czynnikiem rankingowym i ma ograniczony zakres. Własna dokumentacja Google dotycząca rankingów Core Web Vitals nigdy nie wspomina o bfcache. Prawdziwy łańcuch jest pośredni: kwalifikowalność bfcache → lepsze liczby CWV w terenie (głównie LCP/CLS) przy nawigacjach Back/Forward, które zostają przywrócone → CWV to jeden z elementów doświadczenia strony, który Google mówi, że jest zgodny z jego systemami rankingowymi. Nie gwarantuje to wskaźnika przywracania, zagregowanego CWV, rankingów ani konwersji — i dotyczy tylko nawigacji, które CrUX klasyfikuje jako back/forward.
• Skala: „1 na 10 nawigacji na komputerze i 1 na 5 na urządzeniach mobilnych to albo back, albo forward”. Wsparcie: Chrome od v96, plus Firefox i Safari — ale każda przeglądarka ma własne zasady kwalifikowalności.
• Największy bloker: zdarzenie unload („Nigdy nie używaj zdarzenia unload. Nigdy!”) — ~18 punktów procentowych wskaźnika trafień Chrome. Zastąp je pagehide + visibilitychange; wykrywaj przywrócenia za pomocą pageshow / event.persisted; blokuj unload przez Permissions-Policy: unload=().
• Cache-Control: no-store był historycznie największym blokerem (~17% mobilnych / ~7% nawigacji historii na komputerze). Chrome teraz pozwala na bfcache dla wielu stron no-store warunkowo po wdrożeniu z marca–kwietnia 2025 — wykluczanych, jeśli zmienią się auth/cookies, nadal blokowanych przez te same API otwartych połączeń — i tylko w Chrome; starsze przewodniki nazywające no-store absolutnym blokerem są nieaktualne, podobnie jak traktowanie go jako w pełni rozwiązanego.
• Inne blokery: trwające fetch/XHR, timery, obserwatory, otwarty IndexedDB, WebSocket/WebRTC (zamknij/wstrzymaj przy pagehide/freeze, połącz ponownie przy pageshow/resume), window.opener, polityki uprawnień i ramki — wyciągnij powód per-ramka z DevTools/notRestoredReasons zamiast zakładać.
• Poprawność cyklu życia: pagehide.persisted to intencja, nie dowód; tylko pageshow.persisted === true potwierdza przywrócenie. Rób sprzątanie bezwarunkowo przy pagehide/freeze; rób pracę specyficzną dla przywrócenia (odśwież wrażliwe dane, połącz ponownie, policz jeden widok analityki) tylko przy pageshow/resume.
• Testowanie: Chrome DevTools „Test back/forward cache” (jednorazowe laboratorium); API notRestoredReasons tylko w Chrome (Chrome 123+) dla danych terenowych — null nie jest dowodem przywrócenia, tekst powodu nie jest stabilny, a Firefox/Safari wymagają ręcznych kontroli punktowych. Porównaj wskaźniki notRestoredReasons i pageshow.persisted przed i po poprawce.
• SPA: miękkie nawigacje po stronie klienta nie są zdarzeniami bfcache i nie otrzymują takiego samego traktowania (źródło niezgodności CrUX-vs-RUM).
• Adopcja (Web Almanac): użycie no-store rośnie (~21%→23%), użycie unload wyższe na największych stronach (~28% komputerów w top 1 000) — duże strony często blokują własny bfcache.

Oficjalna dokumentacja

Dokumentacja podstawowa na temat bfcache. Zwróć uwagę na podział źródeł: bfcache znajduje się w dokumentacji Chrome / silnika renderującego (instytucjonalny głos Google na ten temat), a nie w Google Search Central — ten podział sam w sobie jest sednem sprawy.

Google / Chrome

• Pamięć podręczna wstecz/do przodu — dokument kanoniczny: definicja, mechanizm, statystyka 1 na 10 / 1 na 5 i zalecenia dotyczące unload.
• Testowanie pamięci podręcznej wstecz/do przodu — kroki testowania w DevTools, główne blokery i wyraźne stwierdzenie “differs from browser cache and HTTP cache” (tłumaczenie) „bfcache różni się od pamięci podręcznej przeglądarki i pamięci podręcznej HTTP”.
• Włączanie bfcache dla Cache-Control: no-store — zmiana polityki z 2025 roku, wartości 17% / 7% i harmonogram wdrożenia.
• Wycofywanie zdarzenia unload — dlaczego unload jest wycofywane i jak przebiega migracja Permissions-Policy.
• API notRestoredReasons pamięci podręcznej wstecz/do przodu — diagnostyka terenowa za pomocą PerformanceNavigationTiming (Chrome 123+).
• Zrozumienie Core Web Vitals i wyników wyszukiwania Google — dokument rankingowy Google Search Central, przywołany tu jako dowód, że nigdy nie wspomina o bfcache.

Microsoft / Edge

• Zasady Microsoft Edge: BackForwardCacheEnabled — definicja Edge, to samo zastrzeżenie dotyczące unload i firmowy przełącznik wyłączający funkcję.

MDN / web standards

• bfcache — glosariusz MDN — ogólna definicja dla twórców stron i rozróżnienie względem pamięci podręcznej HTTP.
• Monitorowanie powodów blokowania bfcache — MDN — praktyczne użycie notRestoredReasons.

Cytaty ze źródła

Oświadczenia na piśmie z dokumentacji źródłowej. Każdy link to link bezpośredni, który przeskakuje do cytowanego fragmentu na stronie źródłowej.

Google / Chrome — czym jest bfcache i dlaczego ma znaczenie

• “Back/forward cache (or bfcache) is a browser optimization that enables instant back and forward navigation.” (tłumaczenie) „Pamięć podręczna wstecz/do przodu (czyli bfcache) to optymalizacja przeglądarki, która umożliwia natychmiastową nawigację wstecz i do przodu.” — web.dev. Przejdź do cytatu
• “1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward. With bfcache enabled, browsers could eliminate the data transfer and time spent loading for billions of web pages every single day!” (tłumaczenie) „Jedna na dziesięć nawigacji na komputerach i jedna na pięć na urządzeniach mobilnych to nawigacja wstecz lub do przodu. Po włączeniu bfcache przeglądarki mogłyby każdego dnia wyeliminować transfer danych i czas ładowania miliardów stron internetowych!” Przejdź do cytatu
• “All major browsers include a bfcache, including Chrome since version 96, Firefox and Safari.” (tłumaczenie) „Wszystkie główne przeglądarki mają bfcache, w tym Chrome od wersji 96, Firefox i Safari.” Przejdź do cytatu

Google / Chrome — zasada optymalizacji nr 1

• “Never use the unload event. Ever!” (tłumaczenie) „Nigdy nie używaj zdarzenia unload. Nigdy!” — web.dev. Przejdź do cytatu

Chrome DevTools — bfcache to nie pamięć podręczna HTTP

• “Back/forward cache differs from browser cache and HTTP cache.” (tłumaczenie) „Pamięć podręczna wstecz/do przodu różni się od pamięci podręcznej przeglądarki i pamięci podręcznej HTTP.” — dokumentacja Chrome DevTools. Przejdź do cytatu

Microsoft Edge — ta sama funkcja, to samo zastrzeżenie

• “When navigating away from a page, its current state (document tree, script, and so on) may be preserved in the back-forward cache. If the browser navigates back to the page, the page may be restored from the back-forward cache and displayed in the state it was in before being cached.” (tłumaczenie) „Po opuszczeniu strony jej bieżący stan (drzewo dokumentu, skrypt itd.) może zostać zachowany w pamięci podręcznej wstecz/do przodu. Gdy przeglądarka wróci do strony, może ona zostać przywrócona z tej pamięci i wyświetlona w stanie sprzed zapisania.” — dokumentacja zasad Microsoft Edge. Przejdź do cytatu

Patrick Stox (ja) — bfcache jako dźwignia CLS

• “Make sure your pages are eligible for bfcache. The back/forward cache keeps pages in the browser cache. It allows for instant loading of a page that was already loaded, meaning no layout shifts will happen.” (tłumaczenie) „Upewnij się, że Twoje strony kwalifikują się do bfcache. Pamięć podręczna wstecz/do przodu przechowuje strony w pamięci podręcznej przeglądarki. Umożliwia natychmiastowe ładowanie strony, która była już załadowana, więc nie wystąpią przesunięcia układu.” — mój przewodnik po CLS w Ahrefs. Przeczytaj

Lista kontrolna kwalifikowalności bfcache

Przegląd, aby potwierdzić, że Twoje strony mogą trafić do pamięci podręcznej wstecz/do przodu:

• Brak nasłuchiwaczy zdarzeń unload gdziekolwiek na stronie (Twoich lub skryptów zewnętrznych). To największy pojedynczy bloker.
• Kod czyszczenia/analityki przeniesiony z unload do pagehide i visibilitychange.
• Nasłuchiwacz pageshow sprawdza event.persisted, aby odświeżyć nieaktualne dane i poprawnie przeliczyć odsłony po przywróceniu z bfcache.
• Rozważ nagłówek odpowiedzi Permissions-Policy: unload=(), aby zablokować rejestrację jakichkolwiek nasłuchiwaczy unload.
• Przejrzyj Cache-Control: no-store — jeśli ustawiasz go defensywnie, potwierdź, czy nadal go potrzebujesz (Chrome 2025+ warunkowo pozwala na bfcache dla wielu stron z no-store — usuwanych przy zmianie uwierzytelnienia/ciasteczek, nadal blokowanych przez te same API otwartych połączeń; nie zakładaj, że inne przeglądarki lub wersje działają tak samo); jeśli świeżość ma znaczenie, preferuj no-cache lub krótki max-age.
• Brak otwartych połączeń, timerów lub obserwatorów pozostawionych w momencie nawigacji — trwające fetch/XHR, otwarte transakcje IndexedDB, WebSocket/WebRTC, MutationObserver/IntersectionObserver (zamknij/wstrzymaj przy pagehide/freeze, przywróć przy pageshow/resume, gdy event.persisted jest prawdziwe).
• Brak referencji window.opener, restrykcyjnych polityk uprawnień lub zablokowanych ramek, które uniemożliwiają kwalifikowalność — sprawdź powód per ramka w DevTools/notRestoredReasons, zamiast zakładać, który ma zastosowanie.
• Test laboratoryjny strony w Chrome DevTools → Application → Back/forward cache → „Test back/forward cache.”
• Diagnostyka terenowa na dużą skalę z notRestoredReasons w Twoim RUM (tylko Chrome; wynik null nie jest dowodem przywrócenia, a tekst powodu nie jest stabilnym kontraktem — trenduj według powodu, nie koduj na sztywno ciągów).
• Nie zakładaj, że przejście w Chrome = kwalifikowalność wszędzie — sprawdź punktowo Firefox i Safari, które stosują własne zasady.

Ściągawka bfcache

Co to blokuje — i naprawa

Zdarzenia, które warto znać

Przetestuj to

Szybkie fakty

• Bfcache = cała żywa strona w pamięci, nie pliki, nie cache zasobów, nie Cache Storage service workera. Chrome: „różni się od cache przeglądarki i cache HTTP.”
• Nie jest czynnikiem rankingowym Google — dokumentacja CWV Search Central nigdy o nim nie wspomina. Przywrócenie poprawia zmierzone LCP/CLS dla użytkowników, którzy je otrzymują; nie gwarantuje wskaźnika przywróceń, zagregowanych CWV, rankingów ani konwersji.
• Wsparcie: Chrome 96+, Firefox, Safari — każde z własnymi zasadami.
• 1 na 10 desktop / 1 na 5 mobile nawigacji to Wstecz/Dalej.

Antywzorce Bfcache (i mity za nimi)

„Bfcache to po prostu mój cache HTTP/przeglądarki — konfiguruję go przez Cache-Control.” Nie. Bfcache to odrębny, całostronicowy snapshot w pamięci; dokumentacja Chrome mówi, że „różni się od cache przeglądarki i cache HTTP.” Nagłówki cache mają znaczenie tylko o tyle, o ile no-store dyskwalifikował stronę. Nie „włączasz bfcache” nagłówkami cache.

„Bfcache to czynnik rankingowy Google, więc jego naprawa poprawia rankingi.” Nie potwierdzone przez żadne oficjalne źródło Google Search. Dokumentacja rankingowa Core Web Vitals nie wspomina o bfcache. Prawdziwa zależność jest pośrednia (lepsze pole LCP/CLS przy nawigacjach Wstecz/Dalej), co jest słabszym, bardziej precyzyjnym twierdzeniem.

„Cache-Control: no-store zawsze blokuje bfcache, na stałe.” Prawda historycznie — i nadal największa historyczna przyczyna — ale nie jest już kategorycznie prawdą po pełnym wdrożeniu w Chrome w 2025 r. bfcache bezpiecznego dla no-store. Przewodniki sprzed tej zmiany są nieaktualne w tym konkretnym punkcie — ale traktowanie tego jako w pełni rozwiązanego też jest błędem: wyjątek Chrome jest warunkowy (usuwany przy zmianach auth/cookie, nadal blokowany przez te same API otwartych połączeń) i specyficzny dla Chrome, a nie uniwersalne zielone światło.

„Strona, która wyzwala pagehide z persisted: true, na pewno została zapisana w cache.” Nie — to intencja, nie dowód. Przeglądarka może nadal usunąć stronę, zanim zobaczysz przywrócenie. Tylko pageshow.persisted === true potwierdza, że przywrócenie faktycznie nastąpiło.

„Jeśli przejdzie test bfcache w Chrome DevTools, jest kwalifikowany wszędzie.” Fałsz. Chrome, Firefox i Safari stosują własne ograniczenia; zaliczenie w jednym nie gwarantuje kwalifikacji w innym.

„unload to dobry sposób na uruchamianie kodu wyjścia/porządkowania, więc go zatrzymam.” Nie — Chrome określa go jako wyjątkowo zawodny (często w ogóle nie odpala na urządzeniach mobilnych) i aktywnie go wycofuje przez Permissions-Policy, właśnie dlatego, że jest największym blokerem bfcache. Użyj pagehide + visibilitychange.

„Bfcache pomaga mojej SPA tak samo jak wielostronicowej witrynie.” Nie bez zastrzeżeń. Bfcache jest powiązany z prawdziwymi nawigacjami przeglądarki; zmiana trasy po stronie klienta („miękka”) nie jest tym samym zdarzeniem i nie otrzymuje takiego samego traktowania — co również powoduje niezgodności CrUX-vs-RUM na stronach opartych na SPA.

„Bfcache to rozwiązany / stary temat, nie warto go audytować.” Przeczą temu dane Web Almanac: użycie no-store rośnie, a użycie unload pozostaje znacznie wyższe na największych, najbardziej ruchliwych stronach — tych, które mają najwięcej do stracenia w ruchu Wstecz/Dalej.

Narzędzia do testowania i diagnozowania bfcache

• Chrome DevTools — panel Back/forward cache. Application → Background services → Back/forward cache → „Test back/forward cache.” Automatycznie nawiguje do chrome://terms/ i z powrotem, a następnie raportuje sukces lub dokładne powody blokowania. Najlepszy do jednorazowej, jednoadresowej kontroli laboratoryjnej.
• API notRestoredReasons (Chrome 123+). Odczytaj performance.getEntriesByType('navigation')[0].notRestoredReasons w swoim RUM, aby zobaczyć powody blokowania prawdziwych użytkowników — w tym dla iframe z tego samego pochodzenia — na dużą skalę, nie tylko w ręcznym teście laboratoryjnym.
• PageSpeed Insights / Lighthouse / CrUX. Tam, gdzie zalecenie lub flaga „back/forward cache” zwykle pojawia się najpierw w audycie, i gdzie widać korzyść w polu CWV dla witryny kwalifikującej się do bfcache.
• Nagłówek Permissions-Policy: unload=(). To nie narzędzie testowe, ale dźwignia egzekwowania: ustaw go, aby aktywnie zapobiec rejestrowaniu jakichkolwiek nasłuchiwaczy unload (w tym zewnętrznych).
• Web Almanac (HTTP Archive) — rozdział o wydajności. Do porównywania, jak powszechne są blokery bfcache w całej sieci według urządzenia i poziomu rankingu witryny.

DevTools mówi, że procedura obsługi unload zablokowała przywrócenie

Objaw: test Back/forward cache wymienia unload. Prawdopodobna przyczyna: kod pierwszej lub osób trzecich zarejestrował nasłuchiwacz unload. Rozwiązanie: zastąp porządkowanie pagehide/visibilitychange, dodaj Permissions-Policy: unload=() tam, gdzie to właściwe, i uruchom ponownie test po każdej zmianie dotkniętego skryptu.

Przywrócona strona pokazuje nieaktualne dane użytkownika

Objaw: Wstecz działa natychmiast, ale stan konta, zapasy lub inna dynamiczna wartość są nieaktualne. Prawdopodobna przyczyna: strona wznowiła zamrożony stan bez odświeżania wrażliwych na czas danych. Rozwiązanie: nasłuchuj pageshow, sprawdź event.persisted i odśwież tylko wymagane dane. Potwierdź, że zarówno zwykłe ładowania, jak i przywrócenia działają.

Analityka gubi lub podwaja widoki Wstecz/Dalej

Objaw: liczba wyświetleń różni się od rzeczywistych nawigacji w historii. Prawdopodobna przyczyna: analityka działa tylko przy pierwotnym ładowaniu lub działa dwa razy bez rozróżnienia przywrócenia. Rozwiązanie: obsłuż pageshow jawnie i użyj event.persisted, aby policzyć przywróconą nawigację raz.

Test laboratoryjny przechodzi, ale przywracanie w polu pozostaje niskie

Objaw: przykładowy URL przechodzi w DevTools, podczas gdy RUM raportuje wiele braków przywróceń. Prawdopodobna przyczyna: inne szablony, przeglądarki, stany prawdziwych użytkowników lub przerywane otwarte połączenia dodają blokery. Rozwiązanie: zbierz notRestoredReasons, pogrupuj według powodu i szablonu, i odtwórz dominujący przypadek z pola, zamiast ekstrapolować z jednego przejścia.

Udowodnij, że poprawka bfcache została wdrożona

Test kwalifikowalności

Test do uruchomienia: DevTools → Application → Back/forward cache → Test back/forward cache. Oczekiwany wynik: strona przywraca się pomyślnie bez żadnego powodu blokującego. Interpretacja niepowodzenia: co najmniej jeden bloker kwalifikowalności pozostaje. Okno monitorowania: natychmiastowe dla Chrome w testowanym stanie. Wyzwalacz wycofania: poprawka psuje czyszczenie, bezpieczeństwo lub wymagane zachowanie aplikacji.

Test zachowania przy przywracaniu

Test do uruchomienia: przejdź dalej i wróć, a następnie sprawdź, czy pageshow otrzymuje event.persisted === true i czy dane wrażliwe na czas są odświeżane. Oczekiwany wynik: jedno natychmiastowe przywrócenie, poprawne dane i jedno zdarzenie analityczne. Interpretacja niepowodzenia: strona albo nie została zapisana w pamięci podręcznej, albo obsługa przywracania jest niekompletna. Okno monitorowania: natychmiastowe dla reprezentatywnych stanów zalogowanych/wylogowanych. Wyzwalacz wycofania: nieaktualne wrażliwe dane lub zduplikowane działania po przywróceniu.

Test przyczyny w terenie

Test do uruchomienia: monitoruj PerformanceNavigationTiming.notRestoredReasons w RUM. Oczekiwany wynik: docelowy bloker maleje dla dotkniętych szablonów bez nowego dominującego blokera zastępującego go. Interpretacja niepowodzenia: próbka laboratoryjna nie odzwierciedlała produkcji lub inna zależność jest właścicielem problemu. Okno monitorowania: wystarczający rzeczywisty ruch wstecz/dalej, aby porównać tę samą mieszankę szablonów. Wyzwalacz wycofania: istotna regresja aplikacji lub integralności danych związana ze zmianą.

Metryki Bfcache, które warto śledzić

Wskaźnik przywracania

Metryka: kwalifikowalne nawigacje wstecz/dalej przywrócone z bfcache. Co ci to mówi: jak często użytkownicy otrzymują korzyść natychmiastowej nawigacji. Jak to pobrać: wpisy nawigacji RUM i pageshow.persisted, segmentowane według przeglądarki i szablonu. Punkt odniesienia / realistyczny zakres: ustal własną bazę, ponieważ zasady przeglądarek, stan strony i mieszanka nawigacji się różnią. Częstotliwość: co tydzień i po zmianach cyklu życia.

Powody braku przywrócenia

Metryka: nawigacje historii pogrupowane według notRestoredReasons. Co ci to mówi: które blokery kosztują najwięcej rzeczywistych przywróceń. Jak to pobrać: API PerformanceNavigationTiming w obsługujących przeglądarkach. Punkt odniesienia / realistyczny zakres: dąż do zera dla blokerów kontrolowanych przez twój własny kod, oznaczając pokrycie przeglądarki/API. Częstotliwość: cotygodniowa triaż.

Poprawność przywróconej nawigacji

Metryka: błędy, incydenty nieaktualnych danych i zduplikowane analityki/działania po przywróceniu. Co ci to mówi: czy wyższa kwalifikowalność zachowuje poprawność aplikacji. Jak to pobrać: zdarzenia błędów RUM, monitorowanie aplikacji i QA analityki kluczowane do pageshow.persisted. Punkt odniesienia / realistyczny zakres: zero znanych awarii poprawności lub prywatności. Częstotliwość: ciągłe alerty i QA wydań.

Zasoby warte twojego czasu

Moje powiązane artykuły

• Czym jest Cumulative Layout Shift (CLS) i jak go poprawić — gdzie wymieniam kwalifikowalność bfcache jako taktykę poprawy CLS, z krótką listą kontrolną blokerów.
• Czym są Core Web Vitals (CWV) i jak je poprawić — metryki nadrzędne, z bfcache jako jedną z wielu dźwigni CLS.
• Przewodnik po technicznym SEO dla początkujących — gdzie wydajność sieci wpisuje się w szerszy obraz.

Moje wystąpienia

• Jak działa wyszukiwarka (SlideShare) — mój przegląd crawlowania, renderowania, indeksowania i rankingu, dla kontekstu, dlaczego funkcja silnika renderującego, taka jak bfcache, znajduje się poza sygnałami rankingowymi wyszukiwarki Google. (Obowiązuje moje stałe zastrzeżenie: “This is my understanding of systems… not going to be 100% complete or accurate.” (tłumaczenie) „To jest moje zrozumienie systemów… nie będzie w 100% kompletne ani dokładne.”)

Oficjalne

• Pamięć podręczna wstecz/do przodu (web.dev) — dokument kanoniczny.
• Włączanie bfcache dla Cache-Control: no-store oraz Wycofywanie zdarzenia unload (Chrome for Developers) — dwie zmiany, które czynią starsze przewodniki nieaktualnymi.
• Zrozumienie Core Web Vitals i wyników wyszukiwania Google (Google Search Central) — dokument o rankingu, który wymownie nigdy nie wspomina o bfcache.

Z branży

• bfcache — glosariusz MDN — dokładna, neutralna względem silników definicja oraz rozróżnienie od pamięci podręcznej HTTP.
• Co pamięć podręczna wstecz/do przodu oznacza dla szybkości witryny? (DebugBear) — najbardziej oparty na danych materiał w tej dziedzinie, z logiem z prawdziwej witryny i konkretnym porównaniem LCP (~100ms z pamięci podręcznej vs ~427ms bez).
• Wyjaśnienie pamięci podręcznej wstecz/do przodu (SpeedVitals) — mechanika, kwalifikowalność, testowanie i wpływ na CWV.
• Pamięć podręczna wstecz/do przodu: czym jest i jak ją wdrożyć (NitroPack) — skoncentrowany na wdrożeniu, dla odbiorców z CMS/hostingu.
• Przełom dla wydajności: pamięć podręczna wstecz/do przodu przeglądarki (Smashing Magazine) — solidne techniczne omówienie, ale uwaga: powstało przed zmianą no-store z 2025 r.
• Web Almanac — rozdział o wydajności (2025) (HTTP Archive) — dane o rzeczywistym przyjęciu unload i no-store według urządzenia i poziomu rankingu witryny.

Statystyki, które warto cytować

• Nawigacje wstecz/wprzód są powszechne: “1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward” (tłumaczenie) „1 na 10 nawigacji na komputerze i 1 na 5 na urządzeniach mobilnych to nawigacja wstecz lub wprzód” — skala możliwości, a nie niszowy przypadek. Źródło
• unload kosztuje ~18 punktów procentowych wskaźnika trafień bfcache w Chrome — dlatego jest głównym blokerem i jest wycofywany. Źródło
• Cache-Control: no-store był największym historycznym blokerem — około 17 % nawigacji historycznych na urządzeniach mobilnych i 7 % na komputerach — zanim wdrożenie Chrome z marca–kwietnia 2025 r. umożliwiło bfcache dla wielu stron z no-store. Źródło
• Przywrócenie bfcache jest niemal natychmiastowe: DebugBear zmierzył LCP około 100ms dla przywróconej strony w porównaniu z ~427 ms dla ładowania bez pamięci podręcznej. Źródło
• Duże witryny blokują się same najbardziej: wśród 1 000 największych witryn ~28 % stron na komputerach i ~20 % na urządzeniach mobilnych nadal używa handlerów unload, w porównaniu z ~11 % / ~10 % we wszystkich witrynach — a użycie no-store rośnie (~21 %→23 %). Źródło

Sprawdź się: Back/Forward Cache (bfcache)

Pięć krótkich pytań o to, czym jest bfcache, co go blokuje i jak ma się do SEO. Wybierz odpowiedź na każde pytanie, a następnie sprawdź.

Dziennik zmian