Back-Forward-Cache

Philip Walton
Barry Pollard

Der Back-Forward-Cache (oder bfcache) ist eine Browseroptimierung, die eine sofortige Zurück- und Vorwärtsnavigation ermöglicht. Das Browsererlebnis wird dadurch erheblich verbessert, insbesondere für Nutzer mit langsameren Netzwerken oder langsamen Geräten.

Auf dieser Seite wird beschrieben, wie Sie Ihre Seiten in allen Browsern für den bfcache optimieren.

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 der bfcache für einen kleinen Prozentsatz der Nutzer in Chrome für websiteübergreifende Navigationen unter Android aktiviert. In 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 speichert, während der Nutzer die Seite verlässt. Da sich die gesamte Seite im Arbeitsspeicher befindet, kann der Browser sie schnell wiederherstellen, wenn der Nutzer später zurückkehren möchte, anstatt alle Netzwerkanfragen wiederholen zu müssen, die zum Laden der Seite erforderlich sind.

Im folgenden Video sehen Sie, wie viel bfcache die Navigation beschleunigen kann:

Mit bfcache werden Seiten beim Vor- und Zurückgehen viel schneller geladen.

Chrome-Nutzungsdaten zeigen, dass 1 von 10 Navigationen auf Computern und 1 von 5 Navigationen auf Mobilgeräten entweder zurück oder vorwärts erfolgen. Aus diesem Grund kann bfcache viel Zeit und Datennutzung einsparen.

Funktionsweise des „Cache“

Der von bfcache verwendete „Cache“ unterscheidet sich vom HTTP-Cache, der seine eigene Rolle bei der Beschleunigung wiederholter Navigationen spielt. „bfcache“ ist eine Momentaufnahme der gesamten Seite im Arbeitsspeicher, einschließlich des JavaScript-Heaps, während der HTTP-Cache nur die Antworten für zuvor gesendete Anfragen enthält. Da nur sehr selten alle Anfragen zum Laden einer Seite über den HTTP-Cache ausgeführt werden müssen, sind wiederholte Besuche mit der bfcache-Wiederherstellung immer schneller als die am besten optimierte Navigation ohne bfcache.

Das Erstellen eines Snapshots einer Seite im Arbeitsspeicher ist jedoch etwas kompliziert im Hinblick darauf, wie sich in Bearbeitung befindlichen Code am besten beibehalten lassen. Wie werden beispielsweise setTimeout()-Aufrufe verarbeitet, bei denen das Zeitlimit erreicht wird, während sich die Seite im bfcache befindet?

Die Antwort lautet, dass Browser alle ausstehenden Timer oder ungelösten Versprechen für Seiten im bfcache pausieren, 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 Versprechungen, ist dies ein relativ geringes Risiko, in anderen Fällen kann es zu verwirrendem oder unerwartetem Verhalten führen. Wenn der Browser beispielsweise eine Aufgabe pausiert, die für eine IndexedDB-Transaktion erforderlich ist, kann sich dies auf andere geöffnete Tabs im selben Ursprung auswirken, da auf dieselben IndexedDB-Datenbanken von mehreren Tabs gleichzeitig zugegriffen werden kann. Daher versuchen Browser normalerweise nicht, Seiten während einer IndexedDB-Transaktion oder bei der Verwendung von APIs, die andere Seiten betreffen könnten, im Cache zu speichern.

Weitere Informationen dazu, wie sich die API-Nutzung auf die bfcache-Berechtigung einer Seite auswirkt, findest du unter Seiten für bfcache optimieren.

bfcache und Single Page Apps (SPA)

Da bfcache mit vom Browser verwalteten Navigationen verwendet wird, funktioniert es nicht für „weiche Navigationen“ innerhalb einer Single-Page-Anwendung (SPA). bfcache kann jedoch hilfreich sein, wenn Sie eine SPA verlassen und zu ihr zurückkehren.

APIs zur Beobachtung des bfcache

