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.

Als Webentwickler sollten Sie unbedingt 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 der bfcache für einen kleinen Prozentsatz der Nutzer auf Android-Geräten für die websiteübergreifende Navigation aktiviert. In nachfolgenden Releases wurde nach und nach zusätzliche Unterstützung eingeführt. Seit Version 96 ist der 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 der Browser sie schnell wiederherstellen, falls der Nutzer später zurückkehren möchte.

Wie oft haben Sie eine Website besucht und auf einen Link geklickt, um zu einer anderen Seite zu gelangen, und dann auf die Schaltfläche „Zurück“ geklickt? In diesem Moment kann bfcache einen großen Einfluss darauf haben, wie schnell die vorherige Seite geladen wird:

Sehen Sie sich dieses Video an, in dem gezeigt wird, wie sich bfcache in der Navigation beschleunigen lässt:

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

bfcache beschleunigt nicht nur die Navigation, es reduziert auch die Datennutzung, da Ressourcen nicht erneut heruntergeladen werden müssen.

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. Mit aktiviertem bfcache könnten Browser die Datenübertragung und den Zeitaufwand für das Laden von Milliarden von Webseiten pro Tag eliminieren!

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 ein Snapshot 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 es sehr selten ist, dass alle zum Laden einer Seite erforderlichen Anfragen aus dem HTTP-Cache erfüllt werden, sind wiederholte Besuche mit bfcache-Wiederherstellungen immer schneller als selbst die besten, nicht vom bfcache optimierten Navigationen.

Das Erstellen eines Snapshots einer Seite im Speicher 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 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 relativ gering, in anderen Fällen kann es zu verwirrendem oder unerwartetem Verhalten führen. Wenn der Browser beispielsweise eine Aufgabe pausiert, die im Rahmen einer IndexedDB-Transaktion erforderlich ist, kann sich dies auf andere geöffnete Tabs im selben Ursprung auswirken, da auf dieselben IndexedDB-Datenbanken gleichzeitig von mehreren Tabs zugegriffen werden kann. Daher versuchen Browser in der Regel nicht, Seiten während einer IndexedDB-Transaktion oder der Verwendung von APIs im Cache zu speichern, die sich auf andere Seiten auswirken könnten.

Weitere Informationen dazu, wie sich verschiedene API-Nutzung auf die bfcache-Verfügbarkeit einer Seite auswirkt, finden Sie unter Seiten für bfcache optimieren.

Der bfcache und die 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 wieder zurückgehen, geht der Browser im iFrame statt im Hauptframe „zurück“. Die Rücknavigation innerhalb des iFrames verwendet jedoch nicht den bfcache.

Der Hauptframe kann auch daran gehindert werden, den bfcache zu verwenden, wenn ein eingebetteter iFrame APIs verwendet, die dies blockieren. Um dies zu verhindern, kannst du die Berechtigungsrichtlinie für den Hauptframe oder die Verwendung von sandbox-Attributen verwenden.

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 helfen, wenn Sie zu einer SPA zurückkehren, anstatt die App von Anfang an komplett neu zu initialisieren.

APIs zur Beobachtung des bfcache

Obwohl bfcache eine Optimierung ist, die Browser automatisch durchführen, 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 auch ausgelöst, wenn Seiten in den bfcache gelangen oder diesen verlassen, sowie in einigen anderen Situationen, z. B. wenn ein Hintergrundtab eingefroren ist, um die CPU-Auslastung 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 erstmals geladen wird, und jedes Mal, wenn die Seite aus dem bfcache wiederhergestellt wird. Das pageshow-Ereignis hat eine persisted-Eigenschaft, die true ist, wenn die Seite aus dem bfcache wiederhergestellt wurde, und andernfalls false. Sie können das Attribut persisted verwenden, um normale Seitenladevorgänge von bfcache-Wiederherstellungen zu 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. Möchten Sie jedoch die bfcache-Trefferquote Ihrer Website messen, 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, 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 aber 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 unbegrenzt dort. Es ist wichtig, dass Entwickler verstehen, warum Seiten für den bfcache infrage kommen (und nicht geeignet sind), um ihre Cache-Trefferraten zu maximieren.

In den folgenden Abschnitten werden die Best Practices beschrieben, die dafür sorgen, dass der Browser Ihre Seiten im Cache speichern kann.

unload-Ereignis nie verwenden

Die wichtigste Methode zur Optimierung des bfcache-Werts in allen Browsern besteht darin, nie das unload-Ereignis zu verwenden. Niemals!

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

