Back-Forward-Cache

Philip Walton

Barry Pollard

Der Back-Forward-Cache (oder bfcache) ist eine Browseroptimierung, mit der vorwärts und rückwärts zu navigieren. Die Browsernutzung wird dadurch erheblich verbessert, insbesondere für Nutzer mit langsameren Netzwerken oder Geräten.

Als Webentwickler sollten Sie wissen, wie Sie Ihre Seiten für den bfcache optimieren, damit Ihre Nutzer davon profitieren können.

Browserkompatibilität

bfcache wird seit vielen Jahren sowohl in Firefox als auch in Safari auf Computern und Mobilgeräten unterstützt.

Ab Version 86 wurde bfcache für einen kleinen Prozentsatz von Nutzern für die websiteübergreifende Navigation unter Android aktiviert. In den nachfolgenden Releases wurde nach und nach zusätzliche Unterstützung eingeführt. Seit Version 96 ist bfcache für alle Chrome-Nutzer auf Computern und Mobilgeräten aktiviert.

bfcache-Grundlagen

bfcache ist ein speicherinterner Cache, der einen vollständigen Snapshot einer Seite (einschließlich des JavaScript-Heaps) speichert, während der Nutzer die Seite verlässt. Da sich die gesamte Seite im Arbeitsspeicher befindet, kann sie im Browser schnell wiederhergestellt werden, wenn der Nutzer später wiederkehrt.

Wie oft haben Sie eine Website besucht und auf einen Link geklickt, um zu einer anderen Seite zu wechseln, nur um festzustellen, dass das nicht das war, was Sie wollten, und auf die Schaltfläche „Zurück“ klicken? In diesem Moment kann bfcache einen großen Einfluss darauf haben, wie schnell die vorherige Seite geladen wird:

In diesem Video von bfcache in Aktion wird gezeigt, wie schnell bfcache die Navigation beschleunigen kann:

Im Video ist das Beispiel mit bfcache ziemlich schneller als das Beispiel ohne.

bfcache beschleunigt nicht nur die Navigation, sondern verringert auch die Datennutzung, da Ressourcen nicht noch einmal heruntergeladen werden müssen.

Aus den Chrome-Nutzungsdaten geht hervor, dass jede zehnte Navigation auf einem Computer und jede fünfte auf einem Mobilgerät entweder vorwärts oder rückwärts erfolgt. Wenn bfcache aktiviert war, konnten Browser die Datenübertragung und den Zeitaufwand für das tägliche Laden von Milliarden von Webseiten eliminieren.

Wie der „Cache“ arbeitet

Der „Cache“ von bfcache verwendet wird, unterscheidet sich vom HTTP-Cache, der seine eigene Rolle bei der Beschleunigung wiederholter Navigationen spielt. „bfcache“ ist ein Snapshot der gesamten Seite im Arbeitsspeicher, einschließlich des JavaScript-Heaps, während der HTTP-Cache nur die Antworten für zuvor gestellte Anfragen enthält. Da es sehr selten ist, dass alle Anforderungen, die zum Laden einer Seite erforderlich sind, aus dem HTTP-Cache ausgeführt werden können, sind wiederholte Besuche mit bfcache-Wiederherstellungen immer schneller als selbst die am besten optimierten Navigationen ohne bfcache.

Das Erstellen eines Snapshots einer Seite im Arbeitsspeicher ist jedoch mit einer gewissen Komplexität verbunden, was die beste Vorgehensweise zur Beibehaltung von laufendem Code angeht. Wie werden beispielsweise setTimeout()-Aufrufe verarbeitet, bei denen das Zeitlimit erreicht wird, während sich die Seite im bfCache befindet?

Die Antwort ist, dass Browser ausstehende Timer oder ungelöste Promis für Seiten im bfcache anhalten, einschließlich fast aller ausstehenden Aufgaben in den JavaScript-Aufgabenwarteschlangen, und Verarbeitungsaufgaben fortsetzen, wenn die Seite aus dem bfcache wiederhergestellt wird.