Obwohl bfcache eine Optimierung ist, die Browser automatisch vornehmen, ist es für Entwickler wichtig, dass sie wissen, wann das passiert, damit sie ihre Seiten dafür optimieren und alle Messwerte oder Leistungsmessungen entsprechend anpassen können.

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

Die neueren Ereignisse Seitenlebenszyklus, freeze und resume, werden ebenfalls gesendet, wenn Seiten in den bfcache gelangen oder verlassen, sowie in einigen anderen Situationen, z. B. wenn ein Hintergrund-Tab einfriert, um die CPU-Nutzung zu minimieren. Diese Ereignisse werden nur in Chromium-basierten Browsern unterstützt.

Beobachten, wenn eine Seite aus dem bfcache wiederhergestellt wird

Das pageshow-Ereignis wird direkt nach dem load-Ereignis ausgelöst, wenn die Seite anfangs geladen wird, und jedes Mal, wenn die Seite aus dem bfcache wiederhergestellt wird. Das Ereignis pageshow hat die Property persisted, die den Wert true hat, wenn die Seite aus dem bfcache wiederhergestellt wurde, und andernfalls den Wert false. Mit dem Attribut persisted können Sie reguläre Seitenladevorgänge von 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 dem bfcache wiederhergestellt werden (direkt vor dem pageshow-Ereignis) und wenn ein Nutzer einen eingefrorenen Hintergrund-Tab noch einmal aufruft. Wenn Sie den Status einer Seite aktualisieren möchten, nachdem sie eingefroren ist (was Seiten im bfcache umfasst), können Sie das Ereignis resume verwenden. Wenn Sie jedoch die bfcache-Trefferquote Ihrer Website messen möchten, müssen Sie das Ereignis pageshow 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 Leistungsmessung.

Beobachten, wenn eine Seite in den bfcache eingeht

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 es false lautet, können Sie sicher sein, dass diese Seite nicht in den bfcache gelangen wird. Wenn persisted jedoch true ist, bedeutet das keine Garantie dafür, dass eine Seite im Cache gespeichert wird. Das bedeutet, dass der Browser die Seite intends, es aber möglicherweise noch andere Faktoren gibt, die das Speichern der Seite unmöglich machen.

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 jedoch nur, dass der Browser intends. Es kann sein, dass sie aus verschiedenen Gründen, die später erklärt werden, trotzdem verworfen werden muss.

Seiten für bfcache optimieren

Nicht alle Seiten werden im bfcache gespeichert, und selbst wenn eine Seite dort gespeichert wird, bleibt sie nicht auf unbestimmte Zeit dort. Auf den folgenden Seiten wird beschrieben, warum Seiten für den bfcache infrage kommen. Außerdem werden Best Practices empfohlen, um die Fähigkeit des Browsers zu maximieren, Ihre Seite im Cache zu speichern, um bessere Cache-Trefferraten zu erzielen.

pagehide anstelle von unload verwenden

Die wichtigste Methode zur Optimierung des bfcache-Werts in allen Browsern besteht darin, keine unload-Event-Listener zu verwenden. Warten Sie stattdessen auf pagehide, da dieses sowohl dann als auch jedes Mal ausgelöst wird, wenn eine Seite in den bfcache eindringt, als auch jedes Mal, wenn unload ausgelöst wird.

unload ist eine ältere Funktion, die ursprünglich jedes Mal ausgelöst wurde, wenn ein Nutzer eine Seite verlässt. Das ist nicht mehr der Fall. Viele Webseiten gehen aber immer noch davon aus, dass Browser unload auf diese Weise verwenden und dass nach dem Auslösen von unload die nicht geladene Seite nicht mehr vorhanden ist. Dies kann den bfcache beschädigen, wenn der Browser versucht, eine nicht geladene Seite im Cache zu speichern.

