Was der bfcache mit Zurück-Navigationen und Ihren Pageview-Zahlen macht

Was ist der bfcache?

Der bfcache, kurz für Back/Forward-Cache, ist eine Browser-Optimierung, die einen vollständigen Snapshot einer Seite im Speicher behält, wenn der Besucher wegnavigiert, sodass ein Klick auf Zurück oder Vorwärts diese Seite sofort wiederherstellt, statt sie neu zu laden. web.dev definiert ihn als "a browser optimization that enables instant back and forward navigation," und beschreibt den Mechanismus: "instead of destroying a page when the user navigates away, we postpone destruction and pause JS execution. If the user navigates back soon, we make the page visible again and unpause JS execution."

Alle großen Browser haben einen: Chrome seit Version 96, Firefox und Safari. Klicks auf Zurück und Vorwärts machen einen großen Teil des Surfens aus. web.dev berichtet: "Chrome usage data shows that 1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward."

Für Analytics zählt, was bei einer Wiederherstellung nicht passiert. Es wird kein HTML angefordert, keine Skripte laufen von vorn, und kein load-Event feuert. Ihr Tracker wacht genau dort auf, wo er pausiert wurde.

Worin unterscheidet sich der bfcache vom HTTP-Cache?

Der bfcache speichert die ganze laufende Seite, der HTTP-Cache dagegen einzelne Antworten. web.dev formuliert es so: "bfcache is a snapshot of the entire page in memory, including the JavaScript heap, whereas the HTTP cache contains only the responses for previously made requests." Eine Seite aus dem HTTP-Cache lädt trotzdem: Der Browser parst das HTML, führt jedes Skript aus und feuert load, also sendet Ihr Tracker einen normalen Pageview. Eine aus dem bfcache wiederhergestellte Seite überspringt all das.

Auch Timer und Promises pausieren. web.dev schreibt, dass "browsers pause any pending timers or unresolved promises for pages in bfcache" und sie bei der Wiederherstellung fortsetzen. Ein Heartbeat- oder Engagement-Timer macht also nach der Lücke weiter, statt sie mitzuzählen.

Welche Seiten kommen für den bfcache infrage?

Eine Seite kommt für den bfcache infrage, solange nichts auf ihr das Caching unsicher macht, und die häufigsten Blocker haben Sie selbst in der Hand. Die Tabelle listet die, die web.dev und die Chrome-Dokumentation nennen.

Manche Fehlschläge haben mit Ihrem Code nichts zu tun. web.dev nennt Zurück- oder Vorwärts-Navigationen, die den bfcache nicht nutzen, "when the user quits the browser and starts it again," "when the user duplicates a tab," und "when the user closes a tab and reopens it," und merkt an, dass Browser gecachte Seiten nach einer gewissen Zeit verwerfen, um Speicher zu sparen. Eine Trefferquote von 100% ist kein realistisches Ziel.

Iframes folgen der Hauptseite. Ein Iframe wird nicht separat gecacht, und ein Iframe, das eine blockierende API nutzt, kann die ganze Seite aus dem bfcache heraushalten.

Wie melden pageshow und pagehide den bfcache?

Die Events pageshow und pagehide melden den bfcache über ihre Eigenschaft persisted. Bei pageshow ist persisted gleich true, wenn die Seite aus dem bfcache zurückkam, und false bei einem normalen Laden. Bei pagehide bedeutet persisted gleich true, dass der Browser die Seite cachen will, wobei web.dev betont, dass das "doesn't guarantee that a page will be cached."

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    console.log('This page was restored from the bfcache.');
  } else {
    console.log('This page was loaded normally.');
  }
});

pageshow "fires right after the load event when the page is initially loading and any time the page is restored from bfcache." Dieses Detail ist für Analytics wichtig, wie der nächste Abschnitt zeigt. Chromium-Browser feuern zusätzlich die Page-Lifecycle-Events freeze und resume, wenn eine Seite in den bfcache wechselt und ihn verlässt, aber web.dev weist darauf hin, dass Sie zum Messen Ihrer bfcache-Trefferquote pageshow brauchen.

Warum verpasst Analytics Zurück-Navigationen oder zählt sie doppelt?

Analytics verpasst Zurück-Navigationen, weil eine Wiederherstellung aus dem bfcache die Skripte der Seite nicht erneut ausführt, ein Tracker, der seinen Pageview beim Laden sendet, bleibt also stumm. web.dev schreibt Website-Betreibern, sie könnten "a decrease in the total number of pageviews reported as Chrome enables bfcache for more users" bemerken, und ergänzt, dass viele Websites "already underreporting pageviews from other browsers that implement bfcache, because many popular analytics libraries don't measure bfcache restores as new pageviews."

