Der Zurück-Button lädt nicht immer neu: bfcache nach `no-store` richtig testen

Der Zurück-Button wirkt banal: Seite verlassen, zurückklicken, Seite wieder laden. Genau dieses mentale Modell ist für moderne Browser aber oft falsch.

Browser können eine Seite im Back/Forward Cache, kurz bfcache, als vollständigen Snapshot im Speicher behalten. Beim Zurück- oder Vorwärtsnavigieren wird dann nicht zwingend neu vom Server geladen. DOM, JavaScript-Heap und Seitenzustand können wieder erscheinen, während die JavaScript-Ausführung beim Verlassen pausiert und beim Wiederherstellen fortgesetzt wird.

Das ist hervorragend für Performance. Es kann aber überraschende Zustände erzeugen, wenn eine Anwendung davon ausgeht, dass jede Rückkehr einen frischen Request, einen neuen Auth-Check, ein neues Analytics-Event oder eine erneute Datenabfrage auslöst.

Und seit 2025 ist eine verbreitete Annahme noch unsicherer: Cache-Control: no-store ist in Chrome nicht mehr automatisch gleichbedeutend mit „diese Seite kommt niemals aus dem bfcache zurück“.

Was Chrome geändert hat

Chrome hat die Nutzung des bfcache für bestimmte Seiten mit Cache-Control: no-store schrittweise erweitert. Laut Chrome for Developers wurde der Rollout im März und April 2025 auf 100 Prozent der Nutzer abgeschlossen.

Das ist kein Ignorieren von Sicherheitsanforderungen. Chrome verwendet zusätzliche Schutzregeln. Unter anderem werden no-store-Seiten aus dem bfcache entfernt, wenn sich Cookies oder andere Autorisierungsmechanismen ändern. Bestimmte APIs wie WebSocket, WebTransport oder WebRTC verhindern bei solchen Seiten weiterhin die Nutzung. Außerdem ist die Verweildauer für no-store-Seiten im bfcache verkürzt.

Trotzdem ändert sich damit eine wichtige technische Erwartung:

Der HTTP-Cache und der bfcache sind zwei verschiedene Mechanismen.

Cache-Control: no-store steuert primär die Speicherung von HTTP-Antworten. Der bfcache speichert dagegen den Zustand einer bereits geladenen Seite im Speicher. Wer no-store als universellen „Zurück-Button-Schutz“ eingesetzt hat, sollte diesen Zustand heute ausdrücklich testen.

Warum das für normale Websites relevant ist

Das Thema klingt zunächst nach Browser-Nerdwissen. In der Praxis betrifft es sehr alltägliche Nutzerwege.

1. Logout und geschützte Bereiche

Ein Nutzer öffnet sein Konto, navigiert zu einer anderen Seite, meldet sich in einem zweiten Tab ab und drückt anschließend im ersten Tab „Zurück“.

Die richtige Erwartung ist: Geschützte Daten dürfen nicht einfach wieder als gültiger Sitzungszustand behandelt werden.

Chrome hat für no-store-Seiten Schutzmechanismen rund um Cookie- und Autorisierungsänderungen eingebaut. Das ersetzt jedoch keinen Anwendungstest. Authentifizierung kann aus Cookies, Tokens, serverseitigen Sessions, clientseitigem State und Drittanbieter-SDKs bestehen. Entscheidend ist nicht nur, ob Chrome eine bestimmte Heuristik besitzt, sondern ob Ihr realer Logout-Pfad zuverlässig verhindert, dass eine wiederhergestellte Oberfläche als weiterhin autorisiert wirkt.

2. Stale Daten nach „Zurück“

Eine Preisübersicht, ein Warenkorb, eine Buchungsliste oder ein Admin-Dashboard kann beim Zurücknavigieren exakt den Zustand zeigen, den der Nutzer vor einer Minute verlassen hat.

Das ist manchmal ideal. Wer zu einer langen Artikelliste zurückkehrt, möchte oft genau an derselben Scrollposition landen.

Bei dynamischen Daten kann derselbe Effekt problematisch sein:

• Ein Auftrag wurde inzwischen storniert.
• Eine Berechtigung wurde entzogen.
• Ein Warenkorb wurde in einem anderen Tab verändert.
• Eine Verfügbarkeit ist nicht mehr aktuell.
• Ein Formularstatus suggeriert, dass eine Aktion noch möglich ist.
• Ein Dashboard zeigt Zahlen, die nach einer Mutation nicht mehr stimmen.

Die Lösung ist nicht, bfcache pauschal zu verhindern. Die Lösung ist, zwischen Zustand, der bewusst erhalten bleiben darf, und Zustand, der beim Wiedererscheinen validiert werden muss, zu unterscheiden.

3. Analytics zählt Rückkehrer nicht wie erwartet

Eine bfcache-Wiederherstellung ist kein normaler vollständiger Reload. Wer Pageviews ausschließlich an load, Framework-Mount oder Initialisierungscode koppelt, kann Back/Forward-Navigation anders messen als erwartet.