In einigen Fällen, z. B. bei Zeitüberschreitungen und Versprechen, ist dies ein relativ geringes Risiko, in anderen Fällen kann es jedoch zu verwirrendem oder unerwartetem Verhalten führen. Wenn der Browser beispielsweise eine Aufgabe anhält, die als Teil einer IndexedDB erforderlich ist Transaktion kann sich das auf andere geöffnete Tabs im selben Ursprung auswirken, da mehrere Tabs gleichzeitig auf dieselben IndexedDB-Datenbanken zugreifen können. Daher versuchen Browser im Allgemeinen nicht, Seiten während einer IndexedDB-Transaktion im Cache zu speichern oder während sie APIs verwenden, die andere Seiten beeinflussen könnten.

Weitere Informationen dazu, wie sich verschiedene API-Nutzungen auf die bfcache-Eignung einer Seite auswirken, finden Sie unter Seiten für bfcache optimieren.

bfcache und iFrames

Wenn eine Seite eingebettete iFrames enthält, können die iFrames selbst nicht für den bfcache verwendet werden. Wenn Sie beispielsweise innerhalb eines iFrames zu einer anderen Seite navigieren, dann aber zurückgehen, wechselt der Browser wieder „zurück“ innerhalb des iFrames statt im Hauptframe, aber bei der Rückwärtsnavigation innerhalb des iFrames wird der bfcache nicht verwendet.

Der Hauptframe kann auch daran gehindert werden, den bfcache zu verwenden, wenn ein eingebetteter iFrame APIs verwendet, die dies blockieren. Dies lässt sich mit der für den Hauptframe festgelegten Berechtigungsrichtlinie oder durch die Verwendung von sandbox-Attributen verhindern.

bfcache und Single-Page-Anwendungen (SPA)

Da bfcache mit vom Browser verwalteten Navigationen funktioniert, funktioniert es nicht bei „weichen Navigationen“. innerhalb einer Single-Page-App (SPA). bfcache kann jedoch trotzdem hilfreich sein, wenn Sie zu einer SPA zurückkehren, anstatt diese App von Anfang an komplett neu zu initialisieren.

APIs zum Beobachten von bfcache

Obwohl bfcache eine Optimierung ist, die Browser automatisch durchführen, ist es dennoch wichtig, dass Entwickler wissen, wann dies geschieht, damit sie ihre Seiten entsprechend optimieren und alle Messwerte oder Leistungsmessungen entsprechend anpassen können.

Die wichtigsten Ereignisse zur Beobachtung von bfcache sind die Seitenübergangsereignisse pageshow und pagehide, die von den meisten Browsern unterstützt werden.

Die neueren Seitenlebenszyklus-Ereignisse (freeze und resume) werden auch ausgelöst, wenn Seiten den bfcache aufrufen oder verlassen, sowie in einigen anderen Situationen, z. B. wenn ein Hintergrundtab eingefroren ist, um die CPU-Nutzung zu minimieren. Diese Ereignisse werden nur in Chromium-basierten Browsern unterstützt.

Beobachten, wenn eine Seite aus bfcache wiederhergestellt wird

Das pageshow-Ereignis wird direkt nach dem load-Ereignis ausgelöst, wenn die Seite zum ersten Mal geladen wird und wenn die Seite aus bfcache wiederhergestellt wird. Das pageshow-Ereignis hat eine persisted-Eigenschaft, die true ist, wenn die Seite aus dem bfcache wiederhergestellt wurde, andernfalls false. Mit dem Attribut persisted können Sie zwischen regulären Seitenladevorgängen und bfCache-Wiederherstellungen unterscheiden. Beispiel:

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

In Browsern, die die Page Lifecycle API unterstützen, wird das resume-Ereignis ausgelöst, wenn Seiten aus bfcache (direkt vor dem pageshow-Ereignis) wiederhergestellt werden und wenn ein Nutzer einen fixierten Hintergrund-Tab wieder aufruft. Wenn Sie den Status einer Seite nach dem Einfrieren aktualisieren möchten (einschließlich der Seiten im bfcache), können Sie das resume-Ereignis verwenden. Wenn Sie jedoch die bfcache-Trefferquote Ihrer Website messen möchten, müssen Sie das pageshow-Ereignis verwenden. In einigen Fällen müssen Sie möglicherweise beide verwenden.

Weitere Informationen zu Best Practices für die bfcache-Messung finden Sie unter Auswirkungen von bfcache auf Analysen und Leistungsmessungen.

