Back/Forward-Cache (bfcache)

TL;DR — Der Back/Forward-Cache (bfcache) ist eine Browserfunktion, die eine ganze Seite im Speicher einfriert, wenn Sie die Seite verlassen. Dadurch kann Zurück oder Vorwärts die Seite sofort und ohne erneutes Laden zurückbringen — sofern der Browser die eingefrorene Seite nicht vorher entfernt. Das ist eine Browserfunktion, kein Google-Rankingfaktor. Weil eine wiederhergestellte Seite aber nahezu sofort erscheint, verbessert sie unauffällig die Core-Web-Vitals-Werte bei den Back/Forward-Navigationen, die tatsächlich wiederhergestellt werden. Deshalb kann ein Performance-Audit empfehlen, die „bfcache-Eignung“ zu beheben.

Was der bfcache ist

Wenn Sie im Browser auf Zurück klicken, geschieht eines von zwei Dingen. Entweder baut der Browser die vorherige Seite vollständig neu auf — lädt Dateien erneut, führt JavaScript wieder aus und berechnet das Layout neu — oder er stellt die Seite sofort genau in dem Zustand wieder her, den sie beim Verlassen hatte. Diese sofortige Variante ist der Back/Forward-Cache, kurz bfcache.

Der Trick: Statt die alte Seite beim Weitergehen zu verwerfen, friert der Browser die gesamte Seite im Speicher ein — einschließlich des laufenden JavaScript — und bewahrt sie dort auf. Wenn Sie bald zurückkehren und die eingefrorene Seite noch vorhanden ist, taut der Browser sie auf und zeigt exakt dieselbe Seite wieder an — ohne Netzwerkanfragen und ohne Wartezeit. Eine Wiederherstellung ist möglich, aber nicht garantiert: Bei knappem Speicher, nach einem Timeout oder wegen bestimmter Aktivitäten kann der Browser die Seite vorher entfernen; dann erhalten Sie eine normale Neuladung.

Googles eigene Kurzbeschreibung bringt es auf den Punkt: bfcache ist “a browser optimization that enables instant back and forward navigation.” (Übersetzung) „eine Browseroptimierung, die sofortige Zurück- und Vorwärtsnavigation ermöglicht.“

Warum das nicht der „Cache“ ist, den Sie bereits kennen

Hier wird am häufigsten etwas verwechselt. Bei „Cache“ denken Sie wahrscheinlich an den Browser-Cache oder HTTP-Cache — Dateien wie Bilder, Skripte und Stylesheets, die der Browser speichert, damit er sie nicht erneut herunterladen muss. Der bfcache ist etwas anderes. Diese Caches speichern Dateien; der bfcache speichert die gesamte lebendige Seite samt JavaScript-Zustand als Snapshot. Chromes eigene Dokumentation sagt ausdrücklich, dass sich bfcache “differs from browser cache and HTTP cache.” (Übersetzung) „sich vom Browser-Cache und vom HTTP-Cache unterscheidet.“

Er ist auch nicht mit zwei anderen Mechanismen gleichzusetzen: dem im Speicher gehaltenen Ressourcen-Cache des Browsers (kompilierte Skripte und dekodierte Bilder für die aktuelle Sitzung) und dem Cache Storage eines Service Workers (Request-/Response-Paare, die eine Website über caches.open() selbst verwaltet). Beide können auf derselben Seite neben dem bfcache aktiv sein — sie sind dennoch getrennte Mechanismen und nicht der bfcache selbst.

Er ist außerdem nicht die alte Funktion „cached page“ oder „cached snapshot“, die Google und Bing früher in den Suchergebnissen angeboten haben — das kleine Dropdown mit einer gespeicherten Seitenversion. Diese Suchfunktion wurde eingestellt. Der bfcache ist eine lebendige Browserfunktion und hat nichts mit Suchergebnissen zu tun.

Hilft der bfcache meiner SEO?

Nicht direkt. Der bfcache ist kein Google-Rankingfaktor — Googles Dokumentation zu Core-Web-Vitals-Rankings erwähnt ihn nicht. Er sorgt dafür, dass Back/Forward-Navigationen für Besucher mit einer tatsächlichen Wiederherstellung nahezu sofort laden; Browser messen das als hervorragenden „Seitenaufbau“. Wenn viele Besucher Zurück und Vorwärts nutzen (etwa beim Einkaufen, in Suchergebnissen oder beim Lesen von Artikel zu Artikel), kann bfcache dadurch die Feldwerte Ihrer gesamten Core Web Vitals verbessern. Das ist einer von vielen Faktoren, von denen Google sagt, dass sie mit dem übereinstimmen, was seine Rankingsysteme belohnen. Die Kette ist also zwei Schritte von „bfcache verbessert Rankings“ entfernt. Sie garantiert weder Ihre Wiederherstellungsrate noch Ihre Gesamtbewertung der Core Web Vitals oder Ihre Rankings — sie ist aber real und messbar.

Sie möchten das vollständige Bild — was bfcache genau blockiert, wie Sie ihn testen und wie die präzise, nicht übertriebene Verbindung zu den Core Web Vitals aussieht? Wechseln Sie zum Tab Fortgeschritten.

TL;DR — Bfcache ist ein ganzseitiger Snapshot im Arbeitsspeicher (DOM + JS-Heap + laufender Zustand), keine erneut abrufbare HTTP-Antwort, kein Ressourcen-Cache des Browsers und kein Cache Storage eines Service Workers. Beim Wegnavigieren pausiert der Browser JavaScript und friert die Seite ein; bei Zurück/Vorwärts taut er den Snapshot — falls er noch vorhanden ist — auf und zeigt ihn ohne Netzwerkanfragen sofort wieder an. Eine Entfernung bleibt jederzeit möglich, daher ist eine Wiederherstellung wahrscheinlich, aber nicht garantiert. Der bfcache ist kein dokumentierter Google-Suchrankingfaktor; die Core-Web-Vitals-Dokumentation von Search Central erwähnt ihn nicht. Seine Bedeutung ist indirekt und begrenzt: Feldmessungen der CWV, vor allem LCP und CLS, werden bei wiederhergestellten Navigationen besser gemessen. Das garantiert weder Wiederherstellungsrate, aggregierte CWV-Bewertung, Rankings noch Conversions.