Doppelte Zählungen entstehen, wenn die gegenteilige Korrektur unsauber umgesetzt wird. Weil pageshow auch bei jedem normalen Laden feuert, sendet ein Listener, der bei jedem pageshow einen Pageview schickt, ohne persisted zu prüfen, zwei Pageviews pro Laden: einen vom normalen Start des Trackers und einen vom Listener.

Weitere Verzerrungen folgen aus demselben Mechanismus:

• Lücken beim Engagement. Pausierte Timer laufen bei der Wiederherstellung weiter, also überspringen Engagement-Timer und Heartbeats die Zeit, in der die Seite im Speicher lag.
• Exit-Events, die nie gesendet werden. Eine Seite, die in den bfcache wechselt, feuert nie unload. Der Leitfaden zu beforeunload vs. pagehide erklärt, warum Exit-Beacons stattdessen auf pagehide und visibilitychange gehören.
• Schnellere Seiten wirken langsamer. web.dev erklärt, dass Wiederherstellungen wiederholte Besuche ersetzen, die zu den schnellsten Ladevorgängen in einem Datensatz gehören. Die Ladezeitdaten verschieben sich also ins Langsamere, obwohl Besucher eine schnellere Erfahrung hatten.
• Gemischte Zählungen. Eine Zurück-Navigation, die den bfcache verfehlt, lädt komplett neu und wird gezählt, während eine, die ihn trifft, nicht gezählt wird. Dasselbe Klickmuster ergibt je nach Eignung unterschiedliche Zahlen.

Der Leitfaden zu Pageviews, Sessions und Nutzern zeigt, wie diese Lücken bis in die Kennzahlen pro Session durchschlagen.

Wie zählen Sie Wiederherstellungen aus dem bfcache richtig?

Sie zählen Wiederherstellungen aus dem bfcache, indem Sie einen pageshow-Listener hinzufügen, der nur dann einen Pageview sendet, wenn event.persisted gleich true ist, und dann testen, dass jeder Klick auf Zurück genau einen Hit erzeugt.

1. Den Listener hinzufügen. Das Google-Analytics-Beispiel von web.dev sendet gtag('event', 'page_view') innerhalb von if (event.persisted) und überlässt das normale Laden dem Standard-Pageview.
2. Den Navigationstyp markieren. Um die Trefferquote zu messen, deaktiviert web.dev den Standard-Pageview mit send_page_view: false, sendet einen Pageview mit navigation_type aus performance.getEntriesByType('navigation')[0].type und sendet bei Wiederherstellungen navigation_type: 'back_forward_cache'. Vergleichen Sie die Zahlen für back_forward und back_forward_cache.
3. Den DevTools-Test ausführen. Öffnen Sie in den Chrome DevTools Application, dann Back-forward Cache, und klicken Sie auf Run Test. Ein Erfolg lautet "Restored from back-forward cache". Ein Fehlschlag listet die Gründe auf und markiert behebbare als Actionable.
4. Gründe aus echten Besuchen sammeln. Die Eigenschaft notRestoredReasons im Navigation-Timing-Eintrag meldet, warum eine Seite nicht wiederhergestellt wurde. Die Chrome-Dokumentation sagt, sie "has shipped from Chrome 123," mit Gründen wie unload-listener und response-cache-control-no-store.
5. Die Blocker beheben. Ersetzen Sie unload durch pagehide, entfernen Sie no-store von Seiten, die nicht sensibel sind, und schließen Sie IndexedDB- oder WebSocket-Verbindungen bei pagehide.

Performance-Kennzahlen brauchen dieselbe Sorgfalt. web.dev erklärt, dass Tools wie der Chrome User Experience Report Wiederherstellungen als eigene Seitenbesuche behandeln, und die Bibliothek web-vitals unterstützt Wiederherstellungen. Bei einer Wiederherstellung wird Largest Contentful Paint vom Zeitstempel des pageshow bis zum nächsten gezeichneten Frame gemessen, während Cumulative Layout Shift und INP auf 0 zurückgesetzt werden.

Wie wirkt sich der bfcache auf die Daten in Flowsery aus?