Browser stehen also vor einem Dilemma. Sie müssen zwischen etwas wählen, das die Nutzererfahrung verbessern kann, aber sie könnten auch Gefahr laufen, die Seite zu stören.

Auf dem Computer haben Chrome und Firefox Seiten dazu entschlossen, den bfcache nicht zu verwenden, wenn sie einen unload-Listener hinzufügen. Dies ist zwar weniger riskant, erfüllt aber viele Seiten nicht. Safari versucht, einige Seiten mit einem unload-Ereignis-Listener im Cache zu speichern. Um mögliche Fehler zu minimieren, 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-Ereignis-Listener im Cache zu speichern. Das liegt daran, dass das unload-Ereignis auf Mobilgeräten immer extrem unzuverlässig war. Das liegt daran, dass das Risiko von Fehlern geringer ist. Firefox behandelt Seiten, die unload verwenden, als nicht für den bfcache geeignet. Eine Ausnahme bildet iOS. Hier müssen alle Browser das WebKit-Rendering-Modul verwenden. Daher verhält es sich wie Safari.

Verwenden Sie statt des unload-Ereignisses das pagehide-Ereignis. Das pagehide-Ereignis wird in allen Fällen ausgelöst, in denen das unload-Ereignis ausgelöst wird, sowie auch beim Speichern einer Seite in den bfcache.

Tatsächlich gibt es in Lighthouse eine no-unload-listeners-Prüfung, bei der Entwickler gewarnt werden, wenn JavaScript auf ihren Seiten (auch das von Drittanbieterbibliotheken) einen unload-Event-Listener hinzufügt.

Aufgrund der Unzuverlässigkeit und der Leistungsbeeinträchtigung für den bfcache wird in Chrome das unload-Ereignis eingestellt.

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

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

Permission-Policy: unload()

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

beforeunload-Listener nur bedingt hinzufügen

Das beforeunload-Ereignis führt nicht dazu, dass deine Seiten im bfcache von modernen Browsern nicht für den bfcache verwendet werden können. Bisher war das aber der Fall und es ist immer noch unzuverlässig. Daher solltest du es nur verwenden, wenn es absolut notwendig ist.

Im Gegensatz zum unload-Ereignis kann beforeunload jedoch legitim verwendet werden. Wenn Sie beispielsweise den Nutzer warnen möchten, dass er nicht gespeicherte Änderungen hat, gehen diese verloren, wenn er die Seite verlässt. In diesem Fall wird empfohlen, beforeunload-Listener nur dann hinzuzufügen, wenn ein Nutzer nicht gespeicherte Änderungen hat, und sie dann sofort zu entfernen, nachdem die nicht gespeicherten Änderungen gespeichert wurden.

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. Er 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 sich bisher entschieden, die Seite nicht im bfcache zu speichern, wenn Cache-Control: no-store auf der Seitenressource selbst (im Gegensatz zu einer Unterressource) festgelegt ist. Wir arbeiten derzeit daran, dieses Verhalten für Chrome auf datenschutzfreundliche Weise zu ändern. Derzeit können jedoch Seiten, auf denen Cache-Control: no-store verwendet wird, nicht den bfcache verwendet werden.

Da Cache-Control: no-store die Eignung einer Seite für den bfcache einschränkt, sollte sie nur auf Seiten festgelegt werden, die vertrauliche Informationen enthalten, bei denen ein Caching jeglicher Art nie angemessen ist.

Für Seiten, die immer aktuelle Inhalte bereitstellen müssen und die keine vertraulichen Informationen enthalten, verwende Cache-Control: no-cache oder Cache-Control: max-age=0. Diese Anweisungen weisen den Browser an, den Inhalt vor der Bereitstellung erneut zu validieren, und wirken sich nicht auf die bfcache-Eignung einer Seite aus.

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

Dies ist wahrscheinlich immer noch eine bessere Nutzererfahrung, da die bfcache-Wiederherstellungen sofort erfolgen und da Seiten nicht sehr lange im bfcache verbleiben, ist es unwahrscheinlich, dass der Inhalt veraltet ist. Falls sich Ihre Inhalte jedoch minutengenau ändern, können Sie Aktualisierungen mit dem pageshow-Ereignis abrufen, wie im nächsten Abschnitt beschrieben.

Veraltete oder sensible Daten nach der bfcache-Wiederherstellung aktualisieren

