bfcache: Jede vierte Website lädt Seiten nach dem Zurück-Button meist neu

Tippt ein Besucher auf den Zurück-Button, kann die vorige Seite sofort wieder dastehen. Browser halten zuletzt besuchte Seiten im Arbeitsspeicher vor, im Back/Forward-Cache (bfcache), und stellen sie ohne eine einzige Netzwerkanfrage wieder her. Das klappt allerdings nur, wenn die Seite es zulässt. Wir haben die Chrome-Felddaten von 1.425 Websites ausgewertet: Bei jeder vierten kam weniger als ein Viertel der Zurück- und Vor-Navigationen aus dem bfcache. Bei allen übrigen Zurück-Navigationen wurde die Seite neu geladen.

Für diese Websites ist die schnelle Rückkehr zur vorigen Seite die Ausnahme. Die häufigsten Blocker lassen sich mit kleinen Änderungen beseitigen, und keiner davon verlangt einen schnelleren Server.

Der bfcache macht aus dem Zurück-Button einen Sofortaufruf

Ohne bfcache verhält sich der Zurück-Button wie ein neuer Besuch. Der Browser fordert das HTML erneut an, lädt Skripte und Stylesheets, führt JavaScript aus und baut die Seite auf. Mit bfcache bewahrt der Browser eine vollständige Momentaufnahme der Seite im Speicher auf, samt Scrollposition, Formulareingaben und Skriptzustand. Beim Zurückgehen holt er diese Momentaufnahme einfach wieder hervor.

Das ist wie ein Buch mit Lesezeichen: Mit bfcache schlagen Sie es an der richtigen Stelle auf, ohne bfcache beginnen Sie wieder beim Umschlag und blättern sich vor. Google bezeichnet den bfcache in seinem Leitfaden Back/forward cache (web.dev, zuletzt aktualisiert im Oktober 2026) als eine der wirksamsten Optimierungen für echte Besucher.

Etwa jeder neunte Seitenaufruf ist eine Zurück- oder Vor-Navigation

Navigationen durch den Verlauf sind kein Randfall. Bei der mittleren Website unserer Stichprobe waren auf Smartphones 11,4 Prozent aller Seitenaufrufe Zurück- oder Vor-Navigationen, also ungefähr jeder neunte. Besucher springen von der Produktseite zurück in die Kategorie, vom Artikel in die Übersicht oder vom Bestellschritt in den Warenkorb und erwarten, dass die vorige Seite sofort da ist.

Jede vierte Website verfehlt den bfcache bei den meisten Zurück-Navigationen

Die bfcache-Quote ist der Anteil der Zurück- und Vor-Navigationen, die Chrome aus dem bfcache bedient hat. Ausgewertet haben wir alle Websites der Stichprobe, bei denen mindestens zwei Prozent der Seitenaufrufe Zurück- oder Vor-Navigationen waren:

bfcache-Quote	Anteil der Websites
unter 25 %	26,5 %
25 % bis unter 50 %	14,1 %
50 % und mehr	59,4 %

Im Median kamen 59 Prozent der Verlaufsnavigationen aus dem bfcache. Das beste Viertel erreichte 77 Prozent und mehr, das schwächste Viertel blieb unter 19 Prozent. Eine Quote von 100 Prozent ist unrealistisch, denn Browser verwerfen gespeicherte Seiten auch bei knappem Speicher oder wenn eine Seite lange im Hintergrund lag. Eine Quote weit unter dem Median deutet aber fast immer auf einen Blocker auf der Website selbst hin.

Cache-Control: no-store blockiert den bfcache am häufigsten

Ein Browser legt eine Seite nur dann im bfcache ab, wenn er sie später gefahrlos wiederherstellen kann. Einige Anweisungen und Funktionen einer Seite schließen das aus. Die häufigsten:

• Cache-Control: no-store im HTML. Viele Content-Management-Systeme und Shopsysteme senden diesen Header auf jeder Seite, oft nur, weil die Seite einen Warenkorb oder einen Login-Status enthalten könnte. Laut Chrome war dieser Header der größte einzelne Grund für verpasste bfcache-Treffer und betraf etwa 17 Prozent der Verlaufsnavigationen auf Mobilgeräten (Enabling bfcache for Cache-Control: no-store, Chrome for Developers, September 2025). Chrome lässt solche Seiten seit Frühjahr 2025 unter bestimmten Bedingungen in den bfcache, andere Browser schließen sie weiterhin aus. Am saubersten ist es trotzdem, no-store nur auf Seiten zu senden, die tatsächlich persönliche Daten zeigen.
• unload-Handler. Skripte, die beim Verlassen einer Seite laufen, oft aus älteren Analyse- oder Chat-Werkzeugen, blockierten in Chrome früher den bfcache. Chrome hat die Abschaffung des unload-Events inzwischen abgeschlossen, solche Handler feuern standardmäßig nicht mehr (Deprecating the unload event, Chrome for Developers, aktualisiert im Oktober 2026). Für Websites, die unload ausdrücklich wieder einschalten, und für andere Browser lohnt der Umstieg auf das Event pagehide weiterhin.
• Offene Verbindungen. Hat eine Seite beim Verlassen eine offene IndexedDB- oder WebRTC-Verbindung, kann der Browser sie nicht sicher aufbewahren. Offene WebSockets blockieren den bfcache in Chrome (seit Version 149) und Safari nicht mehr, in Firefox weiterhin. Abhilfe: Verbindungen bei pagehide schließen und bei pageshow wieder öffnen.
• Verweise zwischen Fenstern. Öffnet eine Seite per window.open() ein Fenster und steuert es weiter, kommt keine der beiden Seiten in den bfcache. Links mit target="_blank" erzeugen in aktuellen Browsern keinen solchen Verweis mehr, weil rel="noopener" dort Standard ist.

Die bfcache-Fähigkeit lässt sich in zwei Minuten testen

Die Chrome DevTools haben dafür einen eigenen Test: Im Bereich Application unter Back/forward cache navigiert ein Klick auf Test back/forward cache weg und wieder zurück und listet jeden Grund auf, der die Wiederherstellung verhindert hat (Test back/forward cache, Chrome for Developers). Lighthouse prüft dasselbe in der Diagnose Page prevented back/forward cache restoration, die nicht in den Performance-Score eingeht. Beide Tests prüfen eine einzelne Seite im Labor. Ob die Korrektur bei echten Besuchern wirkt, zeigen erst die Felddaten einige Wochen später.

Ein funktionierender bfcache hilft auch den Core Web Vitals. Eine wiederhergestellte Seite erscheint praktisch ohne Wartezeit, und der Chrome UX Report zählt jede Wiederherstellung als eigenen Seitenbesuch. Schnelle Wiederherstellungen verbessern also die Feldwerte. Wie die Felddaten zustande kommen, erklärt der Ratgeber zu den Core Web Vitals.

Die bfcache-Quote Ihrer Website prüfen

PerfDelta zeigt in jedem Report die bfcache-Quote Ihrer Domain aus echten Smartphone-Besuchen, neben dem Anteil der Zurück- und Vor-Navigationen und den Werten Ihrer Wettbewerber. Ein Verlauf Woche für Woche zeigt, ob eine Korrektur wirkt. Starten Sie mit einem kostenlosen Website Speed Test oder vergleichen Sie bis zu fünf Websites direkt im Core Web Vitals Benchmark.

Methode und Grenzen dieser Auswertung

• Daten: 2.003 Smartphone-Datensätze aus dem Chrome UX Report, je Origin einmal gezählt, Datenzeitraum bis 26. Oktober 2026, abgerufen von PerfDelta. Jeder Datensatz fasst echte Chrome-Besuche aus einem gleitenden Zeitraum von 28 Tagen zusammen.
• Auswahl: die 1.425 Websites, bei denen Zurück- und Vor-Navigationen mindestens zwei Prozent der Seitenaufrufe ausmachten. Darunter stützt sich die Quote auf zu wenige Navigationen.
• Quote: Navigationen vom Typ back_forward_cache geteilt durch alle Zurück- und Vor-Navigationen mit und ohne bfcache.
• Nur Chrome: Der Chrome UX Report enthält keine Daten aus Safari oder Firefox, die eigene bfcache-Umsetzungen haben.
• Stichprobe: Die Websites stammen aus Tests und Studien von PerfDelta, größere Marken sind überrepräsentiert. Die Ergebnisse sind nicht repräsentativ für das gesamte Web. Weitere Zahlen aus unseren Messungen finden Sie in den Website Speed Statistiken.