Der größte Eignungsblocker ist der unload-Handler (in Chrome etwa 18 Prozentpunkte weniger Treffer); historisch war Cache-Control: no-store der größte Blocker (etwa 17 % mobiler und 7 % Desktop-History-Navigationen). Nach dem Rollout 2025 erlaubt Chrome bfcache für viele no-store-Seiten unter Bedingungen (bei Änderungen an Authentifizierung oder Cookies wird die Seite entfernt; dieselben APIs mit offenen Verbindungen blockieren sie weiterhin). Offene Verbindungen, Timer und Observer sollten bei pagehide/freeze geschlossen oder pausiert und bei pageshow/resume neu aufgebaut werden. Auch window.opener, Permissions Policies und Frames können blockieren — prüfen Sie den Grund pro Frame in DevTools oder notRestoredReasons, statt etwas anzunehmen. Testen Sie einzelne Fälle mit Chrome DevTools und diagnostizieren Sie die Produktion mit der nur in Chrome verfügbaren notRestoredReasons-API; null beweist keine Wiederherstellung, und die Begründungstexte sind nicht stabil. Jeder Browser hat eigene Eignungsregeln, und die Soft-Navigation einer SPA wird nicht gleich behandelt.

Was bfcache tatsächlich ist (die Genauigkeitsgrundlage)

Das Wichtigste zuerst: bfcache ist ein ganzseitiger Snapshot im Speicher und keine gespeicherte HTTP-Antwort. Wenn Sie eine Seite verlassen, baut der Browser sie nicht einfach ab, sondern pausiert die JavaScript-Ausführung und friert die gesamte Seite ein — DOM, JS-Heap, laufende Timer und alles Weitere. Drücken Sie Zurück oder Vorwärts, solange der Snapshot verfügbar ist, taut der Browser ihn auf und zeigt exakt die verlassene Seite wieder an, mit null Netzwerkanfragen und null Neurendering. Das ist eine mögliche Wiederherstellung, keine Garantie: Speicher- druck, Timeout oder eine browserspezifische Regel können einen neuen Ladevorgang erzwingen. Googles kanonische Formulierung lautet: “a browser optimization that enables instant back and forward navigation.” (Übersetzung) „eine Browseroptimierung, die sofortige Zurück- und Vorwärtsnavigation ermöglicht.“

Deshalb ist die Verwechslung mit dem HTTP-/Browser-Cache der typische Fehler in Konkurrenzinhalten. Der HTTP-Cache speichert Antworten früherer Requests, also Dateien, die erneut ausgeliefert werden können. Bfcache speichert die laufende Seite. Die Chrome-DevTools-Dokumentation grenzt beides ausdrücklich ab: bfcache “differs from browser cache and HTTP cache.” (Übersetzung) „sich vom Browser-Cache und vom HTTP-Cache unterscheidet.“ Sie „aktivieren“ bfcache nicht mit Cache-Headern wie den HTTP-Cache. Header spielen hier nur insofern eine Rolle, als Cache-Control: no-store eine Seite früher disqualifizierte.

Dasselbe gilt für zwei weitere Caches, die oft mit bfcache vermischt werden: den im Speicher gehaltenen Ressourcen-Cache des Browsers (kompilierte Skripte und dekodierte Bilder der aktuellen Sitzung) und den Cache Storage eines Service Workers (Request-/Response-Paare, die eine Website über caches.open() selbst verwaltet). Beide können gleichzeitig mit bfcache aktiv sein. Keiner von beiden ist bfcache: Dieser speichert die eingefrorene Seiteninstanz, nicht gecachte Assets oder abgefangene Antworten.

Eine weitere wichtige Abgrenzung: Bfcache hat nichts mit der alten Suchfunktion „cached page“ zu tun, die Google und Bing früher in den Ergebnissen angezeigt haben. Das war ein gespeicherter Snapshot einer Seite im Suchindex und wurde eingestellt. Bfcache ist eine clientseitige Funktion der Rendering-Engine.

Wie häufig sind Back/Forward-Navigationen wirklich?

Das ist kein seltener Sonderfall. Laut web.dev sind “1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward.” (Übersetzung) „Eine von zehn Desktop- und eine von fünf mobilen Navigationen sind entweder Zurück- oder Vorwärtsnavigationen.“ Auf jeder Website mit wiederholten Zurück-/Vorwärts-Abläufen — Kategorie zu Produkt und zurück, Suchergebnisse, paginierte Inhalte oder Lesen von Artikel zu Artikel — ist das ein großer Anteil echter Navigationen, die nahezu sofort erfolgen können.

Browserunterstützung

“All major browsers include a bfcache, including Chrome since version 96, Firefox and Safari.” (Übersetzung) „Alle großen Browser verfügen über einen bfcache, darunter Chrome ab Version 96 sowie Firefox und Safari.“ Firefox und Safari haben eigene, schon länger bestehende bfcache-Implementierungen; alle Chromium-basierten Browser (Edge, Brave, Opera und Arc) übernehmen Chromes Verhalten. Microsofts Edge-Richtlinie beschreibt dieselbe Funktion: Beim Wegnavigieren darf der aktuelle Zustand (Dokumentenbaum, Skript und Ähnliches) im Back-Forward-Cache erhalten bleiben und beim Zurücknavigieren wieder angezeigt werden. In Edge ist die Funktion standardmäßig aktiviert; abschalten kann sie nur eine von der IT verwaltete Unternehmensrichtlinie, nicht der Websitebesitzer.

Der wichtige Vorbehalt: Jeder Browser wendet eigene bfcache-Eignungsregeln an. Eine Seite, die den Chrome-DevTools-Test „Test back/forward cache“ besteht, ist deshalb in Firefox oder Safari nicht automatisch geeignet. Behandeln Sie einen Chrome-Erfolg als notwendig, aber nicht als ausreichend.

Was die bfcache-Eignung blockiert

Das unload-Event — der größte einzelne Blocker

Wenn Sie nur eine Sache aus diesem Artikel mitnehmen: Verwenden Sie das unload-Event nicht. web.dev betont es ungewöhnlich deutlich: “Never use the unload event. Ever!” (Übersetzung) „Verwenden Sie das unload-Event nie. Niemals!“ In Chrome kosten unload-Handler ungefähr 18 Prozentpunkte bfcache-Trefferquote — mit Abstand der größte selbst verursachte Ausschlussgrund.

Chrome schafft das Event aus zwei Gründen schrittweise ab. Erstens ist es der größte bfcache-Blocker. Zweitens ist unload ohnehin extrem unzuverlässig: Auf Mobilgeräten wird es häufig gar nicht ausgelöst, weil Tabs in den Hintergrund gehen und beendet werden und der Browser bfcache gegenüber dem Auslösen von unload bevorzugt. Das Event, auf das Sie sich für „Aufräumen“ verlassen, läuft also oft nicht und verhindert zugleich einen echten Performancegewinn.

Die Lösungen:

