In Chrome wird eine Änderung vorgenommen, durch die die Verwendung des Back-/Forward-Cache (bfcache) für Seiten mit Cache-Control: no-store zulässig ist, wenn dies sicher möglich ist. Was das für Entwickler bedeutet, erfahren Sie hier.
Hintergrund
Wenn Sie Cache-Control: no-store als HTTP-Header festlegen, wird damit signalisiert, dass die Seite nicht im HTTP-Cache gespeichert werden soll. Sie sollte für Seiten mit sensiblen Daten verwendet werden, z. B. für Seiten, auf denen ein Nutzer angemeldet ist. Die Direktive no-store wird jedoch häufig auf Seiten ohne sensible Daten verwendet.
Mit bfcache verschieben wir das Löschen und pausieren die JavaScript-Ausführung, anstatt eine Seite zu zerstören, wenn der Nutzer die Seite verlässt. Wenn der Nutzer bald zurückwechselt, wird die Seite wieder sichtbar gemacht und die Ausführung von JavaScript wird fortgesetzt. Das führt zu einer nahezu sofortigen Seitennavigation für den Nutzer.
Obwohl es in der HTML-Spezifikation nicht erforderlich ist, nehmen Browser Cache-Control: no-store in der Regel als Signal, um die Seite nicht im bfcache zu platzieren. Dies ist der Hauptgrund, warum der bfcache nicht verwendet wird. Das betrifft etwa 17 % der Navigationen im Browserverlauf auf Mobilgeräten und 7 % der Navigationen im Browserverlauf auf Computern. Das bedeutet, dass diese Seiten nicht von der schnellen Wiederherstellung profitieren und die Seite vollständig neu geladen werden muss, einschließlich aller Netzwerkaufrufe, JavaScript-Ausführung und Rendering.
Cache-Control: no-store ist häufig so eingestellt, dass Caching-Probleme vermieden werden, wenn sich die Website ändert. Dieser Grund ist jedoch weniger relevant, wenn der bfcache verwendet wird, da die vollständige Seite fast wiederhergestellt wird, als wäre sie die ganze Zeit geöffnet gewesen.
So ändert sich dieses Verhalten in Chrome
Chrome hat angekündigt, dieses Verhalten zu ändern, geht aber bei dieser Änderung vorsichtig vor. Wir führen seit Chrome 116 Tests durch, die bis vor Kurzem bei 5 % der Seitenladevorgänge ausgeführt wurden.
Am 2. Oktober haben wir diesen Wert auf 10 % der Seitenladevorgänge erhöht. Im November soll er auf 20 % und Anfang nächsten Jahres auf 50 % ansteigen. Danach wird die Funktion vollständig eingeführt. Im Folgenden werden bestimmte Deaktivierungsmöglichkeiten beschrieben.
Sensible Daten
Unsere Analyse zeigt zwar, dass die meisten Navigationen zurück oder vorwärts keine vertraulichen Daten enthalten und daher für den bfcache infrage kommen, es gibt aber Fälle, in denen Seiten nicht in den bfcache aufgenommen werden sollten. Wenn Sie sich beispielsweise abmelden, sollte es nicht möglich sein, eine Seite aufzurufen, auf der Sie angemeldet waren, indem Sie vor- oder zurückgehen.
Um dies zu vermeiden, entfernt Chrome bei Änderungen an Cookies oder anderen Autorisierungsmethoden eine Seite aus dem bfcache.
Außerdem können Seiten, auf denen Cache-Control: no-store verwendet wird, weiterhin nicht für den Back-Forward-Cache verwendet werden, wenn eine der folgenden APIs verwendet wird:
Hinweis: Dies ist keine vollständige Liste der APIs, die die Verwendung von bfcache verhindern. Es sind nur die APIs aufgeführt, die bfcache auf Cache-Control: no-store-Seiten blockieren, auch wenn sie zum Zeitpunkt des Verlassens 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 ohne Cache-Control: no-store), um das Risiko weiter zu senken.
Deaktivierung für Unternehmen
Unternehmen haben oft Software, die nur schwer zu aktualisieren ist, und gemeinsam genutzte Geräte. Die Richtlinie „AllowBackForwardCacheForCacheControlNoStorePageEnabled“ kann deaktiviert werden, um die bfcache-Nutzung auf Cache-Control: no-store Seiten 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 vorherigen Ausnahmen zutrifft, z. B. eine Änderung von Cookies, wird die Verwendung des bfcache für die Seite verhindert. Im bfcache-Tester in den Chrome DevTools wird dann der Grund „Seiten, deren Hauptressource Cache-Control: no-store hat, können nicht in den Back-Forward-Cache aufgenommen werden“ angezeigt.
Auf dieser Testseite für bfcache können Sie mit und ohne dieses Flag testen.
Wichtige Informationen für Entwickler
Entwickler müssen keine Änderungen vornehmen, damit ihre Nutzer von der größeren bfcache-Nutzung profitieren können. Es gibt jedoch einige Dinge, die sie infolgedessen berücksichtigen müssen. Ähnliche Probleme sind möglicherweise auch bei anderen Websites bei der Einführung von bfcache im Dezember 2021 aufgetreten.
Auswirkungen auf die Leistung
Mit dieser Änderung möchten wir die Nutzerfreundlichkeit von Seiten im Web verbessern. Als wir bfcache zum ersten Mal eingeführt haben, wurden deutliche Verbesserungen bei Core Web Vitals festgestellt. Diese Verbesserungen möchten wir nun auf mehr Websites anwenden.
Websiteinhaber stellen während der Einführung möglicherweise eine Verbesserung ihrer Core Web Vitals fest. Sie können die bfcache-Nutzung in CrUX messen, auch im CrUX-Dashboard.
Analysen zu Auswirkungen
Aus dem bfcache wiederhergestellte Seiten stellen die alte Seite (einschließlich des JavaScript-Heaps) wieder her, anstatt sie neu zu laden. Viele bekannte Analyseanbieter messen bfcache-Wiederherstellungen nicht als neue Seitenaufrufe, da sie Seitenaufrufe erst beim ersten Laden auslösen.
Bei Websites, auf denen der bfcache zum ersten Mal verwendet wird, kann es daher zu einer geringeren Anzahl von Seitenladevorgängen in den Analysen kommen. Wir empfehlen, diese als Seitenaufrufe zu betrachten. Legen Sie dazu Listener für das Ereignis pageshow fest und prüfen Sie die Eigenschaft persisted:
// 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');
}
});
Updates bei der Seitenwiederherstellung verarbeiten
Da für Websites jetzt möglicherweise die bfcache-Nutzung genutzt wird, obwohl dies zuvor noch nicht der Fall war, und die Seite stattdessen vollständig mit neuen Daten aktualisiert wird, sollten Entwickler die Daten bei einer bfcache-Wiederherstellung aktualisieren.
Aktualisierungen können ähnlich wie das Protokollieren zusätzlicher Seitenaufrufe für Analysen mit dem Ereignis pageshow und dem Prüfen der Property persisted ausgelöst werden.
Nicht alle Inhalte müssen aktualisiert werden. Außerdem bevorzugen Nutzer möglicherweise, zu den Inhalten zurückzukehren, die sie zuvor gesehen haben. Wenn Sie beispielsweise eine Liste mit Artikeln aktualisieren, sieht der Nutzer möglicherweise keinen Artikel mehr, den er sich noch einmal ansehen wollte.
Auswirkungen auf Werbung
Ähnlich wie bei der Analyse kann sich die Anzahl der Anzeigenimpressionen auf Websites verringern, wenn Anzeigen nur beim Seitenaufbau geladen werden. Anzeigen können bei der Wiederherstellung über den bfCache programmatisch aktualisiert werden, um sicherzustellen, dass sie mit den vollständigen Seitenladevorgängen übereinstimmen. Auch hier wird das Ereignis pageshow verwendet und die Property persisted überprüft. Das ist aber nicht immer richtig. Informationen dazu, wie Anzeigen neu geladen werden, 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 unter Verwendung der bfcache-Komponente geben.
Fazit
Wir freuen uns, die Vorteile von bfcache auf vielen weiteren Seiten anbieten zu können, um die Nutzerfreundlichkeit zu verbessern. Wir haben diese Änderung sorgfältig durchdacht und möchten sie so sicher wie möglich einführen. Wir hoffen, dass die hier bereitgestellten Informationen Entwicklern dabei helfen, diese Änderung zu verstehen und alle erforderlichen Änderungen vorzunehmen, um Probleme zu vermeiden.