Back/Forward Cache (bfcache) optimieren

1. Was ist der Back/Forward Cache

Der Back/Forward Cache, kurz bfcache, ist eine Browser-Optimierung, die eine komplette Seite samt JavaScript-Heap, DOM-Baum, Scroll-Position und laufenden Timern im Arbeitsspeicher einfriert, statt sie beim Verlassen vollständig zu zerstören. Navigiert der Nutzer anschliessend per Zurück- oder Vorwärts-Button, wird die eingefrorene Seite einfach wieder aktiviert, ganz ohne erneuten Netzwerk-Request, ohne erneutes Parsen des HTML und ohne erneute Ausführung von Skripten.

Diese Technik unterscheidet sich fundamental vom regulären HTTP-Cache, der lediglich einzelne Ressourcen wie Bilder oder Stylesheets zwischenspeichert, aber keinen laufenden JavaScript-Zustand erhält. Der bfcache hingegen bewahrt den kompletten Ausführungszustand der Seite, weshalb beispielsweise ein halb ausgefülltes Formular oder eine geöffnete Dropdown-Auswahl bei Rückkehr exakt so erscheint, wie sie beim Verlassen zurückgelassen wurde. Für Nutzer, die häufig zwischen einer Produktliste und mehreren Detailseiten hin- und herwechseln, summiert sich dieser Effekt über eine ganze Sitzung hinweg zu einer spürbar flüssigeren Nutzung des gesamten Onlineshops.

2. Funktionsweise: pageshow und pagehide statt unload

Damit eine Seite sauber in den bfcache aufgenommen werden kann, muss sie über die Events pagehide und pageshow mit dem Zustandswechsel umgehen, statt sich auf die älteren Events unload oder beforeunload zu verlassen. Beim Verlassen der Seite feuert pagehide, und das Attribut event.persisted zeigt an, ob die Seite tatsächlich eingefroren statt zerstört wurde.

Kehrt der Nutzer zur Seite zurück, feuert pageshow erneut, und auch hier signalisiert event.persisted === true, dass es sich um eine Wiederherstellung aus dem bfcache handelt und nicht um einen frischen Seitenaufbau. Anwendungen, die auf diesen Zustand reagieren müssen, etwa um Live-Daten wie Lagerbestände zu aktualisieren, sollten genau an dieser Stelle einen gezielten Refresh auslösen.

3. Code-Beispiel: Korrektes Event-Handling für bfcache-Kompatibilität

Der häufigste Fehler, der den bfcache blockiert, ist die Verwendung eines unload-Event-Listeners, selbst wenn dieser inhaltlich leer ist oder nur für veraltete Analytics-Zwecke registriert wurde. Chrome behandelt jeden registrierten unload-Listener als potenziellen Blocker und verweigert dann den bfcache für die betroffene Seite komplett.

Die saubere Alternative ist, jegliche Aufräumlogik an pagehide zu binden und dabei zwischen einer echten Zerstörung und einem Einfrieren für den bfcache zu unterscheiden, wie im folgenden Beispiel gezeigt.

// Falsch: blockiert den bfcache in Chrome zuverlaessig
window.addEventListener('unload', () => {
  navigator.sendBeacon('/analytics/leave', payload);
});

// Richtig: bfcache-kompatibel über pagehide
window.addEventListener('pagehide', (event) => {
  if (!event.persisted) {
    // Seite wird wirklich zerstört, nicht nur eingefroren
    navigator.sendBeacon('/analytics/leave', payload);
  }
});

// Bei Wiederherstellung aus dem bfcache reagieren
window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    aktualisiereLagerbestand();
  }
});

4. Häufige bfcache-Blocker im Überblick

Neben dem unload-Listener zählen offene WebSocket-, WebRTC- oder EventSource-Verbindungen zu den häufigsten Blockern, da der Browser eine eingefrorene Seite mit aktiver Netzwerkverbindung nicht sicher zwischenspeichern kann. Ebenso verhindert der Response-Header Cache-Control: no-store auf dem Hauptdokument grundsätzlich jede bfcache-Nutzung für diese Seite, unabhängig vom sonstigen JavaScript-Verhalten.

Weitere häufige Ursachen sind offene IndexedDB-Transaktionen zum Zeitpunkt des Verlassens, aktive Anfragen für Benachrichtigungsberechtigungen oder Mikrofon- und Kamerazugriff, sowie bestimmte, vom Browser als nicht sicher freigebbar eingestufte Plugin-Instanzen. Jeder dieser Faktoren kann für sich allein bereits ausreichen, um die gesamte Seite von der bfcache-Nutzung auszuschliessen.

5. Chrome DevTools bfcache-Test-Tool nutzen

Chrome bietet im Reiter Application unter dem Abschnitt Back/forward cache ein dediziertes Testwerkzeug, das per Knopfdruck simuliert, ob die aktuell geöffnete Seite für den bfcache infrage kommt. Nach dem Test listet das Tool alle konkreten Blockierungsgründe einzeln auf, unterteilt in Kategorien wie unterstützt, in der Erprobung befindlich oder derzeit nicht unterstützt.