web.dev empfiehlt, pageshow zu berücksichtigen. Das Event wird auch bei einer Wiederherstellung aus dem bfcache ausgelöst. Über event.persisted lässt sich erkennen, ob die Seite aus einem Cache-Zustand zurückkam.

Für Analytics heißt das nicht automatisch: „Bei jedem pageshow ein neues Pageview feuern.“ Das hängt vom Messkonzept ab. Aber das Team sollte bewusst entscheiden, ob eine History-Navigation als neuer Seitenaufruf, als Navigation oder gar nicht gezählt wird.

4. Formulare wirken „halb abgeschickt“

Ein Nutzer füllt ein Formular aus, sendet es ab, gelangt zur Bestätigung und drückt danach zurück.

Je nach Implementierung kann die vorherige Seite mit alten Eingaben, deaktivierten Buttons, lokalen Validierungszuständen oder Erfolgsmeldungen wiederhergestellt werden. Besonders unangenehm wird es, wenn die Oberfläche erneut eine Aktion anbietet, obwohl der Server sie bereits verarbeitet hat.

Robuste Formulare brauchen deshalb serverseitige Idempotenz oder eindeutige Vorgangslogik dort, wo doppelte Aktionen Schaden verursachen können. Browsernavigation darf nicht die einzige Schutzschicht sein.

5. Single-Page-Apps überschätzen ihren Lifecycle

React, Vue, Next.js und ähnliche Stacks verleiten zu der Annahme, dass Komponenten beim Rückweg sauber neu gemountet werden. Ein bfcache-Restore kann jedoch den bestehenden Dokumentzustand wieder aufnehmen.

Code, der nur bei Initialisierung läuft, ist deshalb nicht automatisch ein geeigneter Ort für jede Aktualitätsprüfung. Kritischer Zustand sollte an den tatsächlichen Seiten-Lifecycle gekoppelt werden.

Der wichtigste Test: Was passiert wirklich beim Zurück-Button?

Ein bfcache-Audit sollte nicht nur prüfen, ob die Seite „cachebar“ ist. Es sollte zwei Fragen beantworten:

1. Kann die Seite von bfcache profitieren?
2. Bleiben Sicherheit, Datenaktualität, Messung und Geschäftslogik bei einer Wiederherstellung korrekt?

Beide Ziele gehören zusammen. Eine Seite künstlich aus dem bfcache zu werfen, nur weil die Anwendung ihren Lifecycle nicht beherrscht, verschenkt Performance. Blind auf bfcache zu optimieren, ohne kritische Zustände zu testen, erzeugt dagegen funktionale Risiken.

Acht praktische Prüffälle

1. Login → geschützte Seite → Logout → Zurück

Testen Sie diesen Ablauf im selben Tab und zusätzlich mit Logout in einem zweiten Tab. Prüfen Sie nicht nur die Oberfläche. Versuchen Sie eine echte geschützte Aktion auszuführen.

Erwartung: Keine veraltete UI darf eine gültige Berechtigung vortäuschen, und geschützte Requests müssen serverseitig weiterhin abgelehnt werden.

2. Daten ändern → weg navigieren → zurück

Ändern Sie einen Datensatz in einem zweiten Tab oder über eine andere Sitzung. Kehren Sie anschließend per Browsernavigation zurück.

Frage: Muss der sichtbare Zustand sofort aktualisiert werden, oder ist der alte Zustand fachlich akzeptabel?

3. Formular absenden → zurück

Prüfen Sie, ob Felder, Fehlermeldungen, Loading-State und Submit-Button sinnvoll aussehen. Testen Sie besonders Vorgänge, die nicht doppelt ausgeführt werden dürfen.

4. Consent-Zustand ändern

Ändern Sie Cookie- oder Tracking-Einstellungen, navigieren Sie weg und zurück. Prüfen Sie, ob eingebettete Dienste, Tag Manager und UI den aktuellen Consent-Zustand widerspiegeln.

5. Sprache, Theme oder Account wechseln

Globale Einstellungen werden häufig clientseitig gespeichert. Ein wiederhergestellter Snapshot sollte nicht dauerhaft eine alte Identität, Sprache oder Theme-Konfiguration anzeigen.

6. Analytics und Performance-Messung

Vergleichen Sie normale Navigation mit Back/Forward-Navigation. Werden Pageviews doppelt gezählt, gar nicht gezählt oder bewusst separat erfasst? Werden Performance-Werte fälschlich als vollständige Seitenladezeiten interpretiert?

7. Echtzeit-Verbindungen

WebSocket-, WebRTC- und ähnliche Verbindungen haben eigene Lifecycle-Anforderungen. Prüfen Sie, ob Verbindungen sauber pausieren, neu aufgebaut werden oder die Seite dadurch bewusst nicht in den bfcache gelangt.

8. Mehrere Browser