• Ersetzen Sie unload durch pagehide. Das pagehide-Event wird in allen Fällen ausgelöst, in denen unload ausgelöst wird, und zusätzlich beim Eintritt in bfcache — es ist also eine strikte Verbesserung. Verwenden Sie visibilitychange für zuverlässiges Aufräumen, wenn der Benutzer die Seite verlässt.
• Erkennen Sie eine bfcache-Wiederherstellung mit pageshow. Hören Sie auf pageshow und prüfen Sie event.persisted. Ist der Wert true, wurde die Seite aus bfcache wiederhergestellt; aktualisieren Sie dann veraltete Daten oder zählen Sie einen Pageview erneut.
• Blockieren Sie unload-Listener proaktiv mit dem Response-Header Permissions-Policy: unload=(). Dadurch können überhaupt keine unload-Handler registriert werden. Chrome migriert die Standardrichtlinie schrittweise zu „deny“; eine entsprechende Permissions-Policy wurde ab Chrome 115 ausgeliefert.

Cache-Control: no-store — historisch der größte, heute nuancierter

Das ist der Aktualitätspunkt, den viele Konkurrenztexte falsch darstellen. Historisch war Cache-Control: no-store der wichtigste einzelne Grund, aus dem Seiten vom bfcache ausgeschlossen wurden — Chromes Zahlen nennen etwa 17 % der History-Navigationen auf Mobilgeräten und 7 % auf dem Desktop. Viele Websites setzen no-store vorsorglich, damit keine veraltete Seite ausgeliefert wird. Google argumentiert jedoch, dass eine bfcache-Wiederherstellung keine veraltete gecachte Antwort lädt, sondern die exakt gleiche lebendige Seite wieder anzeigt, fast als wäre der Tab geöffnet geblieben.

Chrome hat sein Verhalten daher geändert — aber bedingt und nicht universell. Experimente begannen in Chrome 116; der vollständige Rollout für 100 % der Nutzer erfolgte über März und April 2025. Chrome erlaubt bfcache nun für viele no-store-Seiten, sofern bestimmte Sicherheitsbedingungen erfüllt sind. Laut Chromes Dokumentation wird die Seite aus bfcache entfernt, wenn sich Authentifizierungszustand oder Cookies während des Einfrierens ändern, damit ein abgemeldeter oder cookie-bereinigter Besucher keinen veralteten angemeldeten Snapshot sieht. Eine festgelegte Liste von APIs — dieselben offenen Verbindungs-APIs wie IndexedDB, WebSocket und WebRTC — schließt no-store- Seiten weiterhin aus. Das ist browserspezifisches Verhalten in einem bestimmten Versionsbereich, keine Regel für andere Browser oder alte Chrome-Versionen. Verwenden Sie den aktuellen DevTools-/notRestoredReasons-Bericht für genau den Browser und die Version, die Sie testen, statt einer starren Faustregel. Praktische Konsequenz: Jede Anleitung, die no-store — auch ältere Versionen dieser Anleitung — als bedingungslosen, dauerhaften bfcache-Blocker auflistet, ist veraltet; veraltet ist aber auch die Behauptung, das Problem sei vollständig gelöst. Wenn Aktualität für eine Seite entscheidend ist, empfehlen Chromes Dokumente no-cache oder ein kurzes max-age (etwa max-age=60) statt no-store.

Offene Verbindungen, Observer und andere Blocker

Beim Navigieren können bestimmte noch offene Ressourcen die Eignung verhindern — welche genau blockieren und welche nur geschlossen und später neu verbunden werden, hängt von Browser und Version ab. Die folgende Liste ist ein Musterbeispiel, keine feste und dauerhafte Blockerliste:

• Laufende fetch()- oder XMLHttpRequest-Requests.
• Offene IndexedDB-Transaktionen.
• Offene WebSocket-/WebRTC-Verbindungen, Timer und Observer (MutationObserver, IntersectionObserver und ähnliche). Dieser Bereich verbessert sich laufend: Aktuelle Microsoft-Edge-Release-Notes zeigen, dass ein offener WebSocket beim Eintritt in bfcache nun geschlossen werden kann, statt das Caching vollständig zu blockieren. Die empfohlene Wiederverbindung erfolgt über pageshow und die Prüfung von event.persisted. Das entspricht Chromes Trend, Blocker zu reduzieren, statt Seiten pauschal auszuschließen.

Das allgemeine Muster, an dem Sie sich orientieren sollten, statt eine unveränderliche Liste auswendig zu lernen: Schließen oder pausieren Sie offene Verbindungen, Timer und Observer bei pagehide/freeze und **bauen Sie diese bei pageshow/resume wieder auf, wenn event.persisted den Wert true hat. Dieses Muster bleibt gültig, wenn sich in einem Browser ändert, welche APIs die Eignung direkt blockieren und welche er nur pausiert.

window.opener, Permissions Policies und Frames. Eine window.opener-Referenz, bestimmte Permissions Policies und eingebettete Frames (gleicher oder anderer Ursprung) können die Eignung ebenfalls beeinflussen. Das steht auf der Checkliste, die ich aus Ahrefs’ CLS-Leitfaden und Chromes Dokumentation abgeleitet habe. Nehmen Sie aus einer allgemeinen Checkliste aber nicht den tatsächlichen Grund an: Chrome DevTools und die notRestoredReasons-API melden blockierende Gründe pro Frame — für den obersten Frame und jedes iframe getrennt. Ermitteln Sie den echten Grund aus diesem Frame-Bericht für den getesteten Browser, statt von einer Standardliste auszugehen.

Die Sequenz aus Lifecycle-Events und Zuständen richtig lesen

Die Verwechslung dessen, was ein Lifecycle-Event tatsächlich beweist und was es nur nahelegt, ist nach Eignungsfehlern der zweithäufigste Korrektheitsfehler:

Die praktische Regel: Behandeln Sie pagehide.persisted als Absicht, nicht als Beweis — die Seite kann vor dem Zurückkehren noch entfernt werden. Nur pageshow.persisted === true beweist eine Wiederherstellung. Räumen Sie bei pagehide/freeze bedingungslos auf (das ist günstig und sicher, auch bei normaler Navigation). Führen Sie wiederherstellungsspezifische Arbeit erst bei pageshow/resume und nur bei event.persisted aus, damit Sie bei einem normalen Ladevorgang weder Daten unnötig aktualisieren noch einen Analytics-View doppelt zählen.

So testen und diagnostizieren Sie bfcache

Labor / Einzelfall: Chrome DevTools

Öffnen Sie DevTools → Application → Background services → Back/forward cache und klicken Sie auf „Test back/forward cache“. Chrome navigiert automatisch zu chrome://terms/ und zurück und meldet entweder Erfolg oder eine konkrete Liste blockierender Gründe. Das eignet sich für eine einzelne URL.

Produktion / Feld: die notRestoredReasons-API

Früher war der manuelle DevTools-Test für eine URL die einzige Möglichkeit, die Eignung zu prüfen — es gab keinen Weg zu sehen, warum Navigationen echter Nutzer blockiert wurden. Die Eigenschaft notRestoredReasons auf PerformanceNavigationTiming (seit Chrome 123+) schließt diese Lücke: Sie meldet den konkreten Blockierungsgrund für den Top-Frame und gleichursprüngliche iframes in echten Felddaten.

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