Auf dem Computer führen Chrome und Firefox Seiten mit unload-Listenern dazu, dass bfcache nicht verwendet werden kann. Dies verringert das Risiko, führt aber auch dazu, dass viele Seiten nicht im Cache gespeichert werden und daher viel langsamer neu geladen werden. Safari versucht zwar, einige Seiten mit unload-Ereignis-Listenern im Cache zu speichern, aber um mögliche Fehler zu minimieren, wird das unload-Ereignis nicht ausgeführt, wenn ein Nutzer die Seite verlässt. Dadurch sind unload-Listener unzuverlässig.

Auf Mobilgeräten versuchen Chrome und Safari, Seiten mit unload-Ereignis-Listenern im Cache zu speichern, da die Unzuverlässigkeit von unload auf Mobilgeräten das Risiko von Fehlern verringert. In Firefox für Mobilgeräte werden Seiten, die unload verwenden, als nicht für den bfcache geeignet behandelt. Eine Ausnahme bildet iOS, bei dem alle Browser die WebKit-Rendering-Engine verwenden müssen. Daher verhält es sich wie Safari.

Wenn du feststellen möchtest, ob JavaScript auf deinen Seiten unload verwendet, empfehlen wir die no-unload-listeners-Prüfung in Lighthouse.

Informationen zur geplanten Einstellung von unload in Chrome findest du unter Unload-Ereignis einstellen.

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

Einige Skripts und Erweiterungen von Drittanbietern können Unload-Handler zu einer Seite hinzufügen, wodurch die Website langsamer wird, da sie nicht für bfcache infrage kommt. Wenn Sie dies in Chrome 115 und höher verhindern möchten, verwenden Sie eine Berechtigungsrichtlinie.

Permission-Policy: unload()

beforeunload-Listener nur bedingt hinzufügen

Das beforeunload-Ereignis führt nicht dazu, dass Ihre Seiten den Back-Forward-Cache nicht verwenden können. Da er jedoch unzuverlässig ist, empfehlen wir, ihn nur zu verwenden, wenn es absolut notwendig ist.

Ein Beispiel für einen Anwendungsfall für beforeunload ist die Warnung eines Nutzers, dass nicht gespeicherte Änderungen verloren gehen, wenn er die Seite verlässt. In diesem Fall empfehlen wir, beforeunload-Listener nur dann hinzuzufügen, wenn ein Nutzer nicht gespeicherte Änderungen hat, und sie dann wie im folgenden Code sofort zu entfernen, nachdem die nicht gespeicherten Änderungen gespeichert wurden:

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-Webserver, der für Antworten festgelegt werden kann, und weist den Browser an, 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, haben Browser Seiten in der Vergangenheit aus dem bfcache ausgeschlossen, wenn Cache-Control: no-store in der Seitenressource (aber in keiner Unterressource) festgelegt ist. Chrome arbeitet daran, dieses Verhalten zu ändern, ohne den Datenschutz für Nutzer zu wahren. Standardmäßig können Seiten, die Cache-Control: no-store verwenden, jedoch nicht für den bfcache verwendet werden.

Verwenden Sie Cache-Control: no-store zur Optimierung für bfcache nur auf Seiten mit vertraulichen Informationen, die nicht im Cache gespeichert werden dürfen.

Für Seiten, die immer aktuelle Inhalte bereitstellen sollen, aber keine vertraulichen Informationen enthalten sollen, verwende Cache-Control: no-cache oder Cache-Control: max-age=0. Sie weisen den Browser an, den Inhalt vor dem Bereitstellen neu zu validieren, und sie wirken sich nicht auf die bfcache-Eignung einer Seite aus, da bei der Wiederherstellung einer Seite aus bfcache nicht der HTTP-Cache verwendet wird.

Wenn sich deine Inhalte minutengenau ändern, kannst du Aktualisierungen stattdessen mit dem Ereignis pageshow abrufen, um deine Seite wie im nächsten Abschnitt beschrieben auf dem neuesten Stand zu halten.

Veraltete oder sensible Daten nach der bfcache-Wiederherstellung aktualisieren

