Was ist der Back/Forward Cache?
Du klickst in einem Shop auf ein Produkt, schaust es dir an und tippst auf Zurück. Manchmal ist die Liste sofort da, an derselben Stelle. Manchmal lädt alles neu, und du musst wieder runterscrollen. Der Unterschied heißt Back/Forward Cache, kurz bfcache.
MDN beschreibt ihn so: Der Browser speichert beim Verlassen einen vollständigen Schnappschuss der Seite im Arbeitsspeicher, samt laufendem JavaScript. Bei der Rückkehr stellt er ihn wieder her, ohne Anfragen an den Server zu wiederholen. Die Seite war nie weg, sie war nur pausiert.
Alle großen Browser haben einen bfcache, Chrome seit Version 96. In Safari heißt er historisch Page Cache.
Warum das wichtig ist
Laut den Nutzungsdaten von Chrome ist am Desktop jede zehnte und am Handy jede fünfte Navigation ein Zurück oder Vor. Das sind viele Seitenaufrufe, die sofort da sein könnten.
Und sie zählen für die Core Web Vitals. Google wertet im Chrome UX Report seit März 2024 die Navigationsarten getrennt aus. Seiten mit hohem bfcache-Anteil haben deutlich öfter einen Largest Contentful Paint unter 200 Millisekunden, also praktisch sofort.
Beispiel · google.com 2024
Trefferquote im Chrome UX Report
62 %
aus dem bfcache, Handy
68 %
aus dem bfcache, Desktop
Bei google.com kamen rund zwei Drittel aller Zurück- und Vor-Navigationen aus dem bfcache. Der Rest musste neu laden.
Chrome-Entwicklerblog, Datensatz März 2024.
Studie · Web Almanac 2024
Wie oft er blockiert wird
15–16 %
Seiten mit unload-Handler
21 %
Websites mit no-store
Zwei der häufigsten Blocker stecken auf einem großen Teil des Webs. Oft hat sie niemand bewusst eingebaut.
HTTP Archive, Kapitel Performance 2024.
Was den bfcache blockiert
- unload-Handler: Ein Skript, das beim Verlassen der Seite etwas tun will. Laut web.dev ist das am Handy extrem unzuverlässig. Chrome führt es seit Oktober 2026 grundsätzlich nicht mehr aus, Firefox und Safari blockieren den bfcache dadurch aber weiterhin.
- Cache-Control: no-store: Ein Server-Befehl, die Seite nirgends zu speichern. Sinnvoll für Bankdaten, überflüssig für Blogartikel. Chrome lässt solche Seiten inzwischen unter Bedingungen zu, andere Browser nicht unbedingt.
- Offene Verbindungen: etwa zu einer Datenbank im Browser oder einem Live-Chat.
- Fremde Skripte: Laut einer Auswertung im Web Performance Calendar 2025 registriert zum Beispiel der Facebook-Tag einen unload-Handler.
Für WordPress gibt es gute Nachrichten: Laut einer HTTP-Archive-Abfrage des WordPress-Core-Entwicklers Weston Ruter sind 84 Prozent der WordPress-Websites für Besucher ohne Anmeldung bfcache-fähig. Wer eingeloggt ist, bekommt von WordPress meist no-store mitgeschickt und sieht den Effekt deshalb nicht.
So prüfst du deine Seite
- Chrome DevTools: Unter Application → Back/forward cache auf „Run test“ klicken. Chrome navigiert weg und zurück und nennt den Grund, falls es nicht klappt.
- Lighthouse und PageSpeed Insights: Seit Lighthouse 10 gibt es einen eigenen Prüfpunkt, der Blocker in behebbar und nicht behebbar sortiert.
- Abgemeldet testen: Im privaten Fenster, sonst siehst du die Einstellungen für Redakteure.
- Felddaten: Der Chrome UX Report zeigt den Anteil der Aufrufe aus dem bfcache für deine Domain.
Häufige Fehler
Fehler 1 · unload für Tracking nutzen
Wer beim Verlassen noch schnell Daten senden will, nimmt besser das Ereignis pagehide oder visibilitychange. Das empfiehlt web.dev, und es blockiert den bfcache nicht.
Fehler 2 · no-store überall setzen
Manche Sicherheits- oder Cache-Plugins setzen no-store auf jede Seite. Für frische Inhalte reicht no-cache. no-store gehört nur auf Seiten mit sensiblen Daten.
Fehler 3 · Seitenaufrufe aus dem bfcache nicht zählen
Kommt eine Seite aus dem bfcache, lädt sie nicht neu. Manche Analyse-Skripte zählen dann keinen Aufruf. Laut web.dev hilft das Ereignis pageshow mit der Eigenschaft persisted, um diese Aufrufe zu erkennen.
Fehler 4 · Eingeloggt testen
Als angemeldete Redakteurin schickt WordPress dir no-store, deine Besucher bekommen es nicht. Ein Test im eigenen Admin-Browser sagt also wenig.
Was du tun kannst
Häufige Fragen
Muss ich den bfcache einschalten?
Nein. Der Browser nutzt ihn von selbst. Deine Website kann ihn nur verhindern, etwa durch unload-Handler oder den Header no-store.
Wie prüfe ich, ob meine Website den bfcache nutzt?
In Chrome unter DevTools → Application → Back/forward cache auf „Run test“ klicken. Am besten abgemeldet im privaten Fenster, damit du dieselben Einstellungen wie deine Besucher bekommst.
Verbessert der bfcache meine Core Web Vitals?
Ja, für die Zurück- und Vor-Navigationen. Die erscheinen nahezu sofort, und der Chrome UX Report rechnet sie mit ein. Einen direkten Effekt aufs Ranking belegt Google nicht.
Verfälscht der bfcache meine Besucherzahlen?
Er kann, wenn dein Analyse-Skript nur beim Laden zählt. Prüf es mit einem kurzen Test: Seite aufrufen, weiterklicken, zurück — und in der Echtzeit-Ansicht deines Analyse-Tools nachsehen, ob der zweite Aufruf ankommt.
Warum klappt es nicht, wenn ich in WordPress angemeldet bin?
WordPress schickt angemeldeten Nutzern meist den Header no-store, damit keine persönlichen Daten zwischengespeichert werden. Für deine abgemeldeten Besucher gilt das nicht.