Ein paar Punkte sollten Sie laut Chromes eigener API-Anleitung beachten:

• Nur Chrome (123+). Firefox und Safari bieten keine gleichwertige Feld-API; für deren Wiederherstellungsrate brauchen Sie weiterhin manuelle Stichproben.
• Ein Ergebnis null ist mehrdeutig, kein grünes Signal. Es kann bedeuten, dass die Seite wiederhergestellt wurde, oder dass der Browser schlicht keinen Grund gesammelt hat. Chromes Dokumentation warnt davor, null als Beweis einer erfolgreichen Wiederherstellung zu behandeln.
• Der Begründungstext ist kein stabiles Vertragsformat. Codieren Sie keine festen Stringvergleiche; gruppieren und verfolgen Sie Gründe stattdessen, da sich die genaue Formulierung zwischen Chrome-Versionen ändern kann.

Praktisch bedeutet das: Erfassen Sie notRestoredReasons zusammen mit den Wiederherstellungsraten von pageshow.persisted vor und nach dem Rollout einer Änderung. Vergleichen Sie den Trend statt eines einzelnen Snapshots und ergänzen Sie einen manuellen DevTools-/Labortest in Firefox und Safari, die diese API nicht unterstützen. Das ist das richtige Werkzeug für bfcache-Diagnosen in RUM und Produktion — aber nicht das ganze Bild.

Bfcache und Core Web Vitals — der genaue Zusammenhang

Hier verwischen die meisten Konkurrenztexte die Nuance — und genau das ist der Punkt, den man sauber besitzen sollte.

Wie eine bfcache-Wiederherstellung gemessen wird. Browser und damit auch CrUX-Felddaten zählen eine aus bfcache wiederhergestellte Navigation als extrem schnellen „Seitenaufbau“: nahezu sofortiges LCP und — wenn die Seite korrekt umgesetzt ist und kein neues Layout berechnet werden muss — effektiv null zusätzlicher CLS. In DebugBears Vergleich mit echten Daten lag das LCP einer wiederhergestellten Seite bei etwa 100ms gegenüber ungefähr 427 ms bei einem nicht gecachten Laden. Genau deshalb erscheint bfcache in meiner eigenen Ahrefs-CLS-Checkliste als Hebel für CLS und LCP. Dort formuliere ich es so: “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.” (Übersetzung) „Stellen Sie sicher, dass Ihre Seiten für bfcache geeignet sind. Der Back/Forward-Cache hält Seiten im Browser-Cache. Er ermöglicht das sofortige Laden einer bereits geladenen Seite, sodass keine Layoutverschiebungen auftreten.“

Zwei Einschränkungen verdienen Präzision. Erstens betrifft dies nur Navigationen, die CrUX als Back/Forward klassifiziert (die Dimension navigation-type). Über Erstbesuche oder Neuladungen sagt es nichts; diese bilden auf den meisten Websites die Mehrheit. Zweitens ist eine bessere gemessene Erfahrung für Nutzer mit Wiederherstellung keine Garantie: Wer aus bfcache entfernt wurde, erhält weiterhin einen normalen, nicht verbesserten Ladevorgang. Arbeiten an der Eignung erhöhen also die Wiederherstellungsrate innerhalb der Back/Forward-Navigationen, nicht einen festen Anteil des gesamten Traffics. Sie garantieren weder die aggregierten Core Web Vitals im Feld, Rankings noch die Conversion-Rate. Das ist ein echter, messbarer Hebel mit klar begrenztem Umfang, kein allgemeiner Performance- oder SEO-Fix.

Ist bfcache ein Rankingfaktor? Nein. Das ist die belastbare, unterscheidende Aussage. Googles eigene Dokumentation zu Core-Web-Vitals-Rankings erwähnt bfcache überhaupt nicht. Die ehrliche Wirkungskette ist: bfcache-Eignung → bessere CWV-Feldwerte (hauptsächlich LCP/CLS) bei Back/Forward-Navigationen → Core Web Vitals ist eines von vielen „Page-Experience“-Signalen, von denen Google sagt, dass sie mit den bereits belohnten Rankingsignalen übereinstimmen. Das ist deutlich schwächer und präziser als „bfcache verbessert Rankings“ — und die Aussage, die Konkurrenzinhalte vorsichtiger formulieren sollten. Bfcache ist außerdem korrekt eingeordnet eine Funktion der Rendering-Engine, keine Crawler-Funktion. Er hat nichts damit zu tun, wie Googlebot oder Bingbot Seiten crawlen; deshalb gibt es für SEO auch kein „Bings Sicht auf bfcache“ wie bei robots.txt oder Sitemaps.

SPAs und Soft-Navigationen. Bfcache arbeitet mit echten Browsernavigationen und History-Events. Ein clientseitiger „weicher“ Routenwechsel einer Single-Page- App (ein durch JavaScript ausgelöster View-Wechsel ohne echte Browsernavigation) ist kein bfcache-Event und wird nicht gleich behandelt. Versuche mancher RUM-Tools, Core Web Vitals weichen Navigationen zuzuordnen, können Messunterschiede zwischen CrUX und RUM erzeugen — ein wichtiger Hinweis bei Audits von JavaScript-Framework-Websites.

Wie häufig verhindern Blocker den bfcache in der Praxis?

Das Web Almanac des HTTP Archive verfolgt dies; die Lage ist aktuell und bewegt sich weiter. In der Ausgabe 2022 waren allein aufgrund der Kriterien unload und no-store mindestens etwa 22 % der mobilen Seiten nicht bfcache-fähig. Seitdem ist die Nutzung von unload über Website-Klassen und Geräte hinweg gesunken, während Cache-Control: no-store zugenommen hat. Das Kapitel von 2025 nennt etwa 23 % der Websites gegenüber ungefähr 21 % im Jahr 2024, teilweise wegen stärker personalisierter/authentifizierter Erlebnisse und strengerer Compliance-Anforderungen.

Der kontraintuitive Befund: Größere Websites mit mehr Traffic blockieren ihren eigenen bfcache überproportional häufig. Bei den 1 000 größten Websites verwenden noch etwa 28 % der Desktop- und 20 % der mobilen Seiten unload-Handler, gegenüber nur ungefähr 11 % Desktop und 10 % mobil über alle Websites hinweg — oft, weil große Websites mehr veraltete Analytics- und unload-abhängige Skripte mitführen. Gerade die Websites, die den meisten Back/Forward-Traffic verlieren können, stehen sich häufig selbst im Weg.

Wo das einzuordnen ist