Beobachten, wenn eine Seite in den bfcache eintritt

Das pagehide-Ereignis wird entweder ausgelöst, wenn eine Seite entladen wird oder wenn der Browser versucht, sie in den bfcache zu speichern.

Das pagehide-Ereignis hat auch eine persisted-Eigenschaft. Wenn der Status false lautet, können Sie sicher sein, dass diese Seite nicht in den bfcache gelangen wird. Wenn persisted jedoch true ist, bedeutet dies nicht, dass eine Seite im Cache gespeichert wird. Das bedeutet, dass der Browser künftig versucht, die Seite im Cache zu speichern. Es gibt jedoch möglicherweise andere Faktoren, die das Speichern im Cache erschweren.

window.addEventListener('pagehide', (event) => {
  if (event.persisted) {
    console.log('This page *might* be entering the bfcache.');
  } else {
    console.log('This page will unload normally and be discarded.');
  }
});

Ebenso wird das freeze-Ereignis sofort nach dem pagehide-Ereignis ausgelöst, wenn persisted den Wert true hat. Das bedeutet aber nur, dass der Browser die Seite im Cache speichern möchte. Es kann verschiedene Gründe haben, die später erläutert werden.

Seiten für bfcache optimieren

Nicht alle Seiten werden im bfcache gespeichert und selbst wenn eine Seite dort gespeichert wird, bleibt sie dort nicht unbegrenzt. Es ist wichtig, dass die Entwickler verstehen, warum Seiten für bfcache infrage kommen (und nicht infrage kommen), um ihre Cache-Trefferraten zu maximieren.

In den folgenden Abschnitten werden die Best Practices beschrieben, damit der Browser Ihre Seiten so wahrscheinlich wie möglich im Cache speichern kann.

unload-Ereignis nie verwenden

Die wichtigste Methode zur Optimierung für den bfcache in allen Browsern besteht darin, nie das Ereignis unload zu verwenden. Überhaupt nicht!

Das unload-Ereignis ist für Browser problematisch, da es älter als bfcache ist und viele Seiten im Internet unter der (vernünftigen) Annahme basieren, dass eine Seite nicht mehr existieren wird, nachdem das unload-Ereignis ausgelöst wurde. Dies stellt eine Herausforderung dar, da viele dieser Seiten auch in der Annahme erstellt wurden, dass das unload-Ereignis jedes Mal ausgelöst wird, wenn ein Nutzer die Website verlässt. Das ist nicht mehr der Fall (und ist schon lange nicht der Fall).

Browser stehen also vor einem Dilemma. Sie müssen zwischen etwas wählen, das die Nutzererfahrung verbessern kann, aber auch die Gefahr besteht, dass die Seite beschädigt wird.

Auf Desktop-Computern werden Seiten in Chrome und Firefox nicht für den bfcache unterstützt, wenn sie einen unload-Listener hinzufügen. Dies ist zwar weniger riskant, weist aber auch viele Seiten auf. Safari versucht, einige Seiten mit einem unload-Event-Listener im Cache zu speichern. Um mögliche Fehler zu vermeiden, wird das unload-Ereignis jedoch nicht ausgeführt, wenn ein Nutzer die Seite verlässt. Dadurch wird das Ereignis sehr unzuverlässig.

Auf Mobilgeräten versuchen Chrome und Safari, Seiten mit einem unload-Event-Listener im Cache zu speichern, da das Fehlerrisiko geringer ist, da das unload-Ereignis auf Mobilgeräten immer extrem unzuverlässig war. In Firefox werden Seiten, die unload verwenden, als nicht für den bfcache geeignet behandelt. Eine Ausnahme bilden iOS-Geräte, bei denen alle Browser die WebKit-Rendering-Engine verwenden müssen. Daher verhält es sich wie Safari.

Verwenden Sie anstelle des unload-Ereignisses das pagehide-Ereignis. Das pagehide-Ereignis wird immer ausgelöst, wenn das unload-Ereignis ausgelöst wird. Es wird auch ausgelöst, wenn eine Seite in den bfcache abgelegt wird.

Lighthouse hat einen no-unload-listeners-Audit, bei dem Entwickler gewarnt werden, wenn JavaScript auf ihren Seiten (einschließlich des von Drittanbieter-Bibliotheken) einen unload-Event-Listener hinzufügt.