Wenn Ihre Website den Nutzerstatus behält – insbesondere vertrauliche Nutzerdaten –, müssen die Daten nach dem Wiederherstellen einer Seite aus dem bfcache aktualisiert oder gelöscht werden.

Wenn ein Nutzer beispielsweise zu einer Zahlungsseite navigiert und dann seinen Einkaufswagen aktualisiert, könnten über eine Zurück-Navigation veraltete Informationen angezeigt werden, wenn eine veraltete Seite aus dem bfcache wiederhergestellt wird.

Ein weiteres, kritischer wäre es, 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 offengelegt werden, von denen der Nutzer bei der Abmeldung angenommen wurde, dass sie gelöscht wurden.

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

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

Im Idealfall aktualisieren Sie den vorhandenen Inhalt, aber bei einigen Änderungen kann ein vollständiges Aktualisieren erzwungen werden. Mit dem folgenden Code wird geprüft, ob im Ereignis pageshow ein websitespezifisches Cookie vorhanden ist. Wird kein Cookie 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();
  }
});

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

Wiederherstellung von Anzeigen und bfcache

Es mag verlockend sein, auf die Verwendung von bfcache zu verzichten, um bei jeder Zurück-Vorwärts-Navigation einen neuen Satz von Anzeigen auszuliefern. Allerdings wirkt sich dies positiv auf die Leistung aus, es ist jedoch fraglich, ob ein solches Verhalten zu einer höheren Anzeigeninteraktion führt. Die Nutzer haben möglicherweise eine Anzeige bemerkt, auf die sie zurückkehren wollten, indem sie sie jedoch neu geladen haben, anstatt sie aus dem bfcache wiederherzustellen. Dieses Szenario sollte möglichst mit einem A/B-Test getestet werden, bevor Annahmen getroffen werden.

Bei Websites, die Anzeigen nach der Wiederherstellung mit dem bfcache aktualisieren möchten, kann die Aktualisierung nur der Anzeigen für das Ereignis pageshow erfolgen, wenn event.persisted den Wert true hat, um dies ohne Auswirkungen auf die Seitenleistung zu tun. Wenden Sie sich an Ihren Anzeigenanbieter. Hier ist ein Beispiel dafür, wie Sie das Google Publisher-Tag verwenden können.

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

Eine Seite mit einer window.opener-Referenz, die nicht null ist, stellt nicht nur ein Sicherheitsrisiko dar, sondern kann auch nicht sicher in den bfcache verschoben werden. Dies kann nämlich versuchen, auf die Seite zuzugreifen.

Daher sollte das Erstellen von window.opener-Referenzen vermieden werden. Dazu kannst du nach Möglichkeit rel="noopener" verwenden. Hinweis: Diese Option ist jetzt in allen modernen Browsern die Standardeinstellung. Wenn auf Ihrer Website ein Fenster geöffnet und es über window.postMessage() gesteuert oder direkt auf das Fensterobjekt verwiesen werden muss, können weder das geöffnete Fenster noch das Öffnende den bfcache nutzen.

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 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.

Sind diese Aufgaben jedoch mit APIs verbunden, auf die auch von anderen Seiten im selben Ursprung zugegriffen werden kann (z. B. IndexedDB, Web Locks, WebSockets), kann dies problematisch sein, da das Pausieren dieser Aufgaben unter Umständen verhindert, dass Code auf anderen Tabs 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 fetch() oder XMLHttpRequest
• Seiten mit einer offenen WebSocket- oder WebRTC-Verbindung

Wenn Ihre Seite eine dieser APIs verwendet, empfehlen wir Ihnen dringend, 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, können Sie diese APIs während des pageshow- oder resume-Ereignisses wieder öffnen oder eine neue Verbindung herstellen.

Das folgende Beispiel zeigt, wie Sie sicherstellen können, dass Seiten, auf denen IndexedDB verwendet wird, den bfcache verwenden können. Dazu schließen Sie eine offene Verbindung im pagehide-Event-Listener:

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 können Sie Ihre Seiten testen und prüfen, ob sie für den bfcache optimiert sind. Außerdem können Sie 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.

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. Wenn Sie als Entwickler den Grund beheben können, wird er im Steuerfeld als Umsetzbar gekennzeichnet.

In diesem Beispiel führt die Verwendung eines unload-Event-Listeners dazu, dass die Seite für den bfcache nicht geeignet ist. Sie können das Problem beheben, indem Sie von unload zu pagehide wechseln:

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

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 auf Ihrer Website mit einem Analysetool messen, werden Sie möglicherweise einen Rückgang der Gesamtzahl der 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 viele gängige Analysebibliotheken die Wiederherstellung von bfcache nicht als neue Seitenaufrufe messen.

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

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