Bfcache ist ein Performancehebel unter mehreren in diesem Themenbereich. Sein Nutzen zeigt sich in den Felddaten der Core Web Vitals, genauer bei Cumulative Layout Shift und Largest Contentful Paint, weil eine wiederhergestellte Seite sofort und ohne Neuberechnung des Layouts angezeigt wird. Das ist etwas anderes als Caching, das Dateien statt eines lebendigen Seitensnapshots speichert, auch wenn beide über den Cache-Control-Header verbunden sind. Einen direkten Zusammenhang mit Interaction to Next Paint gibt es nicht; ich werde keinen erzwingen.

KI-Zusammenfassung

Eine komprimierte Fassung der Advanced-Version:

• Bfcache = ein ganzseitiger Snapshot im Speicher (DOM + JS-Heap + laufender Zustand), keine erneut abrufbare HTTP-Antwort, kein Ressourcen-Cache und kein Cache Storage eines Service Workers. Beim Wegnavigieren pausiert der Browser JavaScript und friert die Seite ein; bei Zurück/Vorwärts taut er sie ohne Netzwerkanfragen sofort auf, wenn der Snapshot noch vorhanden ist. Eine Entfernung bleibt möglich, daher ist eine Wiederherstellung wahrscheinlich, nicht garantiert. Chromes Dokumentation sagt, dass bfcache “differs from browser cache and HTTP cache.” (Übersetzung) „sich vom Browser-Cache und vom HTTP-Cache unterscheidet.“ Er ist auch nicht die alte, eingestellte Suchfunktion „cached page“.
• Kein Rankingfaktor und nur begrenzter Umfang. Googles Core-Web-Vitals- Rankingdokumente erwähnen bfcache nicht. Die indirekte Kette lautet: bfcache-Eignung → bessere CWV-Feldwerte (vor allem LCP/CLS) bei wiederhergestellten Back/Forward-Navigationen → CWV ist eines der Page-Experience-Signale, die laut Google zu seinen Rankingsystemen passen. Wiederherstellungsrate, aggregierte CWV, Rankings und Conversions werden nicht garantiert; betroffen sind nur von CrUX als Back/Forward klassifizierte Navigationen.
• Skalierung: „1 von 10 Navigationen auf dem Desktop und 1 von 5 auf Mobilgeräten ist Zurück oder Vorwärts.“ Unterstützung: Chrome ab Version 96 sowie Firefox und Safari — aber mit jeweils eigenen Eignungsregeln.
• Größter Blocker: das unload-Event (“Never use the unload event. Ever!” (Übersetzung) „Verwenden Sie das unload-Event niemals.“) — etwa 18 Prozentpunkte der Chrome-Trefferquote. Ersetzen Sie es durch pagehide + visibilitychange, erkennen Sie Wiederherstellungen mit pageshow/event.persisted und blockieren Sie unload über Permissions-Policy: unload=().
• Cache-Control: no-store war historisch der größte Blocker (etwa 17 % mobil und 7 % Desktop). Nach dem Rollout von März/April 2025 erlaubt Chrome bfcache für viele no-store-Seiten bedingt; Änderungen an Authentifizierung/Cookies entfernen den Snapshot und die offenen Verbindungs-APIs blockieren weiterhin. Nur Chrome ist gemeint: Alte Anleitungen mit einem absoluten Blocker sind veraltet, die Behauptung einer vollständigen Lösung aber ebenfalls.
• Weitere Blocker: laufende fetch/XHR-Requests, Timer, Observer, offene IndexedDB, WebSocket/WebRTC (bei pagehide/freeze schließen oder pausieren, bei pageshow/resume neu verbinden), window.opener, Permissions Policies und Frames. Ermitteln Sie den Grund pro Frame aus DevTools/notRestoredReasons holen, nicht raten.
• Lifecycle-Korrektheit: pagehide.persisted ist Absicht, kein Beweis; nur pageshow.persisted === true bestätigt eine Wiederherstellung. Bei pagehide/freeze bedingungslos aufräumen; spezielle Wiederherstellungsarbeit (sensible Daten aktualisieren, verbinden, einen Analytics-View zählen) nur bei pageshow/resume.
• Tests: Chrome DevTools „Test back/forward cache“ für einzelne Fälle; die Chrome-only-API notRestoredReasons (Chrome 123+) für Felddaten. null ist kein Beweis, Begründungstexte sind nicht stabil, und Firefox sowie Safari brauchen manuelle Stichproben. Vergleichen Sie notRestoredReasons-Daten und die Wiederherstellungsraten von pageshow.persisted vor und nach einer Änderung.
• SPAs: Clientseitige Soft-Navigationen sind keine bfcache-Events und werden nicht gleich behandelt (eine Ursache für CrUX-vs.-RUM-Abweichungen).
• Verbreitung (Web Almanac): no-store-Nutzung steigt (etwa 21 % → 23 %); unload-Nutzung ist bei den größten Websites höher (etwa 28 % Desktop unter den Top 1 000). Große Websites blockieren ihren eigenen bfcache häufig.

Offizielle Dokumentation

Primärquellen zum bfcache. Achten Sie auf die Trennung: Bfcache lebt in den Chrome-/Rendering-Engine-Dokumenten (Googles institutionelle Stimme dazu), nicht in Googles Search Central — genau diese Trennung ist der Punkt.

Google / Chrome

• Back/Forward-Cache — die kanonische Dokumentation: Definition, Mechanismus, die Statistik 1 von 10 / 1 von 5 und unload- Hinweise.
• Back/Forward-Cache testen — DevTools-Schritte, wichtigste Blocker und die ausdrückliche Aussage, dass bfcache sich von Browser- und HTTP-Cache unterscheidet.
• Bfcache für Cache-Control: no-store aktivieren — die Richtlinienänderung 2025, die Werte 17 % / 7 % und der Rollout.
• Das unload-Event abschaffen — warum unload ausläuft und die Migration der Permissions-Policy.
• notRestoredReasons-API des Back/Forward-Caches — Diagnose im Feld über PerformanceNavigationTiming (Chrome 123+).
• Core Web Vitals und Google-Suchergebnisse verstehen — Googles Search-Central-Rankingdokument, das bezeichnenderweise bfcache nicht erwähnt.

Microsoft / Edge

• Microsoft-Edge-Richtlinie: BackForwardCacheEnabled — Edges Definition, derselbe unload-Vorbehalt und der Schalter über die Unternehmensrichtlinie.

MDN / Webstandards

• bfcache — MDN Glossary — allgemeine Webentwicklerdefinition und die Abgrenzung zum HTTP-Cache.
• Blockierungsgründe des bfcache überwachen — MDN — praktische Nutzung von notRestoredReasons.

Zitate aus den Quellen

Aussagen aus der Quelldokumentation, die namentlich zugeschrieben sind. Jeder Link führt über einen Deep Link direkt zur zitierten Passage auf der Quellseite.