Aufgrund der Unzuverlässigkeit und der Auswirkungen auf die Leistung von bfcache plant Chrome, das unload-Ereignis einzustellen.

Berechtigungsrichtlinie verwenden, um zu verhindern, dass Unload-Handler auf einer Seite verwendet werden

Websites, die keine unload-Event-Handler verwenden, können mithilfe einer Berechtigungsrichtlinie dafür sorgen, dass diese nicht hinzugefügt werden.

Permission-Policy: unload=()

Außerdem wird dadurch verhindert, dass Drittanbieter oder Erweiterungen die Website verlangsamen, indem sie Unload-Handler hinzufügen, wodurch die Website nicht mehr für den bfcache verwendet werden kann.

Nur beforeunload-Listener bedingt hinzufügen

Das beforeunload-Ereignis führt nicht dazu, dass Ihre Seiten nicht für den bfcache in modernen Browsern infrage kommen, aber zuvor war es da und es ist immer noch unzuverlässig. Verwenden Sie es daher nur, wenn es unbedingt erforderlich ist.

Im Gegensatz zum unload-Ereignis gibt es jedoch legitime Verwendungszwecke für beforeunload. Wenn Sie beispielsweise den Nutzer warnen möchten, dass er Nicht gespeicherte Änderungen gehen verloren, wenn sie die Seite verlassen. In diesem Fall empfehlen, beforeunload-Listener nur dann hinzuzufügen, wenn ein Nutzer noch nicht gespeichert hat Änderungen vornehmen und diese sofort nach dem Speichern der nicht gespeicherten Änderungen entfernen.

window.addEventListener('beforeunload', (event) => {
  if (pageHasUnsavedChanges()) {
    event.preventDefault();
    return event.returnValue = 'Are you sure you want to exit?';
  }
});

function beforeUnloadListener(event) {
  event.preventDefault();
  return event.returnValue = 'Are you sure you want to exit?';
};

// A function that invokes a callback when the page has unsaved changes.
onPageHasUnsavedChanges(() => {
  window.addEventListener('beforeunload', beforeUnloadListener);
});

// A function that invokes a callback when the page's unsaved changes are resolved.
onAllChangesSaved(() => {
  window.removeEventListener('beforeunload', beforeUnloadListener);
});

Verwendung von Cache-Control: no-store minimieren

Cache-Control: no-store ist ein HTTP-Header, den Webserver für Antworten festlegen können, der den Browser anweist, die Antwort nicht in einem HTTP-Cache zu speichern. Es wird für Ressourcen verwendet, die vertrauliche Nutzerinformationen enthalten, z. B. Seiten, für die eine Anmeldung erforderlich ist.

Obwohl bfcache kein HTTP-Cache ist, wurde die Seite in der Vergangenheit von Browsern nicht in bfcache gespeichert, wenn Cache-Control: no-store für die Seitenressource selbst (und nicht für eine Unterressource) festgelegt wurde. Wir arbeiten daran, dieses Verhalten für Chrome unter Einhaltung des Datenschutzes zu ändern. Derzeit können jedoch alle Seiten, die Cache-Control: no-store verwenden, nicht für den bfcache verwendet werden.

Da Cache-Control: no-store die Eignung einer Seite für den bfcache einschränkt, sollte es nur auf Seiten festgelegt werden, die vertrauliche Informationen enthalten, und auf denen irgendeine Art von Caching nie angebracht ist.

Verwenden Sie Cache-Control: no-cache oder Cache-Control: max-age=0 für Seiten, auf denen immer aktuelle Inhalte angezeigt werden müssen und die keine vertraulichen Informationen enthalten. Diese Anweisungen weisen den Browser an, den Inhalt vor der Bereitstellung erneut zu überprüfen, und sie wirken sich nicht auf die bfcache-Eignung einer Seite aus.

Wenn eine Seite aus dem bfcache wiederhergestellt wird, wird sie aus dem Arbeitsspeicher und nicht aus dem HTTP-Cache wiederhergestellt. Daher werden Anweisungen wie Cache-Control: no-cache oder Cache-Control: max-age=0 nicht berücksichtigt und es erfolgt keine erneute Validierung, bevor der Inhalt dem Nutzer angezeigt wird.

