bfcache für Cache-Control aktivieren: no-store

Veröffentlicht am 21. Oktober 2024, zuletzt aktualisiert am 9. September 2025

In Chrome wird eine Änderung vorgenommen, um die Verwendung des Cache für Zurück/Vorwärts (bfcache) für Seiten mit Cache-Control: no-store zu ermöglichen, wenn dies sicher ist. Hier erfahren Sie, was das für Entwickler bedeutet.

Hintergrund

Wenn Sie Cache-Control: no-store als HTTP-Header festlegen, signalisieren Sie, dass die Seite nicht im HTTP-Cache gespeichert werden soll. Diese Richtlinie sollte für Seiten mit vertraulichen Daten verwendet werden, z. B. für Seiten, auf denen ein Nutzer angemeldet ist. Die no-store-Anweisung wird jedoch häufig auch auf Seiten ohne vertrauliche Daten verwendet.

Mit dem bfcache wird eine Seite nicht sofort zerstört, wenn der Nutzer sie verlässt. Stattdessen wird die Zerstörung aufgeschoben und die JS-Ausführung pausiert. Wenn der Nutzer schnell zurückkehrt, machen wir die Seite wieder sichtbar und setzen die JS-Ausführung fort. Dadurch können Nutzer die Seite fast sofort aufrufen.

Obwohl es in der HTML-Spezifikation nicht vorgeschrieben ist, verwenden Browser Cache-Control: no-store in der Regel als Signal, um die Seite nicht im bfcache zu speichern. Dies ist der häufigste Grund dafür, dass bfcache nicht verwendet wird, und zwar bei etwa 17% der Verlaufsnavigationen auf Mobilgeräten und 7% der Verlaufsnavigationen auf Computern. Das bedeutet, dass diese Seiten nicht von den schnellen Wiederherstellungen profitieren und die Seite vollständig neu laden müssen, einschließlich aller Netzwerkaufrufe, der JavaScript-Ausführung und des Renderings.

Häufig wird Cache-Control: no-store festgelegt, um Caching-Probleme bei Änderungen an der Website zu vermeiden. Dieser Grund ist jedoch weniger relevant, wenn der bfcache verwendet wird, da die gesamte Seite fast so wiederhergestellt wird, als wäre sie die ganze Zeit geöffnet gewesen.

So ändert Chrome dieses Verhalten

Chrome hat angekündigt, dieses Verhalten ändern zu wollen, geht dabei aber vorsichtig vor. Seit Chrome 116 führen wir Tests durch, bei denen der Prozentsatz der Seitenaufrufe schrittweise erhöht wird. Es wird erwartet, dass im März und April 2025 100% erreicht werden.

Sensible Daten

Unsere Analyse zeigt, dass die meisten Rückwärts- oder Vorwärtsnavigationen keine vertraulichen Daten enthalten und daher für den bfcache infrage kommen sollten. Es gibt jedoch Fälle, in denen Seiten nicht im bfcache platziert werden sollten. Nach dem Abmelden sollte es beispielsweise nicht möglich sein, eine angemeldete Seite durch Vor- oder Zurückgehen abzurufen.

Um dies zu vermeiden, entfernt Chrome eine Seite aus dem bfcache, wenn sich Cookies oder andere Autorisierungsmethoden ändern.

Außerdem können Seiten, auf denen Cache-Control: no-store verwendet wird, weiterhin nicht den Back-Forward-Cache nutzen, wenn die folgenden APIs verwendet werden:

Dies ist keine vollständige Liste der APIs, die die Verwendung des BFCache verhindern. Es handelt sich um die APIs, die den BFCache auf Cache-Control: no-store-Seiten blockieren, auch wenn sie beim Verlassen der Seite nicht verwendet werden.

Die Zeitüberschreitung für den Back-Forward-Cache für Cache-Control: no-store-Seiten wird ebenfalls auf 3 Minuten reduziert (von 10 Minuten für Seiten, auf denen Cache-Control: no-store nicht verwendet wird), um das Risiko weiter zu verringern.

Enterprise-Opt-outs

Unternehmen haben oft Software, die schwer zu aktualisieren ist, und gemeinsam genutzte Geräte. Die Richtlinie AllowBackForwardCacheForCacheControlNoStorePageEnabled kann deaktiviert werden, um die Verwendung von bfcache für Cache-Control: no-store-Seiten weiterhin zu verhindern.

Änderung testen

Entwickler können diese Änderung mit dem folgenden Flag testen:

--enable-features=CacheControlNoStoreEnterBackForwardCache:level/restore-unless-cookie-change

Wenn eine der oben genannten Ausnahmen zutrifft, z. B. wenn sich Cookies ändern, wird verhindert, dass die Seite den bfcache verwendet. Im bfcache-Tester in Chrome-Entwicklertools wird dann der Grund „Seiten, deren Hauptressource Cache-Control: no-store enthält, können nicht in den Back-Forward-Cache aufgenommen werden.“ angezeigt.