Google / Chrome — was bfcache ist und warum er wichtig ist

• “Back/forward cache (or bfcache) is a browser optimization that enables instant back and forward navigation.” (Übersetzung) „Der Back/Forward-Cache (oder bfcache) ist eine Browseroptimierung, die sofortige Zurück- und Vorwärtsnavigation ermöglicht.“ — web.dev. Zum Zitat
• “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!” (Übersetzung) „Eine von zehn Desktop- und eine von fünf mobilen Navigationen sind entweder Zurück- oder Vorwärtsnavigationen. Mit aktiviertem bfcache könnten Browser die Datenübertragung und Ladezeit für Milliarden Webseiten jeden Tag vermeiden.“ Zum Zitat
• “All major browsers include a bfcache, including Chrome since version 96, Firefox and Safari.” (Übersetzung) „Alle großen Browser verfügen über einen bfcache, darunter Chrome ab Version 96 sowie Firefox und Safari.“ Zum Zitat

Google / Chrome — die wichtigste Optimierungsregel

• “Never use the unload event. Ever!” (Übersetzung) „Das unload-Event darf niemals verwendet werden.“ — web.dev. Zum Zitat

Chrome DevTools — bfcache ist nicht der HTTP-Cache

• “Back/forward cache differs from browser cache and HTTP cache.” (Übersetzung) „Der Back/Forward-Cache unterscheidet sich vom Browser- und HTTP-Cache.“ — Chrome-DevTools-Dokumentation. Zum Zitat

Microsoft Edge — dieselbe Funktion, derselbe Vorbehalt

• “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.” (Übersetzung) „Wenn Sie eine Seite verlassen, kann ihr aktueller Zustand (Dokumentbaum, Skript usw.) im Back/Forward-Cache erhalten bleiben. Navigiert der Browser zurück zur Seite, kann er sie aus dem Back/Forward-Cache wiederherstellen und in dem Zustand anzeigen, in dem sie vor dem Caching war.“ — Microsoft-Edge-Richtliniendokumentation. Zum Zitat

Patrick Stox (ich) — bfcache als CLS-Hebel

• “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.” (Übersetzung) „Prüfen Sie, dass Ihre Seiten für bfcache geeignet sind. Der Back/Forward-Cache hält Seiten im Browser-Cache und lädt bereits geladene Seiten sofort, sodass keine Layoutverschiebungen entstehen.“ — mein Ahrefs-CLS-Leitfaden. Lesen

Checkliste für bfcache-Eignung

Ein Durchlauf, um zu bestätigen, dass Ihre Seiten in den Back/Forward-Cache gelangen können:

• Auf der Seite gibt es nirgendwo unload-Event-Listener (weder eigene noch von Drittanbieter-Skripten). Das ist der größte einzelne Blocker.
• Cleanup-/Analytics-Code wurde von unload auf pagehide und visibilitychange umgestellt.
• Ein pageshow-Listener prüft event.persisted, aktualisiert veraltete Daten und zählt Pageviews nach einer bfcache-Wiederherstellung korrekt erneut.
• Erwägen Sie den Response-Header Permissions-Policy: unload=(), damit keine unload-Listener registriert werden.
• Prüfen Sie Cache-Control: no-store. Wenn Sie es vorsorglich setzen, bestätigen Sie, dass Sie es weiterhin benötigen (Chrome 2025+ erlaubt bfcache für viele no-store-Seiten bedingt; bei Authentifizierungs- oder Cookie-Änderung wird entfernt und offene Verbindungen blockieren weiterhin). Nehmen Sie nicht an, dass andere Browser oder Versionen gleich funktionieren; bei relevanter Aktualität sind no-cache oder ein kurzes max-age vorzuziehen.
• Beim Navigieren bleiben keine offenen Verbindungen, Timer oder Observer hängen — laufende fetch/XHR-Requests, offene IndexedDB-Transaktionen, WebSocket/WebRTC sowie MutationObserver/IntersectionObserver (bei pagehide/freeze schließen/pausieren, bei pageshow/resume, wenn event.persisted true ist, neu aufbauen).
• Keine window.opener-Referenzen, restriktiven Permissions Policies oder blockierten Frames halten die Seite ungeeignet — den Grund pro Frame in DevTools/notRestoredReasons prüfen, nicht raten.
• Labortest in Chrome DevTools → Application → Back/forward cache → „Test back/forward cache“.
• Feld-Diagnose im Maßstab mit notRestoredReasons in Ihrem RUM (nur Chrome; null ist kein Beweis, und der Begründungstext ist kein stabiles Vertragsformat — nach Grund gruppieren, keine Strings fest codieren).
• Nicht annehmen, dass ein Chrome-Erfolg überall gilt — Firefox und Safari stichprobenartig prüfen, da sie eigene Regeln anwenden.

Bfcache-Spickzettel

Was ihn blockiert — und die Lösung

Wichtige Events

Testen

Schnelle Fakten

• Bfcache = die gesamte lebendige Seite im Speicher, nicht Dateien, nicht der Ressourcen-Cache und nicht der Cache Storage eines Service Workers. Chrome sagt, dass er sich vom Browser- und HTTP-Cache unterscheidet.
• Kein Google-Rankingfaktor — die CWV-Dokumentation von Search Central erwähnt ihn nicht. Eine Wiederherstellung verbessert gemessenes LCP/CLS für die Nutzer, die sie erhalten; sie garantiert weder Rate, aggregierte CWV, Rankings noch Conversions.
• Unterstützung: Chrome 96+, Firefox und Safari — jeweils mit eigenen Regeln.
• 1 von 10 Desktop- / 1 von 5 Mobil-Navigationen ist Zurück oder Vorwärts.

Bfcache-Anti-Patterns (und die Mythen dahinter)

„Bfcache ist nur mein HTTP-/Browser-Cache — ich konfiguriere ihn mit Cache-Control.“ Nein. Bfcache ist ein eigener ganzseitiger Snapshot im Speicher; Chromes Dokumentation sagt, er unterscheide sich von Browser- und HTTP-Cache. Cache-Header sind nur insofern relevant, als no-store eine Seite früher disqualifizierte. Sie „schalten“ bfcache nicht mit Cache-Headern ein.

„Bfcache ist ein Google-Rankingfaktor, also verbessern Reparaturen meine Rankings.“ Dafür gibt es keine Feststellung in einer offiziellen Google-Search- Quelle. Das Rankingdokument zu Core Web Vitals erwähnt bfcache nicht. Der echte Zusammenhang ist indirekt (bessere LCP-/CLS-Feldwerte bei Back/Forward- Navigationen) — eine schwächere, präzisere Aussage.