Chrome, Safari und Firefox nutzen bfcache, aber nicht jede Eligibility-Regel ist identisch. Eine Chrome-spezifische Heuristik ist keine plattformübergreifende Garantie.

pageshow ist der bessere Ort für gezielte Revalidierung

Für Seiten, die bei einer Wiederherstellung bestimmten Zustand prüfen müssen, ist pageshow ein nützlicher Lifecycle-Punkt.

Wenn event.persisted wahr ist, kam die Seite aus einem gespeicherten Seitenzustand zurück. Dann können gezielt die Dinge validiert werden, die wirklich frisch sein müssen:

• Session- oder Accountstatus
• kritische Berechtigungen
• Warenkorb oder Buchungszustand
• zeitkritische Preise oder Verfügbarkeit
• Consent-Konfiguration
• serverseitig veränderte Datensätze

Wichtig ist das Wort gezielt. Wer bei jedem Zurückklick die komplette Anwendung hart neu lädt, macht den Performance-Vorteil des bfcache wieder kaputt.

Ein besseres Muster ist: den visuellen Zustand sofort wiederherstellen lassen und nur die fachlich sensiblen Daten im Hintergrund revalidieren. Falls sich etwas geändert hat, wird die Oberfläche kontrolliert aktualisiert.

Warum unload keine gute Gegenmaßnahme ist

Historischer Code hängt Aufräumlogik gerne an unload. Das ist heute eine schlechte Basis.

web.dev weist darauf hin, dass unload unzuverlässig ist und in mehreren Browsern die bfcache-Nutzung beeinträchtigen kann. Für Lifecycle-Arbeit sind pagehide, visibilitychange und je nach Anwendungsfall pageshow robuster.

Das Ziel sollte also nicht lauten: „Wie verhindere ich bfcache mit einem alten Event?“

Sondern: „Wie baue ich meinen Seitenzustand so, dass eine Pause und Wiederaufnahme korrekt funktioniert?“

So testen Sie bfcache in Chrome DevTools

Chrome DevTools enthält einen eigenen Back/Forward-Cache-Test. In der Application-Ansicht kann geprüft werden, ob eine Seite erfolgreich aus dem bfcache wiederhergestellt werden kann und welche Gründe eine Wiederherstellung verhindern.

Das ist hilfreich für zwei entgegengesetzte Fehler:

• Eine Seite sollte schnell wiederherstellbar sein, wird aber durch unnötige Technik blockiert.
• Eine Anwendung scheint korrekt zu funktionieren, wurde aber noch nie unter echter bfcache-Wiederherstellung getestet.

Für reale Nutzer kann zusätzlich die notRestoredReasons-API Hinweise liefern, warum eine History-Navigation nicht aus dem bfcache bedient wurde. Solche Telemetrie ist besonders nützlich, wenn lokale Tests andere Browser-, iframe- oder Drittanbieter-Konstellationen haben als Produktion.

Red Flags in einem Website-Audit

• Cache-Control: no-store wird als alleiniger Schutz gegen Back-Navigation betrachtet.
• Logout wird nur per Klicktest geprüft, nicht mit anschließendem Browser-Zurück.
• Authentifizierung wird im Frontend als Sichtbarkeitszustand statt serverseitig als Berechtigung behandelt.
• Kritische Daten werden nur beim Initial-Load geladen.
• Analytics kennt keinen Unterschied zwischen Reload und bfcache-Restore.
• Formulare können nach Zurücknavigation unbeabsichtigt erneut ausgelöst werden.
• Drittanbieter registrieren unload-Handler und blockieren bfcache unbemerkt.
• Niemand testet Safari und Firefox, weil der Chrome-Test „grün“ war.
• Teams deaktivieren bfcache pauschal, statt die eigentliche Zustandslogik zu korrigieren.

Was Website-Pflichtencheck prüfen würde

Ein bfcache- und History-Navigation-Check kann unter anderem untersuchen:

• tatsächliche bfcache-Nutzung auf repräsentativen Seitentypen
• Cache-Control-Header und ihre beabsichtigte Bedeutung
• Login-, Logout- und Rollenwechsel
• Verhalten nach Session- oder Consent-Änderungen
• Formulare und nicht wiederholbare Aktionen
• Datenaktualität nach Back/Forward-Navigation
• pageshow, pagehide, visibilitychange und problematische unload-Handler
• Analytics- und Performance-Messung
• WebSocket- und Echtzeit-Komponenten
• Unterschiede zwischen Chrome, Safari und Firefox
• DevTools- und Lighthouse-Befunde
• Regressionstests für kritische Nutzerwege

Der bfcache ist kein Fehler, den man abschalten muss. Er ist eine reale Browser-Lifecycle-Eigenschaft, mit der moderne Websites umgehen sollten.

Der Zurück-Button ist heute nicht zwingend ein neuer Seitenaufruf. Wenn Ihre Sicherheits-, Daten- oder Messlogik genau davon ausgeht, ist nicht der Browser überraschend – sondern die Annahme zu fragil.