Dies ist jedoch wahrscheinlich immer noch eine bessere Nutzererfahrung, da bfcache-Wiederherstellungen sofort erfolgen und da Seiten nicht sehr lange im bfcache bleiben, ist es unwahrscheinlich, dass der Inhalt veraltet ist. Sollten sich die Inhalte allerdings von Minute zu Minute ändern, kannst du alle Aktualisierungen mit dem Ereignis pageshow abrufen, wie im nächsten Abschnitt beschrieben.

Veraltete oder sensible Daten nach der bfcache-Wiederherstellung aktualisieren

Wenn Ihre Website den Nutzerstatus beibehält – insbesondere vertrauliche Nutzerdaten –, müssen die Daten aktualisiert oder gelöscht werden, nachdem eine Seite aus dem bfcache wiederhergestellt wurde.

Wenn ein Nutzer beispielsweise zu einer Zahlungsseite navigiert und dann seinen Einkaufswagen aktualisiert, kann eine Zurück-Navigation potenziell veraltete Informationen anzeigen, wenn eine veraltete Seite aus bfcache wiederhergestellt wird.

Ein weiteres, wichtigeres Beispiel ist, wenn sich ein Nutzer auf einem öffentlichen Computer von einer Website abmeldet und der nächste Nutzer auf die Schaltfläche „Zurück“ klickt. Dadurch könnten private Daten preisgegeben werden, von denen der Nutzer angenommen wurde, dass sie bei der Abmeldung gelöscht wurden.

Um solche Situationen zu vermeiden, empfiehlt es sich, die Seite immer nach einem pageshow-Ereignis zu aktualisieren, wenn event.persisted den Wert true hat:

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // Do any checks and updates to the page
  }
});

Idealerweise sollten Sie den Inhalt aktualisieren. Bei einigen Änderungen können Sie jedoch ein vollständiges Neuladen erzwingen. Mit dem folgenden Code wird geprüft, ob im pageshow-Ereignis ein websitespezifisches Cookie vorhanden ist. Wird das Cookie nicht gefunden, wird es neu geladen:

window.addEventListener('pageshow', (event) => {
  if (event.persisted && !document.cookie.match(/my-cookie)) {
    // Force a reload if the user has logged out.
    location.reload();
  }
});

Ein Neuladen hat den Vorteil, dass der Verlauf weiterhin erhalten bleibt (um Vorwärtsnavigationen zu ermöglichen), aber eine Weiterleitung kann in einigen Fällen sinnvoller sein.

Anzeigen und bfcache-Wiederherstellung

Es mag verlockend sein, auf die Verwendung von bfcache zu verzichten, um bei jeder Rückwärts-/Vorwärts-Navigation einen neuen Satz von Anzeigen zu schalten. Allerdings ist es fraglich, ob sich ein solches Verhalten nicht nur auf die Leistung auswirkt, sondern auch zu mehr Interaktionen mit den Anzeigen. Möglicherweise ist Nutzern eine Anzeige aufgefallen, die sie durch erneutes Laden des Inhalts wieder aufrufen wollten, anstatt ihn aus dem bfcache wiederherzustellen. Das Testen dieses Szenarios – idealerweise mit einem A/B-Test – ist wichtig, bevor Annahmen getroffen werden.

Bei Websites, auf denen Anzeigen bei der bfCache-Wiederherstellung aktualisiert werden sollen und dann nur die Anzeigen im pageshow-Ereignis aktualisiert werden, wenn event.persisted den Wert true hat, ist dies ohne Beeinträchtigung der Seitenleistung möglich. Wenden Sie sich an Ihren Anzeigenanbieter. Hier finden Sie ein Beispiel, wie dies mit dem Google Publishing-Tag funktioniert.

window.opener-Verweise vermeiden

Wenn in älteren Browsern eine Seite mit window.open() über einen Link mit target=_blank ohne Angabe von rel="noopener" geöffnet wird, hat die öffnende Seite einen Verweis auf das Fensterobjekt der geöffneten Seite.

Eine Seite mit einem window.opener-Verweis, der nicht null ist, kann nicht sicher in den bfcache verschoben werden, da sie so ein Sicherheitsrisiko darstellt.