„Cache-Control: no-store blockiert bfcache immer und dauerhaft.“ Historisch stimmt das — und es war weiterhin die größte historische Ursache —, aber nach Chromes vollständigem Rollout 2025 für sicheres no-store nicht mehr kategorisch. Ältere Anleitungen sind an genau diesem Punkt veraltet; falsch ist aber auch die Darstellung als vollständig gelöst: Chromes Ausnahme ist bedingt (Entfernung bei Auth-/Cookie-Änderungen, weiterhin Blockade durch dieselben offenen Verbindungs-APIs) und Chrome-spezifisch, nicht universell.

„Eine Seite, die pagehide mit persisted: true auslöst, war definitiv gecacht.“ Nein — das ist Absicht, kein Beweis. Der Browser kann die Seite noch entfernen, bevor Sie eine Wiederherstellung sehen. Nur pageshow.persisted === true bestätigt, dass tatsächlich wiederhergestellt wurde.

„Wenn der Chrome-DevTools-bfcache-Test besteht, ist die Seite überall geeignet.“ Falsch. Chrome, Firefox und Safari wenden jeweils eigene Einschränkungen an; ein Erfolg in einem Browser garantiert keine Eignung in einem anderen.

„unload ist eine gute Möglichkeit für Exit-/Cleanup-Code, also behalte ich es.“ Nein. Chrome nennt es extrem unzuverlässig (auf Mobilgeräten wird es oft überhaupt nicht ausgelöst) und schafft es über eine Permissions-Policy ab, gerade weil es der größte bfcache-Blocker ist. Verwenden Sie pagehide + visibilitychange.

„Bfcache hilft meiner SPA genauso wie einer mehrseitigen Website.“ Nicht ohne Einschränkung. Bfcache hängt an echten Browsernavigationen; ein clientseitiger „weicher“ Routenwechsel ist nicht dasselbe Event und wird nicht gleich behandelt. Das kann bei SPAs außerdem Unterschiede zwischen CrUX und RUM verursachen.

„Bfcache ist gelöst bzw. alte Neuigkeit und kein Audit wert.“ Die Daten des Web Almanac widersprechen dem: Die Nutzung von no-store steigt, und die Nutzung von unload bleibt gerade auf den größten Websites deutlich höher — jenen mit dem meisten Back/Forward-Traffic, den sie verlieren können.

Werkzeuge zum Testen und Diagnostizieren von bfcache

• Chrome DevTools — Back/forward-cache-Panel. Application → Background services → Back/forward cache → „Test back/forward cache“. Navigiert automatisch zu chrome://terms/ und zurück und meldet Erfolg oder die genauen Blockierungsgründe. Am besten für einen einzelnen URL-Labortest.
• Die notRestoredReasons-API (Chrome 123+). Lesen Sie performance.getEntriesByType('navigation')[0].notRestoredReasons in Ihrem RUM, um Blockierungsgründe echter Nutzer — auch für gleichursprüngliche iframes — im großen Maßstab zu sehen.
• PageSpeed Insights / Lighthouse / CrUX. Dort erscheint eine Empfehlung oder ein Hinweis zu „back/forward cache“ oft zuerst im Audit; dort zeigt sich auch der CWV-Feldnutzen einer bfcache-fähigen Website.
• Header Permissions-Policy: unload=(). Kein Testwerkzeug, aber der Durchsetzungshebel: Er verhindert aktiv, dass unload-Listener, einschließlich solcher von Drittanbietern, registriert werden.
• Web Almanac (Performance-Kapitel des HTTP Archive). Für Benchmarks, wie häufig bfcache-Blocker nach Gerät und Website-Rangklasse vorkommen.

DevTools meldet, dass ein unload-Handler die Wiederherstellung blockiert

Symptom: Der Back/Forward-Cache-Test nennt unload. Wahrscheinliche Ursache: Eigenes oder Drittanbieter-JavaScript hat einen unload-Listener registriert. Lösung: Cleanup durch pagehide/visibilitychange ersetzen, wo passend Permissions-Policy: unload=() ergänzen und nach Änderungen an jedem betroffenen Skript den Test erneut ausführen.

Eine wiederhergestellte Seite zeigt veraltete Nutzerdaten

Symptom: Zurück erscheint sofort, aber Kontozustand, Bestand oder ein anderer dynamischer Wert ist veraltet. Wahrscheinliche Ursache: Die Seite wurde aus ihrem eingefrorenen Zustand fortgesetzt, ohne zeitkritische Daten zu aktualisieren. Lösung: Auf pageshow hören, event.persisted prüfen und nur die benötigten Daten aktualisieren. Bestätigen, dass normale Ladevorgänge und Wiederherstellungen korrekt funktionieren.

Analytics verpasst oder verdoppelt Back/Forward-Views

Symptom: Pageview-Zahlen unterscheiden sich von tatsächlichen History-Navigationen. Wahrscheinliche Ursache: Analytics läuft nur beim ursprünglichen Laden oder zweimal, ohne eine Wiederherstellung zu unterscheiden. Lösung: pageshow ausdrücklich behandeln und event.persisted verwenden, um die wiederhergestellte Navigation genau einmal zu zählen.

Der Labortest besteht, aber die Feld-Wiederherstellung bleibt niedrig

Symptom: Eine Stichproben-URL besteht DevTools, während RUM viele Nicht-Wiederherstellungen meldet. Wahrscheinliche Ursache: Andere Templates, Browser, reale Nutzerzustände oder sporadische offene Verbindungen bringen weitere Blocker ein. Lösung: notRestoredReasons sammeln, nach Grund und Template gruppieren und den dominanten Feldfall reproduzieren, statt einen einzigen Erfolg zu verallgemeinern.

Nachweisen, dass eine bfcache-Reparatur ausgeliefert wurde

Eignungstest

Auszuführender Test: DevTools → Application → Back/forward cache → Test back/forward cache. Erwartetes Ergebnis: Die Seite wird erfolgreich ohne Blockierungsgrund wiederhergestellt. Interpretation eines Fehlschlags: Mindestens ein Eignungsblocker ist noch vorhanden. Beobachtungsfenster: Im getesteten Zustand sofort für Chrome. Rollback-Auslöser: Die Änderung beschädigt Cleanup, Sicherheit oder notwendiges Anwendungsverhalten.

Test des Wiederherstellungsverhaltens

Auszuführender Test: Wegnavigieren und Zurück; danach prüfen, dass pageshow event.persisted === true erhält und zeitkritische Daten aktualisiert werden. Erwartetes Ergebnis: Eine sofortige Wiederherstellung, korrekte Daten und genau ein Analytics-View. Interpretation eines Fehlschlags: Die Seite wurde entweder nicht gecacht oder die Behandlung der Wiederherstellung ist unvollständig. Beobachtungsfenster: Sofort über repräsentative an- und abgemeldete Zustände. Rollback-Auslöser: Veraltete sensible Daten oder doppelte Aktionen nach der Wiederherstellung.

