Jede Zurück-Navigation im Web ist ein Moment, in dem Nutzer eine Seite erwarten, die sie bereits kennen -- und trotzdem warten muessen, wenn der Browser sie komplett neu laedt. Genau hier setzt der Back-Forward-Cache an, kurz bfcache: Verlaesst ein Nutzer eine Seite, friert der Browser ihren vollständigen Zustand im Speicher ein und stellt ihn beim Klick auf Zurück oder Vorwaerts fast verzoegerungsfrei wieder her, statt die gesamte Ladekette erneut zu durchlaufen. Der Hebel ist gross, denn auf dem Desktop ist rund jede zehnte (Chrome for Developers) und auf Mobilgeraeten rund jede fuenfte (Chrome for Developers) Navigation eine Zurück- oder Vorwaerts-Bewegung, und im Maerz-2024-Datensatz des Chrome UX Report wurden bereits 6,77 Prozent (Chrome UX Report) aller Seitenaufrufe direkt aus dem bfcache bedient. 2026 ist das Thema besonders aktuell, weil Chrome den bfcache im Fruehjahr 2025 auch für Seiten mit dem Header Cache-Control: no-store auf 100 Prozent (Chrome for Developers) der Nutzer ausgerollt und mit der notRestoredReasons-API ein Diagnosewerkzeug ergaenzt hat. Dieser Beitrag erklärt, wie der bfcache funktioniert, welche Sperren die Wiederherstellung verhindern, wie man die Eignung in den DevTools testet und warum eine gezielte Frontend-Optimierung hier die Feld-Metriken hebt -- inklusive des Bezugs zu den Core Web Vitals 2026.
Das Wichtigste in Kürze
- Der Back-Forward-Cache friert beim Verlassen einer Seite deren kompletten Zustand -- DOM-Baum, JavaScript-Heap und Scroll-Position -- im Speicher ein und stellt ihn beim Zurueck- oder Vorwaerts-Klick fast verzoegerungsfrei wieder her, statt die Seite neu zu laden.
- Weil auf dem Desktop rund jede zehnte und auf Mobilgeraeten rund jede fuenfte Navigation eine Zurueck- oder Vorwaerts-Bewegung ist, hebt eine hohe Trefferquote die im Feld gemessenen Metriken einer Domain spuerbar.
- Typische Blocker sind veraltete unload-Handler, offene WebSocket-, WebRTC- oder WebTransport-Verbindungen, ein nicht zurueckgesetzter window.opener und -- eingeschraenkt -- der Header Cache-Control: no-store.
- Seit dem vollstaendigen Rollout im Fruehjahr 2025 laesst Chrome auch Seiten mit Cache-Control: no-store in den bfcache, solange keine Cookie-Aenderung oder sensible Verarbeitung dagegen spricht.
- Die Eignung laesst sich im Panel Back-Forward-Cache der DevTools testen und ueber die notRestoredReasons-API im Feld diagnostizieren -- die Grundlage, um Blocker gezielt zu entfernen.
Was der Back-Forward-Cache ist
Um den Nutzen zu verstehen, hilft der Vergleich mit einer normalen Navigation. Klickt ein Nutzer ohne bfcache auf Zurück, beginnt der Browser die komplette Arbeit von vorn: Verbindung aufbauen, HTML laden, darin CSS, Schriften, Bilder und Skripte entdecken, diese laden, JavaScript ausfuehren und die Seite rendern. Der bfcache umgeht das, indem er beim Verlassen einen vollständigen Schnappschuss der Seite behaelt -- den aufgebauten DOM-Baum, den JavaScript-Heap und sogar die Scroll-Position. Kehrt der Nutzer zurück, tauscht der Browser diesen eingefrorenen Zustand einfach wieder ein. Anders als ein klassischer HTTP-Cache, der einzelne Dateien vorhaelt, konserviert der bfcache die ganze, bereits fertig gerenderte Seite im Arbeitsspeicher. Das verwandte Prinzip, eine Folgeseite im Voraus vorzubereiten, beschreibt unser Beitrag zu den Speculation Rules für Instant-Navigation; der bfcache kuemmert sich dagegen um den Weg zurück.
Damit Seiten den bfcache sauber nutzen, gibt es zwei zentrale Ereignisse. Das Ereignis pagehide feuert, wenn die Seite verlassen und -- falls möglich -- in den bfcache gelegt wird; das Ereignis pageshow feuert bei jedem Anzeigen, also sowohl beim ersten Laden als auch bei der Wiederherstellung. Ob eine Seite frisch geladen oder aus dem Cache zurückgeholt wurde, verraet die Eigenschaft event.persisted: Ist sie true, kam die Seite aus dem bfcache (MDN Web Docs). Genau hier liegt eine häufige Fehlerquelle -- und zugleich der Ansatzpunkt, um dynamische Inhalte nach einer Wiederherstellung gezielt zu aktualisieren.
pageshow und persisted richtig nutzen
Warum bfcache die Feld-Metriken hebt
Der bfcache wirkt doppelt: Er verbessert das unmittelbar erlebte Tempo und hebt zugleich die im Feld gemessenen Werte. Weil eine Wiederherstellung praktisch ohne Ladezeit auskommt, zaehlt sie in den Felddaten als einer der schnellsten Seitenaufrufe überhaupt. Der Chrome UX Report weist seit dem Datensatz vom Maerz 2024 einen eigenen Navigationstyp für den bfcache aus, und die Auswertung zeigt eine starke statistische Korrelation zwischen bfcache-Navigationen und einem sofortigen Largest Contentful Paint (Chrome for Developers). Für stark frequentierte Seiten mit vielen Zurück-Bewegungen kann das den Anteil bestandener Core Web Vitals spuerbar heben, ohne dass sich am eigentlichen Seitenaufbau etwas aendert. Wie Labor- und Felddaten hier zusammenspielen, vertieft unser Beitrag zu RUM gegenüber CrUX-Felddaten.
Der geschäftliche Effekt ist belegt. In einem kontrollierten Test steigerte Yahoo! JAPAN News seinen Anzeigenumsatz auf Mobilgeraeten um 9,0 Prozent (web.dev) und die Seitenaufrufe um 2,26 Prozent (web.dev), nachdem der bfcache aktiviert war; die Trefferquote stieg dabei von 0,04 auf 54,07 Prozent (web.dev). Der Grund ist einfach: Wer schneller zurück zur Ergebnisliste springt, sieht mehr Seiten und bricht seltener ab. Der bfcache verbessert ausserdem nicht nur die Ladezeit, sondern häufig auch die Reaktionsfaehigkeit direkt nach der Navigation, was der Interaction to Next Paint zugutekommt.
Eine Seite, die beim Zurück-Klick sofort da ist, fuehlt sich nicht nur schneller an -- sie verlaengert die Sitzung, weil der Weg zurück zur Übersicht keine Huerde mehr ist.
Was die Wiederherstellung blockiert
So wirkungsvoll der bfcache ist, er greift nur, wenn eine Seite dafür geeignet ist. Bestimmte Muster zwingen den Browser, die Seite stattdessen komplett zu verwerfen und neu zu laden. Der historisch häufigste Blocker ist der unload-Handler: Registriert eine Seite ein unload-Ereignis, gilt sie in Firefox und im Chrome-Desktop als nicht cachefaehig (web.dev). Google hat begonnen, das unload-Ereignis ganz zu verabschieden, weil es unzuverlaessig ist und den bfcache verhindert -- moderne Alternativen sind pagehide und das visibilitychange-Ereignis. Auch ein beforeunload-Handler war lange ein Problem und sollte nur bedingt und nicht dauerhaft registriert werden.
| Blocker | Warum bfcache aussetzt | Saubere Loesung |
|---|---|---|
| unload-Handler | gilt als nicht cachefaehig, wird abgekuendigt | auf pagehide und visibilitychange umstellen |
| offene WebSocket / WebRTC / WebTransport | aktive Verbindung uebersteht das Einfrieren nicht | Verbindung in pagehide schliessen, in pageshow neu aufbauen |
| laufender fetch oder XMLHttpRequest | die Antwort wuerde ins Leere laufen | Anfragen vor dem Verlassen abschliessen oder abbrechen |
| window.opener nicht null | der Verweis auf ein anderes Fenster blockiert | ausgehende Links mit rel=noopener oeffnen |
| Cache-Control: no-store | nur eingeschraenkt zulaessig, Raeumung bei Cookie-Aenderung | Header pruefen, no-store nur setzen, wo noetig |
Der Umgang mit diesen Sperren wird schrittweise besser. Offene WebSocket-Verbindungen etwa blockierten den bfcache lange in fast allen Browsern; seit Chrome 149 (web.dev) wird eine Seite mit offener WebSocket-Verbindung unter bestimmten Bedingungen dennoch gecacht und die Verbindung beim Verlassen pausiert. Verlaesslich bleibt es dennoch, offene Verbindungen im pagehide-Ereignis selbst zu schließen und im pageshow-Ereignis neu aufzubauen. Viele dieser Blocker stammen ohnehin aus eingebundenen Skripten Dritter, weshalb ein schlanker Bestand hilft, wie unser Beitrag zum Entschlacken von Third-Party-Skripten zeigt. Auch eine schlanke Seitenstruktur wirkt unterstützend -- wie man die DOM-Größe reduziert, beschreibt der zugehoerige Beitrag.
Das unload-Ereignis ist ein Auslaufmodell
Cache-Control: no-store -- der Durchbruch von 2025
Lange galt eine feste Regel: Seiten mit dem Header Cache-Control: no-store landeten nie im bfcache. Das betraf viele eingeloggte Bereiche, Warenkoerbe und andere Seiten mit persoenlichen Daten, die diesen Header aus Vorsicht setzen -- obwohl die meisten Zurück-Navigationen dort gar keine sensiblen Daten preisgeben. Genau dieser Header ist der mit Abstand größte einzelne Blocker: Er verhinderte den bfcache bei rund 17 Prozent (Chrome for Developers) der History-Navigationen auf Mobilgeraeten und 7 Prozent (Chrome for Developers) auf dem Desktop.
Chrome hat das ab Version 116 schrittweise geaendert und den Rollout über Maerz und April 2025 (Chrome for Developers) auf 100 Prozent (Chrome for Developers) der Nutzer abgeschlossen; als Browser-Feature ist der Schritt im Chrome Platform Status dokumentiert (Chrome Platform Status). Seither duerfen auch no-store-Seiten in den bfcache -- allerdings mit Sicherheitsnetz. Aendert sich ein Cookie oder eine andere Berechtigung, während die Seite im Cache liegt, raeumt Chrome sie sofort und laedt beim Zurück-Klick frisch, damit niemand veraltete oder fremde Daten sieht. Zusätzlich ist die Verweildauer solcher Seiten im Cache auf 3 Minuten (Chrome for Developers) verkuerzt, gegenüber 10 Minuten (Chrome for Developers) bei gewoehnlichen Seiten. Wichtig: Diese Lockerung gilt zunächst nur für Chrome; andere Browser koennen no-store weiterhin als Blocker behandeln.
no-store bewusst setzen
Eignung testen und diagnostizieren
Ob eine Seite bfcache-tauglich ist, laesst sich direkt prüfen. In den Chrome DevTools gibt es unter Application ein eigenes Panel Back-Forward-Cache mit der Schaltflaeche Test durchfuehren: Sie navigiert die aktuelle Seite weg und wieder zurück und listet anschließend jeden Grund auf, der die Wiederherstellung verhindert haette (Chrome for Developers). Das ist der schnellste Weg, um im Labor gezielt Blocker zu finden und nach jeder Aenderung erneut zu prüfen.
window.addEventListener("pageshow", (event) => {
if (event.persisted) {
// Seite kam aus dem bfcache -- nur dynamische Werte auffrischen
refreshCartCount();
}
});
window.addEventListener("pagehide", () => {
// offene Verbindung schliessen, damit die Seite cachefaehig bleibt
socket?.close();
});Für die Praxis noch wichtiger sind die Felddaten, denn im Labor lassen sich nicht alle Situationen nachstellen. Dafür gibt es die notRestoredReasons-API, die seit Chrome 123 (Chrome for Developers) ausgeliefert wird. Sie haengt an der Klasse PerformanceNavigationTiming und meldet nach einer Navigation, ob die Seite aus dem bfcache kam und, falls nicht, welche Rahmen aus welchem Grund blockiert haben (MDN Web Docs). So sieht man an echten Nutzerdaten, welcher Blocker tatsaechlich zuschlaegt, statt im Labor zu raten.
const [entry] = performance.getEntriesByType("navigation");
if (entry && entry.notRestoredReasons) {
console.log(entry.notRestoredReasons);
// meldet blockierende Gruende, z. B. "unload-handler" oder "websocket"
}- Im DevTools-Panel Back-Forward-Cache nach jeder Aenderung testen
- unload-Handler entfernen und durch pagehide oder visibilitychange ersetzen
- Offene WebSocket-, WebRTC- oder WebTransport-Verbindungen in pagehide schliessen
- window.opener durch rel=noopener auf ausgehenden Links neutralisieren
- Cache-Control: no-store nur setzen, wo es zwingend noetig ist
- Ueber die notRestoredReasons-API im Feld pruefen, welche Blocker real auftreten
Die Shop-Reise: von der Kategorie zum Produkt und zurück
Kaum ein Muster profitiert so unmittelbar vom bfcache wie die typische Shop-Reise. Nutzer oeffnen eine Kategorieseite, klicken sich in ein Produkt, springen zurück zur Liste, oeffnen das naechste Produkt, springen wieder zurück -- und das oft mehrfach in Folge. Ohne bfcache laedt die Kategorieseite bei jedem Zurück-Klick neu, samt Filtern, Sortierung und Scroll-Position, die dabei verloren geht. Mit bfcache erscheint exakt der vorherige Zustand sofort: dieselbe Scroll-Hoehe, dieselben aktiven Filter, kein Flackern. Weil auf Mobilgeraeten rund jede fuenfte (Chrome for Developers) Navigation eine solche Zurück-Bewegung ist, entscheidet die bfcache-Eignung der Kategorievorlage hier über einen grossen Teil des erlebten Tempos. Wie stark schnelle Navigation auf Conversion und Umsatz wirkt, vertieft unser Beitrag zum Zusammenhang von Ladezeit, Conversion-Rate und Umsatz.
Der Kern in einem Satz
Wie wir die bfcache-Eignung herstellen
In der Praxis gehen wir beim bfcache wie bei jeder Frontend-Massnahme vor: erst messen, dann handeln. Zunächst prüfen wir in einer Performance-Analyse jede zentrale Vorlage -- Startseite, Kategorie, Produkt, Warenkorb, Login-Bereich -- im DevTools-Panel und über die notRestoredReasons-API auf ihre bfcache-Eignung. Dann entfernen wir die gefundenen Blocker: Wir ersetzen veraltete unload-Handler durch pagehide, schließen offene Verbindungen sauber, neutralisieren window.opener und prüfen jeden Cache-Control: no-store-Header auf seine Berechtigung. Anschließend sorgen wir dafür, dass dynamische Werte wie Warenkorb oder Login-Status nach einer Wiederherstellung über event.persisted gezielt aktualisiert werden. Zum Schluss messen wir die Wirkung in den Felddaten der Core Web Vitals, statt uns auf Laborwerte allein zu verlassen. Der bfcache ist für uns Teil eines größeren Leistungsspektrums rund um Ladezeit und Navigation.
Der Reiz des bfcache liegt darin, dass er an einem Moment ansetzt, den Nutzer als selbstverstaendlich empfinden: dem Weg zurück. Eine Seite, die beim Zurück-Klick schon da ist, wirkt mueheloser als jede noch so gut optimierte Ladeanimation. Weil der bfcache in modernen Browsern ohnehin eingebaut ist -- in Chrome seit Version 96 (web.dev) und in Firefox und Safari schon laenger --, kostet seine Nutzung keinen Neubau, sondern nur das Entfernen der Blocker. Genau das prüfen und erledigen wir im Rahmen der Frontend-Optimierung, damit Zurück-Navigationen auf Ihrer Website oder in Ihrem Shop sofort sind. Wie sich Textkompression zusätzlich auf die Ladezeit auswirkt, zeigt unser Beitrag zu Brotli und Zstandard.
Quellen und Studien