Daher ist es am besten, window.opener-Referenzen zu erstellen. Dazu kannst du nach Möglichkeit rel="noopener" verwenden. Hinweis: Dies ist jetzt die Standardeinstellung in allen modernen Browsern. Wenn auf deiner Website ein Fenster geöffnet und über window.postMessage() gesteuert werden muss oder direkt auf das Fensterobjekt verwiesen wird, kommt weder das geöffnete Fenster noch der öffnende Browser für den bfcache infrage.

Offene Verbindungen schließen, bevor der Nutzer die Seite verlässt

Wie bereits erwähnt, werden beim Einlegen einer Seite in den bfCache alle geplanten JavaScript-Aufgaben pausiert und fortgesetzt, wenn die Seite aus dem Cache entfernt wird.

Wenn diese geplanten JavaScript-Aufgaben nur auf DOM-APIs oder andere APIs zugreifen, die nur auf die aktuelle Seite beschränkt sind, wird das Pausieren dieser Aufgaben, während die Seite für den Nutzer nicht sichtbar ist, keine Probleme verursachen.

Wenn diese Aufgaben jedoch mit APIs verbunden sind, auf die auch über andere Seiten desselben Ursprungs zugegriffen werden kann (z. B. IndexedDB, Web Locks, WebSockets), kann dies problematisch sein, da das Pausieren dieser Aufgaben dazu führen kann, dass Code auf anderen Tabs nicht ausgeführt wird.

Daher versuchen einige Browser in den folgenden Fällen nicht, eine Seite in den bfcache zu speichern:

• Seiten mit einer offenen IndexedDB-Verbindung
• Seiten mit laufendem fetch() oder XMLHttpRequest
• Seiten mit einer offenen WebSocket- oder WebRTC-Verbindung

Wenn auf deiner Seite eine dieser APIs verwendet wird, empfehlen wir dringend, Verbindungen zu schließen und Beobachter während des Ereignisses pagehide oder freeze zu entfernen oder zu trennen. So kann der Browser die Seite sicher im Cache speichern, ohne andere geöffnete Tabs zu beeinträchtigen.

Wenn die Seite dann aus dem bfcache wiederhergestellt wird, können Sie diese APIs während des pageshow- oder resume-Ereignisses neu öffnen oder wiederherstellen.

Das folgende Beispiel zeigt, wie Sie dafür sorgen können, dass Seiten, die IndexedDB verwenden, für bfcache infrage kommen, indem Sie eine offene Verbindung im pagehide-Event-Listener schließen:

let dbPromise;
function openDB() {
  if (!dbPromise) {
    dbPromise = new Promise((resolve, reject) => {
      const req = indexedDB.open('my-db', 1);
      req.onupgradeneeded = () => req.result.createObjectStore('keyval');
      req.onerror = () => reject(req.error);
      req.onsuccess = () => resolve(req.result);
    });
  }
  return dbPromise;
}

// Close the connection to the database when the user leaves.
window.addEventListener('pagehide', () => {
  if (dbPromise) {
    dbPromise.then(db => db.close());
    dbPromise = null;
  }
});

// Open the connection when the page is loaded or restored from bfcache.
window.addEventListener('pageshow', () => openDB());

Testen, ob die Seiten im Cache gespeichert werden können

Mit den Chrome-Entwicklertools können Sie Ihre Seiten testen, um sicherzustellen, dass sie für den bfcache optimiert sind. Außerdem können Sie Probleme identifizieren, die verhindern, dass sie zulässig sind.

So testen Sie eine Seite:

1. Rufen Sie die Seite in Chrome auf.
2. Gehen Sie in den Entwicklertools zu Application (Anwendung) -> Back-Forward-Cache.
3. Klicken Sie auf die Schaltfläche Run Test (Test ausführen). Die Entwicklertools versuchen dann, die Seite zu verlassen und wieder zurückzugehen. um zu ermitteln, ob die Seite aus dem bfcache wiederhergestellt werden kann.

</ph>

Wenn der Test erfolgreich ist, wird im Bereich „Aus dem Back-Forward-Cache wiederhergestellt“ angezeigt.

</ph>

Wenn sie nicht erfolgreich ist, wird im Steuerfeld der Grund dafür angegeben. Wenn Sie als Entwickler den Grund beheben können, wird dies im Steuerfeld als Umsetzbar gekennzeichnet.