Test der Feldgründe

Auszuführender Test: PerformanceNavigationTiming.notRestoredReasons im RUM überwachen. Erwartetes Ergebnis: Der gezielte Blocker nimmt für betroffene Templates ab, ohne dass ein neuer dominanter Blocker ihn ersetzt. Interpretation eines Fehlschlags: Die Laborstichprobe war nicht repräsentativ für die Produktion oder eine andere Abhängigkeit ist für das Problem zuständig. Beobachtungsfenster: Genügend echte Back/Forward-Navigationen, um denselben Template-Mix zu vergleichen. Rollback-Auslöser: Eine wesentliche Anwendungs- oder Datenintegritätsregression, die auf die Änderung zurückgeht.

Bfcache-Metriken, die sich lohnen

Trefferquote der Wiederherstellungen

Metrik: Geeignete Back/Forward-Navigationen, die aus bfcache wiederhergestellt wurden. Aussage: Wie häufig Nutzer den Vorteil der sofortigen Navigation erhalten. Erhebung: RUM-Navigationseinträge und pageshow.persisted, nach Browser und Template segmentiert. Benchmark / realistischer Bereich: Eine eigene Basislinie festlegen, weil Browserregeln, Seitenzustand und Navigationsmix unterschiedlich sind. Rhythmus: Wöchentlich und nach Lifecycle-Änderungen.

Gründe für Nicht-Wiederherstellungen

Metrik: History-Navigationen, gruppiert nach notRestoredReasons. Aussage: Welche Blocker die meisten echten Wiederherstellungen kosten. Erhebung: Die PerformanceNavigationTiming-API in unterstützenden Browsern. Benchmark / realistischer Bereich: Für Blocker, die der eigene Code kontrolliert, null anstreben und die Browser-/API-Abdeckung kennzeichnen. Rhythmus: Wöchentliche Triage.

Korrektheit wiederhergestellter Navigationen

Metrik: Fehler, Vorfälle mit veralteten Daten und doppelte Analytics- oder Anwendungsaktionen nach einer Wiederherstellung. Aussage: Ob höhere Eignung die Korrektheit der Anwendung erhält. Erhebung: RUM-Fehlerereignisse, Anwendungsmonitoring und Analytics-QA mit pageshow.persisted als Schlüssel. Benchmark / realistischer Bereich: Null bekannte Korrektheits- oder Datenschutzfehler. Rhythmus: Kontinuierliche Alarmierung und QA vor Releases.

Ressourcen, für die sich die Zeit lohnt

Meine verwandten Beiträge

• Was ist Cumulative Layout Shift (CLS) und wie verbessert man ihn? — dort führe ich bfcache-Eignung als CLS-Verbesserungshebel mit einer kurzen Blocker-Checkliste auf.
• Was sind Core Web Vitals (CWV) und wie verbessert man sie? — die übergeordneten Metriken, mit bfcache als einem von mehreren CLS-Hebeln.
• Der Einsteigerleitfaden für technisches SEO — dort wird Web-Performance in das größere Bild eingeordnet.

Meine Vorträge

• So funktioniert die Suche (SlideShare) — mein Überblick über Crawling, Rendering, Indexierung und Ranking; er erklärt, warum eine Rendering-Engine-Funktion wie bfcache außerhalb der Ranking-Signale der Suche liegt. (Mein ständiger Hinweis gilt: “This is my understanding of systems… not going to be 100% complete or accurate.” (Übersetzung) „Das ist mein Verständnis von Systemen … es wird nicht vollständig oder völlig korrekt sein.“)

Offiziell

• Back/Forward-Cache (web.dev) — die kanonische Dokumentation.
• Bfcache für Cache-Control: no-store aktivieren und Das unload-Event abschaffen (Chrome for Developers) — die beiden Änderungen, durch die ältere Anleitungen veraltet sind.
• Core Web Vitals und Google-Suchergebnisse verstehen (Google Search Central) — das Rankingdokument, das bezeichnenderweise bfcache nicht erwähnt.

Aus der Branche

• bfcache — MDN-Glossar — genaue, engine-neutrale Definition und Abgrenzung zum HTTP-Cache.
• Was bedeutet der Back/Forward-Cache für die Seitengeschwindigkeit? (DebugBear) — der datenreichste Beitrag zu diesem Thema, mit einem echten Website-Log und einem konkreten LCP-Vergleich (etwa 100ms gecacht gegenüber etwa 427 ms ungecacht).
• Back-Forward-Cache erklärt (SpeedVitals) — Mechanik, Eignung, Tests und CWV-Auswirkung.
• Back/Forward-Cache: Was er ist und wie man ihn implementiert (NitroPack) — auf Implementierung ausgerichtet, für CMS- und Hosting-Zielgruppen.
• Leistungssprung: Browser-Back/Forward-Cache (Smashing Magazine) — ein guter technischer Deep Dive, der jedoch vor der no-store-Änderung von 2025 erschien.
• Web Almanac — Performance-Kapitel (2025) (HTTP Archive) — reale Verbreitungsdaten zu unload und no-store, aufgeschlüsselt nach Gerät und Rangklasse.

Statistiken, die sich zitieren lassen

• Back/Forward-Navigationen sind häufig: „1 von 10 Navigationen auf dem Desktop und 1 von 5 auf Mobilgeräten ist Zurück oder Vorwärts“ — das zeigt die Größenordnung, nicht einen Sonderfall. Quelle
• unload kostet etwa 18 Prozentpunkte der bfcache-Trefferquote in Chrome — deshalb ist es der wichtigste Blocker und wird abgeschafft. Quelle
• Cache-Control: no-store war historisch der größte Blocker — ungefähr 17 % der History-Navigationen mobil und 7 % auf dem Desktop — bevor Chromes Rollout im März/April 2025 bfcache für viele no-store-Seiten erlaubte. Quelle
• Eine bfcache-Wiederherstellung ist nahezu sofort: DebugBear maß für eine wiederhergestellte Seite ungefähr 100ms LCP gegenüber etwa 427 ms bei einem ungecachten Laden. Quelle
• Große Websites blockieren sich am stärksten: Bei den 1 000 größten Websites verwenden etwa 28 % der Desktop- und 20 % der mobilen Seiten noch unload-Handler, gegenüber etwa 11 % / 10 % bei allen Websites; die Nutzung von no-store steigt (etwa 21 % → 23 %). Quelle

Testen Sie sich selbst: Back/Forward-Cache (bfcache)

Fünf kurze Fragen dazu, was bfcache ist, was ihn blockiert und wie er sich auf SEO bezieht. Wählen Sie jeweils eine Antwort und prüfen Sie anschließend.

Änderungsprotokoll