Die Dokumentation von Flowsery beschreibt nicht, wie der Tracker eine Wiederherstellung aus dem bfcache behandelt, testen Sie es also auf Ihrer eigenen Website, bevor Sie Code hinzufügen. Die Echtzeit-Analytics von Flowsery zeigen jeden Pageview in dem Moment auf Ihrem Dashboard, in dem er passiert, und damit ist die Prüfung schnell erledigt: Öffnen Sie eine Seite, klicken Sie auf einen Link, gehen Sie zurück und achten Sie darauf, ob die wiederhergestellte Seite als neuer Pageview erscheint. Führen Sie zuerst den bfcache-Test in den DevTools aus, damit Sie wissen, dass die Seite wiederhergestellt und nicht neu geladen wurde. Wenn Wiederherstellungen nicht erscheinen und Sie sie zählen wollen, stellt das npm-SDK von Flowsery eine Methode trackPageview() bereit, die Sie aus einem pageshow-Listener mit Prüfung von event.persisted aufrufen können. So vermeiden Sie die doppelte Zählung, die ein Listener ohne diese Prüfung verursachen würde.

Häufig gestellte Fragen

Haben alle Browser einen bfcache?

Ja, alle großen Browser haben einen. web.dev nennt Chrome seit Version 96, Firefox und Safari. Jeder Browser hat eigene Regeln für die Eignung, deshalb kann dieselbe Seite in einem Browser gecacht und in einem anderen neu geladen werden.

Feuert bei einer Wiederherstellung aus dem bfcache das load-Event?

Nein. Eine Wiederherstellung macht die pausierte Seite wieder sichtbar und setzt ihr JavaScript fort, also feuern load und DOMContentLoaded nicht. Das Event pageshow feuert, mit persisted gleich true.

Warum sind meine Pageviews gesunken, nachdem Chrome den bfcache ausgeweitet hat?

Mehr Klicks auf Zurück und Vorwärts wurden zu Wiederherstellungen statt zu Neuladevorgängen, und viele Analytics-Skripte zählen Pageviews nur beim Laden. web.dev beschreibt genau diesen Rückgang. Fügen Sie einen pageshow-Listener hinzu, der einen Pageview sendet, wenn event.persisted gleich true ist, falls Sie Wiederherstellungen zählen wollen.

Deaktiviert Cache-Control: no-store den bfcache?

Auf der Seite selbst hat es Seiten bisher aus dem bfcache herausgehalten. web.dev empfiehlt, es nur für Seiten mit sensiblen Informationen zu nutzen und für Seiten, die nur frische Inhalte brauchen, no-cache oder max-age=0 zu verwenden. Keine dieser beiden Optionen beeinflusst die Eignung.

Wie prüfe ich, ob eine Seite für den bfcache infrage kommt?

Gehen Sie in den Chrome DevTools zu Application, dann zu Back-forward Cache, und klicken Sie auf Run Test. Das Panel meldet, ob die Seite wiederhergestellt wurde, und listet andernfalls die blockierenden Gründe auf. Für echte Besuche lesen Sie notRestoredReasons aus dem Navigation-Timing-Eintrag.

Funktioniert der bfcache innerhalb einer Single-Page-App?

Nein. web.dev schreibt, dass der bfcache "doesn't work for 'soft navigations' within a single-page app." Er greift, wenn ein Besucher die App verlässt und mit dem Zurück-Button zurückkommt, wodurch die ganze App wiederhergestellt werden kann, statt neu zu starten, sofern die Seite dafür infrage kommt.

Was passiert mit Timern und Heartbeats, solange eine Seite im bfcache liegt?

Browser pausieren ausstehende Timer und unerfüllte Promises und setzen sie bei der Wiederherstellung fort. Ein Heartbeat oder Engagement-Timer macht nach der Lücke weiter, die Zeit im Speicher zählt also nicht als Engagement.

Hält ein unload-Listener eine Seite aus dem bfcache heraus?

Ja, in Chrome und Firefox auf dem Desktop sowie in Firefox mobil, außer unter iOS. Ersetzen Sie unload durch pagehide, dann bleibt die Seite geeignet.

Wie vermeide ich doppelte Pageviews mit einem pageshow-Listener?

pageshow feuert bei jedem normalen Laden und bei jeder Wiederherstellung. Senden Sie den Pageview daher nur, wenn event.persisted den Wert true hat. Den normalen Ladevorgang deckt der Start des Trackers bereits ab. Drücken Sie dann auf einer Testseite zurück und prüfen Sie, dass jeder Klick genau einen Treffer erzeugt.

Zählt Flowsery Wiederherstellungen aus dem bfcache automatisch?

Die Flowsery-Docs beschreiben das nicht, testen Sie es also auf Ihrer eigenen Seite. Öffnen Sie eine Seite, klicken Sie einen Link, drücken Sie zurück und beobachten Sie in der Echtzeit-Ansicht, ob ein neuer Pageview erscheint. Fehlt er, rufen Sie trackPageview() aus dem npm SDK in einem pageshow-Listener auf, der event.persisted prüft.