Dieses Werkzeug ist deutlich zuverlässiger als manuelles Ausprobieren per Zurück-Button, da es auch subtile Blocker wie eine im Hintergrund aktive Push-Verbindung oder eine ausstehende Berechtigungsanfrage aufdeckt, die im normalen Testablauf leicht übersehen werden. Es empfiehlt sich, diesen Test routinemäßig für jeden neuen Seitentyp nach größeren Frontend-Änderungen erneut durchzuführen.

6. Messbarer Performance-Gewinn bei erfolgreicher Nutzung

Wird eine Seite erfolgreich aus dem bfcache wiederhergestellt, liegt die Zeit bis zur Interaktionsfähigkeit typischerweise im niedrigen zweistelligen Millisekundenbereich, während ein vollständiger Neuaufbau derselben Seite je nach Komplexität mehrere hundert Millisekunden bis wenige Sekunden dauern kann. Dieser Unterschied fällt besonders bei mobilen Verbindungen mit hoher Latenz oder eingeschränkter Bandbreite deutlich stärker ins Gewicht als auf dem Desktop mit schneller Standleitung.

Chrome hat in eigenen Untersuchungen über alle Navigationsvorgänge hinweg gezeigt, dass ein erheblicher Anteil aller Zurück- und Vorwärts-Navigationen historisch am bfcache vorbeilief, obwohl genau diese Navigationsmuster besonders häufig vorkommen. Jede zusätzliche Seite, die bfcache-fähig gemacht wird, reduziert somit nicht nur die individuelle Ladezeit, sondern auch die Serverlast, da keine erneute Anfrage an den Server gestellt werden muss.

7. Zusammenspiel mit anderen Browser-APIs

Manche Browser-APIs erfordern besondere Sorgfalt im Zusammenspiel mit dem bfcache: Eine laufende IndexedDB-Transaktion muss vor dem Verlassen der Seite abgeschlossen sein, da offene Transaktionen den bfcache blockieren können, und ausstehende Fetch-Anfragen sollten idealerweise beendet oder zumindest sauber abbrechbar sein. Auch der Media-Session-API-Zustand und aktive WebLocks können je nach Browser-Version Einfluss auf die bfcache-Fähigkeit haben.

Für Formulare mit automatischem Zwischenspeichern empfiehlt es sich, den Speichervorgang an pagehide statt an beforeunload zu binden, da beforeunload-Listener in neueren Chrome-Versionen zwar nicht mehr grundsätzlich blockieren, aber weiterhin als Risikofaktor gelten und die bfcache-Wiederherstellung in manchen Fällen verzögern können. Eine konsequente Umstellung auf die moderneren Lifecycle-Events zahlt sich hier langfristig aus.

8. Best Practices für klassische Multi-Page-Anwendungen

Für klassische, serverseitig gerenderte Mehrseiten-Websites, wie sie im E-Commerce-Umfeld üblich sind, lohnt sich eine systematische Bestandsaufnahme aller eingebundenen Drittanbieter-Skripte, da Tracking- und Chat-Widgets häufig unbemerkt unload-Listener oder dauerhafte WebSocket-Verbindungen registrieren. Eine zentrale Übersicht, welches Skript welchen bfcache-Blocker verursacht, erleichtert die gezielte Behebung erheblich.

Zusätzlich sollte jede Seite, deren Inhalt sich bei Rückkehr verändert haben könnte, etwa ein Warenkorb mit aktuellem Preis oder Lagerbestand, über den pageshow-Handler gezielt die betroffenen Bereiche aktualisieren, statt die gesamte Seite neu zu laden. So bleibt der Geschwindigkeitsvorteil des bfcache erhalten, während die Aktualität der angezeigten Daten trotzdem gewährleistet ist. Ein sinnvoller zusätzlicher Schritt ist, sämtliche eingebundenen Drittanbieter-Skripte regelmäßig neu zu prüfen, da deren Anbieter gelegentlich neue Funktionen wie Push-Benachrichtigungen ergänzen, die unbemerkt neue bfcache-Blocker einführen können.

9. Zusammenfassung

Der Back/Forward Cache gehört zu den wirkungsvollsten, gleichzeitig aber am häufigsten unbeabsichtigt blockierten Performance-Optimierungen moderner Browser, da bereits ein einzelner vergessener unload-Listener oder eine offene WebSocket-Verbindung den gesamten Effekt zunichtemachen kann. Eine regelmäßige Prüfung mit dem Chrome DevTools bfcache-Test-Tool sollte deshalb fester Bestandteil jedes Performance-Reviews sein, insbesondere nach der Einbindung neuer Drittanbieter-Skripte oder größerer Änderungen an der Checkout-Strecke.

Wer die häufigsten Blocker konsequent vermeidet und Lifecycle-Events wie pagehide und pageshow korrekt einsetzt, erhält im Gegenzug eine spürbar schnellere Navigation für alle Nutzer, die im Verlauf ihrer Sitzung zwischen Seiten hin- und herwechseln, was gerade im Bereich Kategorie- und Produktseiten im Onlinehandel ein häufiges Navigationsmuster darstellt.

10. Zusammenfassung

11. FAQ: Back/Forward Cache