// 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.

Es gibt verschiedene Situationen, in denen der bfcache nicht vom Websiteinhaber verwendet wird, da er nicht die Kontrolle über die Website hat:

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

In einigen dieser Fälle wird der ursprüngliche Navigationstyp von einigen Browsern möglicherweise beibehalten und der Typ back_forward angezeigt, auch wenn es sich nicht um Vorwärts- und Rückwärtsnavigation handelt.

Selbst ohne diese Ausschlüsse wird der bfcache nach einer bestimmten Zeit verworfen, um Arbeitsspeicher zu sparen.

Websiteinhaber sollten also nicht bei allen back_forward-Navigationen mit einer bfcache-Trefferquote von 100% rechnen. Die Messung des Verhältnisses kann jedoch nützlich sein, um Seiten zu ermitteln, auf denen die Seite selbst die Verwendung des bfcache für einen hohen Anteil der Vor- und Zurücknavigation verhindert.

Das Chrome-Team hat die NotRestoredReasons API hinzugefügt, um die Gründe dafür zu ermitteln, warum Seiten den bfcache nicht verwenden, damit Entwickler ihre bfcache-Trefferraten verbessern können. Das Chrome-Team hat außerdem Navigationstypen zu CrUX hinzugefügt, damit die Anzahl der bfcache-Navigationen auch ohne eigene Messungen angezeigt werden kann.

Leistungsmessung

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

Da bfcache-Navigationen eine vorhandene Seite wiederherstellen, anstatt einen neuen Seitenaufbau einzuleiten, wird die Gesamtzahl der erfassten Seitenladevorgänge bei Aktivierung von bfcache abnehmen. Wichtig ist jedoch, dass die durch bfcache-Wiederherstellungen ersetzten Seitenladevorgänge wahrscheinlich zu den schnellsten Seitenladevorgängen in Ihrem Dataset gehörten. Das liegt daran, dass das Zurück- und Vorwärtsnavigationen per Definition wiederholte Besuche sind und dass wiederholte Seitenladevorgänge bei erstmaligen Besuchern aufgrund von HTTP-Caching in der Regel schneller erfolgen als zuvor.

Dies führt zu weniger schnellen Seitenladevorgängen in Ihrem Dataset, was die Verteilung wahrscheinlich langsamer verzerren wird – trotz der Tatsache, dass sich die Leistung für die Nutzenden wahrscheinlich verbessert hat!

Es gibt mehrere Möglichkeiten, mit diesem Problem umzugehen. Erstens: Alle Messwerte zum Seitenaufbau mit ihrem jeweiligen Navigationstyp versehen: 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 erfassen, der die Nutzererfahrung genauer widerspiegelt.

Auswirkungen auf Core Web Vitals

Mit den Core Web Vitals wird die Nutzerfreundlichkeit einer Webseite anhand verschiedener Dimensionen gemessen (Ladegeschwindigkeit, Interaktivität, visuelle Stabilität). Da der bfcache-Nutzer eine schnellere Navigation als vollständige Seitenladevorgänge aufweist, ist es wichtig, dass sich dies in den Core Web Vitals-Messwerten widerspiegelt. Schließlich ist für einen Nutzer nicht wichtig, ob der bfcache aktiviert ist, sondern nur die Geschwindigkeit der Navigation.

Tools wie der Bericht zur Nutzererfahrung in Chrome, die Core Web Vitals-Messwerte erheben und entsprechende Berichte erstellen, behandeln bfcache-Wiederherstellungen in ihrem Datensatz als separate Seitenaufrufe. Und obwohl es keine speziellen Web Performance-APIs für die Messung dieser Messwerte nach der Wiederherstellung von bfcache gibt, können Sie ihre Werte 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 INP-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 der Core Web Vitals-Messwerte zu Messwerten. Ein konkretes Beispiel für die Implementierung von bfcache-Versionen dieser Messwerte finden Sie hier.

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

Weitere Ressourcen

• Cache-Cache für Firefox (bfcache in Firefox)
• Seiten-Cache (bfcache in Safari)
• Back-Forward-Cache: Verhalten im Web (bfcache-Unterschiede zwischen Browsern)
• bfcache-Tester (testen, 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 Core Web Vitals-Verbesserungen durch Aktivieren von bfcache zeigt)