</ph>

In diesem Beispiel macht die Verwendung eines unload-Event-Listeners die Seite nicht für bfcache geeignet. Sie können dies beheben, indem Sie von unload auf pagehide umstellen:

window.addEventListener('pagehide', ...);

window.addEventListener('unload', ...);

Lighthouse 10.0 hat einen bfcache-Audit hinzugefügt, der einen ähnlichen Test durchführt. Weitere Informationen finden Sie in der Dokumentation zum bfcache-Audit.

Auswirkungen von bfcache auf Analysen und Leistungsmessung

Wenn Sie ein Analysetool verwenden, um die Besuche auf Ihrer Website zu messen, werden Sie möglicherweise einen Rückgang der Gesamtzahl der Seitenaufrufe feststellen, da Chrome bfcache für mehr Nutzer aktiviert.

Tatsächlich werden wahrscheinlich bereits zu wenige Seitenaufrufe von anderen Browsern erfasst, die bfcache implementieren, da viele gängige Analysebibliotheken die bfcache-Wiederherstellungen nicht als neue Seitenaufrufe messen.

Wenn Sie bfcache-Wiederherstellungen in die Anzahl Ihrer Seitenaufrufe einschließen möchten, legen Sie Listener für das pageshow-Ereignis fest und aktivieren Sie das Attribut persisted.

Im folgenden Beispiel sehen Sie, wie dies mit Google Analytics funktioniert. Andere Analysetools verwenden wahrscheinlich eine ähnliche Logik:

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

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

bfcache-Trefferquote messen

Sie können auch messen, ob der bfcache verwendet wurde, um Seiten zu identifizieren, die den bfcache nicht nutzen. Dazu können Sie den Navigationstyp beim Seitenaufbau messen:

// Send a navigation_type when the page is first loaded.
gtag('event', 'page_view', {
   'navigation_type': performance.getEntriesByType('navigation')[0].type;
});

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

Berechnen Sie die bfcache-Trefferquote anhand der Anzahl der back_forward- und back_forward_cache-Navigationen.

Beachten Sie, dass es eine Reihe von Szenarien geben kann, die außerhalb der Kontrolle des Websiteinhabers liegen, wenn eine Rückwärts-/Vorwärtsnavigation den bfcache nicht verwendet, darunter:

• Der Nutzer schließt den Browser und startet ihn neu.
• Ein Nutzer dupliziert einen Tab,
• Der Nutzer schließt einen Tab und öffnet ihn wieder.

In einigen dieser Fälle wird der ursprüngliche Navigationstyp von einigen Browsern beibehalten. Daher wird möglicherweise der Typ back_forward angezeigt, obwohl es sich dabei nicht um Rückwärtsnavigationen handelt.

Auch ohne diese Ausschlüsse wird der bfcache nach einem bestimmten Zeitraum verworfen, um Arbeitsspeicher zu sparen.

Websiteinhaber sollten daher keine bfCache-Trefferquote von 100% für alle back_forward-Aufrufe erwarten. Die Messung ihres Verhältnisses kann jedoch nützlich sein, um Seiten zu identifizieren, bei denen die Seite selbst die bfcache-Nutzung bei einem hohen Anteil der Zurück- und Vorwärtsnavigationen verhindert.

Das Chrome-Team hat die NotRestoredReasons API hinzugefügt, um zu zeigen, warum Seiten bfcache nicht verwenden. So können Entwickler ihre bfcache-Trefferquoten verbessern. Das Chrome-Team hat Navigationstypen in CrUX hinzugefügt, sodass Sie die Anzahl der bfcache-Navigationen sehen können, ohne sie selbst zu messen.

Leistungsmessung

bfcache kann sich auch negativ auf die vor Ort erfassten Leistungsmesswerte auswirken, insbesondere auf Messwerte, die die Seitenladezeit messen.

Da bfcache-Navigationen eine vorhandene Seite wiederherstellen und keinen neuen Seitenaufbau initiieren, verringert sich die Gesamtzahl der erfassten Seitenladevorgänge, wenn bfcache aktiviert ist. Wichtig ist jedoch, dass die Seitenladevorgänge, die durch bfcache-Wiederherstellungen ersetzt werden, wahrscheinlich zu den schnellsten Seitenladevorgängen in Ihrem Dataset gehören würden. Das liegt daran, dass eine Navigation mit dem Zurück- oder Vorwärtspfeil per Definition wiederholte Besuche ist und dass das wiederholte Laden einer Seite im Allgemeinen schneller ist als das Laden von Seiten durch Erstbesucher (aufgrund von HTTP-Caching, wie bereits erwähnt).

