Was ist der bfcache?

Der bfcache ist eine Optimierung, die zum Browser gehört, nicht zu deinem Server oder deinem Code. Wenn jemand eine Seite über einen Link oder eine neue URL verlässt, zerstört der Browser diesen Tab nicht zwangsläufig: Er kann die Ausführung von JavaScript pausieren und den kompletten Zustand des Dokuments im Arbeitsspeicher behalten. Kehrt diese Person später über die Zurück- oder Vorwärts-Taste zurück, stellt der Browser die Seite exakt so wieder her, wie sie war, ohne auch nur eine einzige Ressource neu herunterzuladen.

Google beziffert, dass eine von zehn Navigationen am Desktop und eine von fünf auf Mobilgeräten von diesem Typ sind, also vor oder zurück. Das ist ein Anteil, der selten gemessen wird, weil Auditierungswerkzeuge sich meist nur auf den ersten Seitenaufruf konzentrieren, denjenigen, der die meisten Berichte zu Core Web Vitals speist. Wer nur diese erste Ladezeit misst, sieht diesen ganzen Teil des tatsächlichen Nutzererlebnisses gar nicht.

Der bfcache sollte nicht mit anderen Cache-Formen verwechselt werden. Der HTTP-Cache speichert einzelne Dateien wie Bilder, Stylesheets oder Skripte, um sie nicht erneut herunterzuladen. Der bfcache speichert die ganze Seite, samt ihrem JavaScript-Zustand, bereit, ohne irgendetwas von Grund auf neu auszuführen. Deshalb wirkt eine Seite mit aktivem bfcache beim Zurückgehen wie sofort da, während ein vollständiges Neuladen, selbst gut optimiert, immer mindestens eine Netzwerkanfrage bedeutet, mit allem, was an Wartezeit und Serverlast dazugehört.

Der Browser entscheidet in dem Moment, in dem der Nutzer eine Seite verlässt, ob sie für den bfcache geeignet ist, anhand einer Liste technischer Bedingungen. Erfüllt die Seite sie, wird der Rendering-Prozess im Speicher eingefroren, statt zerstört zu werden. Die JavaScript-Ausführung stoppt, Timer laufen nicht mehr weiter, und die Seite wartet dort, unverändert, bis der Nutzer zurückkehrt oder der Browser diesen Speicher für etwas anderes braucht. Aus Sicht des Servers findet dabei schlicht nichts statt, kein einziger Log-Eintrag entsteht für diesen Besuch.

Es gibt Faktoren, die dieses Einfrieren verhindern, und web.dev dokumentiert sie genau. Der wichtigste ist ein Handler für das unload-Ereignis: Jede Seite, die dieses Ereignis noch nutzt, um Code auszuführen, wird in Chrome und Firefox ausnahmslos vom bfcache ausgeschlossen. Der Header Cache-Control: no-store in der Server-Antwort erzeugt denselben Effekt, weil er dem Browser ausdrücklich sagt, nichts von dieser Seite zu behalten. Ebenso blockieren offene Verbindungen beim Verlassen den bfcache, etwa eine laufende IndexedDB-Transaktion, eine unaufgelöste fetch- oder XMLHttpRequest-Anfrage, ein aktiver WebSocket oder eine WebRTC-Verbindung, sowie jede window.opener-Referenz, die den ursprünglichen Tab mit dem neuen verknüpft lässt.

Ob eine konkrete Seite in den bfcache aufgenommen wird oder nicht, zeigt ein eigener Test in Chrome DevTools, im Reiter Application unter Back-forward cache, der die tatsächliche Prüfung ausführt und bei einer Blockade den genauen Grund liefert, konkret genug, um ihn direkt an die Entwicklung weiterzugeben, statt nur zu wissen, dass etwas nicht funktioniert. Ein weiterer, programmatischer Messweg ist die Navigation Timing API: Sie gibt den Navigationstyp über performance.getEntriesByType('navigation')[0].type aus, mit dem Wert back_forward, wenn die Seite aus dem bfcache kam, wodurch sich dieser Anteil zuverlässig in jedem eigenen Analytics-System dauerhaft erfassen lässt.

Der bfcache ändert keine einzige Zeile am Inhalt der Seite, verändert aber vollständig, wie ihre Geschwindigkeit bei einem keineswegs kleinen Teil der Besuche wahrgenommen wird: zwischen einer von zehn und einer von fünf Navigationen, laut den im vorigen Abschnitt genannten Daten. Wird eine Seite aus dem bfcache wiederhergestellt, fallen ihre LCP- und FCP-Werte praktisch mit dem Moment der Wiederherstellung zusammen, weil es weder ein Herunterladen noch ein Rendering von Grund auf gibt. Ein Blick in die Back-forward-cache-Prüfung der Chrome DevTools reicht oft aus, um diesen Zusammenhang in wenigen Minuten zu bestätigen.

Das erklärt ein Muster, das jeden verwirrt, der Performance auditiert, ohne den bfcache zu kennen: Eine Website, an der scheinbar nichts geändert wurde, verbessert ihre Geschwindigkeitswerte von einem Tag auf den anderen, oder verschlechtert sie nach einem Deployment, das unbemerkt einen unload-Handler oder einen no-store-Header eingeführt hat. Die Ursache liegt nicht im sichtbaren Code, sondern darin, ob diese Seite weiterhin für den bfcache geeignet ist oder es nicht mehr ist.

Für ein Team, das von der wahrgenommenen Performance abhängt, etwa ein Shop mit Navigation vom Katalog zum Produkt und zurück oder ein Medium mit Artikellisten, ist der bfcache kein nebensächliches technisches Detail. Er ist der Unterschied, ob sich Zurückgehen sofort anfühlt oder wie ein weiteres Laden, und dieser Unterschied macht sich in jeder Sitzung bemerkbar, die mindestens eine Rückwärtsnavigation enthält, also in einem guten Teil des gesamten Nutzerverhaltens auf der Seite.

• Entferne jeden Handler für das unload-Ereignis und ersetze ihn durch pagehide oder visibilitychange, die mit dem bfcache kompatibel sind.
• Prüfe, dass keine HTML-Antwort Cache-Control: no-store trägt, außer die Seite enthält tatsächlich sensible Daten, die nicht im Speicher bleiben dürfen.
• Schließe offene Verbindungen wie WebSocket, WebRTC oder ausstehende fetch-Anfragen im pagehide-Ereignis, statt sie beim Verlassen der Seite aktiv zu lassen.
• Prüfe jede wichtige Vorlage einzeln mit dem Back-forward-cache-Test in Chrome DevTools, nicht nur die Startseite allein.
• Vermeide einen zugänglichen window.opener beim Öffnen von Links in einem neuen Tab; ergänze diese Links konsequent um rel="noopener".
• Miss den tatsächlichen Anteil an back_forward-Navigationen auf deiner Website mit der Navigation Timing API, bevor du annimmst, das Problem sei nebensächlich.

• Annehmen, die wahrgenommene Langsamkeit beim Zurückgehen sei grundsätzlich ein Serverproblem, während die eigentliche Blockade im eigenen Client-Code liegt und dort gesucht werden muss.
• Cache-Control: no-store vorsorglich auf ganz normale Seiten setzen, ohne wirklich zu prüfen, ob dort tatsächlich Daten stehen, die nicht gespeichert werden dürfen.
• Einen unload-Handler aus einem alten Analytics-Skript stehen lassen, den niemand seit der Installation überprüft hat.
• Den HTTP-Cache einzelner Dateien mit dem bfcache der gesamten Seite verwechseln und annehmen, die Optimierung des einen decke auch das andere ab.