Wenn Ihre Website Daten zum Nutzerstatus speichert und diese Daten vertrauliche Nutzerinformationen enthalten, müssen sie nach der Wiederherstellung einer Seite aus dem bfcache aktualisiert oder gelöscht werden.

Wenn sich ein Nutzer beispielsweise auf einem öffentlichen Computer von einer Website abmeldet und der nächste Nutzer auf die Schaltfläche „Zurück“ klickt, können die veralteten Daten aus dem bfcache private Daten enthalten, die der erste Nutzer bei der Abmeldung gelöscht hatte.

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

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

Bei einigen Änderungen möchten Sie stattdessen möglicherweise eine vollständige Aktualisierung erzwingen und dabei den Navigationsverlauf für Vorwärtsnavigation beibehalten. Mit dem folgenden Code wird geprüft, ob im Ereignis pageshow ein websitespezifisches Cookie vorhanden ist. Wird es nicht gefunden, wird der Code aktualisiert:

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

Wiederherstellung von Anzeigen und bfcache

Es kann verlockend sein, auf den bfcache zu verzichten, damit Ihre Seite bei jeder Zurück- oder Vorwärtsnavigation neue Anzeigen schalten kann. Dies beeinträchtigt jedoch die Websiteleistung und führt nicht dauerhaft zu mehr Anzeigeninteraktionen. Wenn ein Nutzer beispielsweise zu einer Seite zurückkehren möchte, um auf eine Anzeige zu klicken, wird dann möglicherweise eine andere Anzeige eingeblendet, wenn die Seite neu geladen und nicht aus dem bfcache wiederhergestellt wird. Mithilfe von A/B-Tests lässt sich die beste Strategie für Ihre Seite ermitteln.

Bei Websites, bei denen Anzeigen nach der Wiederherstellung mit bfcache aktualisiert werden sollen, können Sie nur die Anzeigen für das Ereignis pageshow aktualisieren, wenn event.persisted den Wert true hat, ohne die Seitenleistung zu beeinträchtigen, wie in diesem Beispiel mit dem Google Publisher-Tag. Weitere Informationen zu Best Practices für Ihre Website erhalten Sie von Ihrem Anzeigenanbieter.

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, verweist die öffnende Seite auf das Fensterobjekt der geöffneten Seite.

Eine Seite mit einem window.opener-Verweis, der nicht null ist, stellt ein Sicherheitsrisiko dar und kann nicht sicher in den bfcache verschoben werden. Seiten, die versuchen, auf die Seite zuzugreifen, könnten dadurch beschädigt werden.

Verwenden Sie zur Vermeidung dieser Risiken rel="noopener", um das Erstellen von window.opener-Referenzen zu verhindern. Dies ist das Standardverhalten in allen modernen Browsern. Wenn Ihre Website ein Fenster öffnen und es mit window.postMessage() oder durch direkten Verweis auf das Fensterobjekt steuern muss, kommen weder das geöffnete Fenster noch das Öffnende für den bfcache infrage.

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

Wie bereits erwähnt, werden beim Speichern einer Seite in den bfcache alle geplanten JavaScript-Aufgaben angehalten und fortgesetzt, sobald die Seite aus dem Cache genommen wird.

Wenn diese geplanten JavaScript-Aufgaben nur auf DOM APIs oder andere APIs zugreifen, die auf der aktuellen Seite isoliert sind, verursacht das Pausieren dieser Aufgaben, während die Seite nicht für den Nutzer nicht sichtbar ist, keine Probleme.

Wenn diese Aufgaben jedoch mit APIs verbunden sind, auf die auch über andere Seiten im selben Ursprung zugegriffen werden kann (z. B. IndexedDB, Web Locks und WebSockets), kann das Pausieren dieser Seiten die Seiten beschädigen, da auf diesen Seiten verhindert wird, dass Code ausgeführt wird.

Daher versuchen einige Browser nicht, eine Seite in den bfcache zu speichern, wenn eines der folgenden Elemente vorliegt:

Wenn Ihre Seite eine dieser APIs verwendet, empfehlen wir dringend, die Verbindungen zu schließen und Beobachter während des pagehide- oder freeze-Ereignisses zu entfernen oder zu trennen. Dadurch kann der Browser die Seite sicher im Cache speichern, ohne dass andere geöffnete Tabs beeinträchtigt werden. Wenn die Seite dann aus dem bfcache wiederhergestellt wird, kannst du diese APIs während des pageshow- oder resume-Ereignisses noch einmal öffnen oder eine neue Verbindung herstellen.

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

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());

Prüfen, ob Ihre Seiten im Cache gespeichert werden können

Mit den Chrome-Entwicklertools kannst du deine Seiten testen, um zu prüfen, ob sie für bfcache optimiert sind, und Probleme identifizieren, die möglicherweise verhindern, dass sie geeignet sind.

So testen Sie eine Seite:

  1. Rufen Sie die Seite in Chrome auf.
  2. Gehen Sie in den Entwicklertools zu 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ückzukehren, um festzustellen, ob die Seite aus dem bfcache wiederhergestellt werden kann.
Bereich für den Back-Forward-Cache in den Entwicklertools
Im Bereich Back-Forward-Cache in den Entwicklertools

Wenn der Test erfolgreich war, wird im Bereich „Aus dem Back-Forward-Cache wiederhergestellt“ angezeigt. Ist die Anfrage nicht erfolgreich, wird im Steuerfeld der Grund dafür angegeben. Eine vollständige Liste der Gründe findest du unter Liste der Gründe für eine nicht wiederhergestellte Anfrage in Chromium.

Wenn der Grund etwas ist, das Sie als Entwickler beheben können, wird er im Steuerfeld als Umsetzbar gekennzeichnet.

Entwicklertools melden einen Fehler bei der Wiederherstellung einer Seite aus dem bfcache
Fehlgeschlagener bfcache-Test mit umsetzbarem Ergebnis

In diesem Bild ist die Seite aufgrund der Verwendung eines unload-Event-Listeners für den bfcache nicht zulässig. Sie können dies beheben, indem Sie von unload zu pagehide wechseln:

Das sollten Sie tun:
window.addEventListener('pagehide', ...);
Don'ts
window.addEventListener('unload', ...);

In Lighthouse 10.0 wurde außerdem eine bfcache-Prüfung hinzugefügt, die einen ähnlichen Test durchführt. Weitere Informationen finden Sie in den Dokumenten des bfcache-Audits.

Auswirkungen von bfcache auf Analysen und Leistungsmessungen

Wenn Sie die Besuche Ihrer Website mit einem Analysetool erfassen, werden Sie möglicherweise einen Rückgang der Gesamtzahl der erfassten Seitenaufrufe feststellen, da Chrome den bfcache für mehr Nutzer aktiviert.

Wahrscheinlich werden die Seitenaufrufe von anderen Browsern, in denen bfcache implementiert ist, bereits zu niedrig angegeben, da die meisten gängigen Analysebibliotheken die Wiederherstellung von bfcache nicht als neue Seitenaufrufe erfassen.

Wenn Sie bfcache-Wiederherstellungen in die Anzahl der Seitenaufrufe einbeziehen möchten, legen Sie Listener für das Ereignis pageshow fest und prüfen Sie das Attribut persisted.

Das folgende Beispiel zeigt, wie Sie das mit Google Analytics tun können. 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

Um Seiten zu identifizieren, die den bfcache noch nicht verwenden, messen Sie den Navigationstyp für Seitenladevorgänge so:

// 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-Navigationen und back_forward_cache-Navigationen.

Gründe dafür, dass bei der Zurück- oder Vorwärtsnavigation bfcache möglicherweise nicht verwendet wird, sind u. a. folgendes Nutzerverhalten:

  • Schließen Sie den Browser und starten Sie ihn neu.
  • Duplizieren eines Tabs.
  • Schließen und Wiederherstellen eines Tabs