Das führt zu weniger schnellen Seitenladevorgängen in Ihrem Dataset, was die Verteilung wahrscheinlich langsamer verfälscht – trotz der Tatsache, dass sich die Leistung für den Nutzer wahrscheinlich verbessert hat.

Es gibt verschiedene Möglichkeiten, mit diesem Problem umzugehen. Eine besteht darin, alle Messwerte zum Seitenaufbau mit dem entsprechenden Navigationstyp zu versehen: navigate, reload, back_forward oder prerender. Auf diese Weise können Sie die Leistung innerhalb dieser Navigationstypen weiter überwachen, auch wenn die Verteilung insgesamt negativ ist. Wir empfehlen diesen Ansatz für nicht nutzerbezogene Messwerte zum Seitenaufbau wie Time to First Byte (TTFB).

Bei nutzerorientierten Messwerten wie den Core Web Vitals ist es besser, einen Wert zu erfassen, der die Nutzererfahrung genauer widerspiegelt.

Auswirkungen auf Core Web Vitals

Mit Core Web Vitals wird die Nutzererfahrung auf einer Webseite anhand verschiedener Dimensionen gemessen (Ladegeschwindigkeit, Interaktivität, visuelle Stabilität). Da der bfCache-Wiederherstellungsprozess für Nutzer schneller erfolgt als der vollständige Seitenaufbau, ist es wichtig, dass sich dies in den Core Web Vitals-Messwerten widerspiegelt. Schließlich ist es für Nutzer egal, ob bfcache aktiviert ist oder nicht, sie interessiert nur, dass die Navigation schnell war!

Bei Tools wie dem Bericht zur Nutzererfahrung in Chrome, in denen Core Web Vitals-Messwerte erfasst und in Berichte aufgenommen werden, werden bfcache-Wiederherstellungen im Dataset als separate Seitenaufrufe behandelt. Es gibt zwar keine eigenen Web-Performance-APIs für die Messung dieser Messwerte nach bfcache-Wiederherstellungen, aber Sie können deren Werte mit vorhandenen Web-APIs schätzen:

• Verwenden Sie für Largest Contentful Paint (LCP) die Differenz zwischen dem Zeitstempel des pageshow-Ereignisses und dem Zeitstempel des nächsten dargestellten Frames, da alle Elemente im Frame gleichzeitig dargestellt werden. Bei einer bfcache-Wiederherstellung sind LCP und FCP identisch.
• Verwenden Sie für Interaction to Next Paint (INP) den vorhandenen Performance Observer, aber setzen Sie den aktuellen INP-Wert auf 0 zurück.
• Verwenden Sie für Cumulative Layout Shift (CLS) den vorhandenen Performance Observer, setzen Sie den aktuellen CLS-Wert jedoch auf 0 zurück.

Weitere Informationen dazu, wie sich der bfcache auf die einzelnen Messwerte auswirkt, finden Sie in den Leitfäden zu den Core Web Vitals-Messwerten. Ein konkretes Beispiel für die Implementierung der bfcache-Versionen dieser Messwerte findest du in der PR-Dokumentation zum Hinzufügen zur Webvitals-JS-Bibliothek.

Die JavaScript-Bibliothek von web-vitals unterstützt die bfcache-Wiederherstellung in den gemeldeten Messwerten.

Zusätzliche Ressourcen

• Firefox-Caching (bfcache in Firefox)
• Seiten-Cache (bfcache in Safari)
• Back-Forward-Cache: im Web preisgegebenes Verhalten (bfcache-Unterschiede zwischen Browsern)
• bfcache-Tester (Testen Sie, wie sich verschiedene APIs und Ereignisse auf den bfcache in Browsern auswirken.)
• Performance Game Changer: Browser-Back-Forward-Cache (Eine Fallstudie des Smashing Magazine, die deutliche Verbesserungen der Core Web Vitals durch die Aktivierung von bfcache zeigt)