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

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. Diese 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 wird eine Seite nicht zerstört, wenn der Nutzer wegklickt, sondern die Zerstörung verschoben und die JS-Ausführung pausiert. Wenn der Nutzer bald wieder 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. Das 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.

Oft wird Cache-Control: no-store festgelegt, um Cache-Probleme bei Änderungen 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 geblieben.

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 für angemeldete Nutzer aufzurufen, indem Sie vor- oder zurückgehen.

Um dies zu vermeiden, entfernt Chrome eine Seite aus dem bfcache, wenn Änderungen an Cookies oder anderen Autorisierungsmethoden vorgenommen werden.

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

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 von 10 Minuten (für Seiten ohne Cache-Control: no-store) auf 3 Minuten reduziert, 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 weiterhin die Nutzung des bfcache für 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 Seite daran gehindert, den bfcache zu verwenden. 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 Webseiten im Web verbessern. Bei der Einführung von bfcache haben wir deutliche Verbesserungen bei den Core Web Vitals festgestellt. Diese Verbesserungen möchten wir jetzt auf weitere Websites ausweiten.

Websiteinhaber können nach der Einführung eine Verbesserung ihrer Core Web Vitals feststellen. Außerdem können sie die Nutzung des bfcache in CrUX messen, einschließlich im CrUX-Dashboard.

Analysen zu Auswirkungen

Bei Seiten, die aus dem bfcache wiederhergestellt werden, wird die alte Seite (einschließlich des JavaScript-Haufens) wiederhergestellt, anstatt die Seite neu zu laden. Viele gängige Analyseanbieter erfassen die Wiederherstellung des bfcache nicht als neue Seitenaufrufe, da sie nur beim ersten Laden Seitenaufrufe 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');
  }
});

Aktualisierungen beim Wiederherstellen von Seiten verarbeiten

Da die bfcache-Nutzung auf Websites jetzt möglicherweise angezeigt wird, wenn dies zuvor nicht der Fall war und die Seite stattdessen vollständig mit neuen Daten neu geladen 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 den Auswirkungen auf Analysen kann es auf Websites zu einer geringeren Anzahl von Anzeigenimpressionen kommen, wenn Anzeigen erst beim Laden der Seite geladen werden. Anzeigen können bei der Wiederherstellung des bfcache programmatisch aktualisiert werden, um für Übereinstimmung mit dem vollständigen Seitenaufbau zu sorgen. Dazu wird das Ereignis pageshow verwendet und die Property persisted geprüft. Dies ist jedoch nicht immer die richtige Vorgehensweise. Lesen Sie in der Dokumentation Ihres Anzeigenanbieters nach, wie Sie das Aktualisieren von Anzeigen auslösen.

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, den bfcache auf viele weitere Seiten anzuwenden, 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.