In einigen dieser Fälle behält der Browser möglicherweise den ursprünglichen Navigationstyp bei und zeigt den Typ back_forward an, auch wenn es sich nicht um Vor- oder Zurücknavigation handelt. Selbst wenn Navigationstypen korrekt gemeldet werden, wird der bfcache regelmäßig verworfen, um Arbeitsspeicher zu sparen.

Daher können Websiteinhaber nicht bei allen back_forward-Navigationen mit einer BFCache-Trefferquote von 100% rechnen. Durch das Messen des Verhältnisses können jedoch Seiten identifiziert werden, die die Verwendung von bfcache verhindern.

Das Chrome-Team arbeitet an einer NotRestoredReasons API, um die Gründe für die Verwendung von bfcache auf Seiten aufzudecken, damit Entwickler ihre bfcache-Trefferraten verbessern können.

Leistungsmessung

bfcache kann sich auch negativ auf die im Feld erfassten Leistungsmesswerte auswirken, insbesondere auf Messwerte, die Seitenladezeiten messen.

Da bfcache-Navigationen eine vorhandene Seite wiederherstellen, anstatt einen neuen Seitenaufbau zu starten, verringert sich die Gesamtzahl der erfassten Seitenladevorgänge, wenn „bfcache“ aktiviert ist. Allerdings gehörten die bfcache-Ersatzseiten wahrscheinlich zu den schnellsten Seitenladevorgängen in Ihrem Dataset, da wiederholtes Laden von Seiten, einschließlich Vor- und Zurücknavigation, und aufgrund von HTTP-Caching in der Regel schneller als beim ersten Laden von Seiten ist. Das Aktivieren von bfcache kann also dazu führen, dass die Seiten in den Analysen langsamer geladen werden, obwohl die Websiteleistung für den Nutzer verbessert wurde.

Es gibt mehrere Möglichkeiten, mit diesem Problem umzugehen. Erstens: Annotieren Sie alle Messwerte zum Seitenaufbau mit dem entsprechenden Navigationstyp: navigate, reload, back_forward oder prerender. So können Sie die Leistung innerhalb dieser Navigationstypen weiterhin überwachen, auch wenn die Gesamtverteilung 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 melden, der die Nutzererfahrung genauer widerspiegelt.

Auswirkungen auf Core Web Vitals

Mit Core Web Vitals wird die Nutzerfreundlichkeit einer Webseite für eine Vielzahl von Dimensionen gemessen (Ladegeschwindigkeit, Interaktivität, visuelle Stabilität). Es ist wichtig, dass Ihre Core Web Vitals-Messwerte die Tatsache widerspiegeln, dass die bfcache-Wiederherstellungen so erfolgen, dass die Navigation schneller ist als der Standardseitenaufbau.

Tools wie der Bericht zur Nutzererfahrung in Chrome, mit denen Core Web Vitals-Messwerte erhoben und Berichte dazu erstellt werden, behandeln bfcache-Wiederherstellungen in ihrem Dataset als separate Seitenaufrufe. Es gibt zwar keine speziellen Web Performance APIs zum Messen dieser Messwerte nach der Wiederherstellung von bfcache, Sie können ihre Werte jedoch mit vorhandenen Web-APIs annähern:

  • Verwenden Sie für Largest Contentful Paint (LCP) die Differenz zwischen dem Zeitstempel des pageshow-Ereignisses und dem Zeitstempel des nächsten gerenderten 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) weiterhin den vorhandenen Performance Observer, aber setzen Sie den aktuellen CLS-Wert auf 0 zurück.
  • Verwenden Sie für Cumulative Layout Shift (CLS) weiterhin den vorhandenen Performance Observer, aber setzen Sie den aktuellen CLS-Wert auf 0 zurück.

Weitere Informationen dazu, wie sich der bfcache auf die einzelnen Messwerte auswirkt, finden Sie auf den Seiten mit den Messwertleitfäden der einzelnen Core Web Vitals. Ein konkretes Beispiel für die Implementierung von bfcache-Versionen dieser Messwerte finden Sie hier.

Weitere Ressourcen