Sie können diese bfcache-Testseite verwenden, um Tests mit und ohne dieses Flag durchzuführen.

Wichtige Informationen für Entwickler

Entwickler müssen keine Änderungen vornehmen, damit ihre Nutzer von dieser stärkeren bfcache-Nutzung profitieren. Es gibt jedoch einige Dinge, die sie dadurch berücksichtigen müssen. Ähnliche Überlegungen haben andere Websites bei der ersten Einführung von bfcache im Dezember 2021 angestellt.

Sollten Entwickler weiterhin versuchen, die Nutzung von Cache-Control: no-store zu reduzieren?

Der bfcache ist für Cache-Control: no-store unter den oben genannten eingeschränkten Umständen und nur für Chrome aktiviert. Andere Browser blockieren die Verwendung von bfcache möglicherweise weiterhin, wenn Cache-Control: no-store verwendet wird.

Es empfiehlt sich weiterhin, die Verwendung von Cache-Control: no-store zu minimieren, anstatt sich auf diese Heuristiken zu verlassen.

Auswirkungen auf die Leistung

Wir nehmen diese Änderung vor, um die Nutzerfreundlichkeit von Webseiten zu verbessern. Wir haben bei der ersten Einführung von bfcache eine deutliche Verbesserung der Core Web Vitals festgestellt und möchten diese Verbesserungen nun auf weitere Websites ausweiten.

Websiteinhaber werden möglicherweise eine Verbesserung ihrer Core Web Vitals feststellen, wenn diese Funktion eingeführt wird. Sie können die bfcache-Nutzung in CrUX messen, auch in CrUX Vis.

Wirkungsanalysen

Seiten, die aus dem bfcache wiederhergestellt werden, werden nicht neu geladen, sondern die alte Seite wird wiederhergestellt, einschließlich des JavaScript-Heaps. Viele beliebte Analyseanbieter erfassen bfcache-Wiederherstellungen nicht als neue Seitenaufrufe, da Seitenaufrufe nur beim ersten Laden ausgelöst werden.

Wenn Websites den bfcache zum ersten Mal verwenden, kann es daher zu einem Rückgang der Seitenaufrufe in ihren Analysen kommen. Wir empfehlen, diese als Seitenaufrufe zu berücksichtigen. Dazu müssen Sie Listener für das pageshow-Ereignis festlegen und die persisted-Eigenschaft prüfen:

// Send a pageview when the page is first loaded.
gtag('event', 'page_view');

// Send another pageview if the page is restored from bfcache.
window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // Page was restored from bfcache, sent another page view.
    gtag('event', 'page_view');
  }
});

Aktualisierungen beim Wiederherstellen von Seiten verarbeiten

Da Websites jetzt möglicherweise bfcache-Nutzung sehen, die sie zuvor nicht gesehen haben, und die Seite stattdessen mit neuen Daten vollständig neu geladen würde, sollten Entwickler in Erwägung ziehen, Daten bei einer bfcache-Wiederherstellung zu aktualisieren.

Updates können auf ähnliche Weise ausgelöst werden wie das Protokollieren zusätzlicher Seitenaufrufe für die Analyse mit dem pageshow-Ereignis und der persisted-Property.

Nicht alle Inhalte müssen aktualisiert werden. Nutzer bevorzugen es möglicherweise, zu den Inhalten zurückzukehren, die sie zuvor gesehen haben. Wenn beispielsweise eine Liste von Artikeln aktualisiert wird, wird ein Artikel, den der Nutzer noch einmal aufrufen wollte, möglicherweise nicht mehr angezeigt.

Auswirkungen auf Anzeigen

Ähnlich wie bei der Analyse kann es bei Websites zu einem Rückgang der Anzeigenimpressionen kommen, wenn Anzeigen nur beim Laden der Seite geladen werden. Anzeigen können bei der Wiederherstellung aus dem bfcache programmatisch aktualisiert werden, um die Parität mit vollständigen Seitenaufrufen zu gewährleisten. Dazu wird wieder das pageshow-Ereignis verwendet und die persisted-Eigenschaft geprüft. Dies ist jedoch nicht immer die richtige Vorgehensweise. Informationen zum Auslösen von Anzeigen-Neuladevorgängen finden Sie in der Dokumentation Ihres Anzeigenanbieters.

Weitere Informationen zum bfcache

Weitere Informationen zum bfcache finden Sie in unserem umfassenden technischen Leitfaden zum bfcache.

Feedback

Wir freuen uns über Feedback zu dieser Änderung. Sie können es im Chrome-Issue-Tracker mit der bfcache-Komponente einreichen.

Fazit

Wir freuen uns, dass wir durch die Einführung von bfcache die Nutzerfreundlichkeit vieler weiterer Seiten verbessern können. Wir haben diese Änderung sorgfältig geprüft und möchten sie so sicher wie möglich einführen. Wir hoffen, dass die hier bereitgestellten Informationen Entwicklern helfen, diese Änderung zu verstehen und alle erforderlichen Änderungen vorzunehmen, um Probleme zu vermeiden.