Back-Forward-Cache notRestoredReasons API

Finden Sie heraus, welche Navigationen den bfcache nicht verwenden konnten und warum.

Chris Mills

Die notRestoredReasons-Property, die der Klasse PerformanceNavigationTiming hinzugefügt wurde, gibt Informationen darüber an, ob im Dokument vorhandene Frames bei der Navigation blockiert wurden und warum der bfcache blockiert wurde. Anhand dieser Informationen können Entwickler Seiten identifizieren, die aktualisiert werden müssen, um sie bfcache-kompatibel zu machen, wodurch die Websiteleistung verbessert wird.

Aktueller Status

Step Status
1. Erklärende Erklärung erstellen Abschließen
2. Ersten Entwurf der Spezifikation erstellen Nicht gestartet
3. Feedback einholen und Design iterieren In Bearbeitung
4. Ursprungstest Gestartet
5. Launch Nicht gestartet

bfcache notRestoredReasons API testen

Ab Version 109 ist die bfcache notRestoredReasons API als Ursprungstest in Chromium verfügbar. Aktualisierte Informationen zum Veröffentlichungszeitplan für diese Funktion finden Sie auf der entsprechenden Funktionsseite von ChromeStatus.com. Die Veröffentlichungsdaten der einzelnen Versionen finden Sie in der Chrome-Roadmap.

Sie können die bfcache notRestoredReasons API testen, indem Sie sich für den Ursprungstest registrieren und die API in Ihren Tests verwenden. Eine Anleitung zur Verwendung Ihres Tokens nach der Registrierung finden Sie unter An einem Ursprungstest teilnehmen.

Konzepte und Nutzung

Moderne Browser bieten eine Optimierungsfunktion für die Verlaufsnavigation, den Back-Forward-Cache (bfcache). Dadurch wird der Ladevorgang sofort durchgeführt, wenn Nutzende zu einer Seite zurückkehren, die sie bereits besucht haben. Es kann vorkommen, dass Seiten aus verschiedenen Gründen nicht in den bfcache gelangen oder gelöscht werden. Einige davon sind aufgrund einer Spezifikation erforderlich, andere sind jedoch spezifisch für die Browserimplementierungen.

Bisher gab es für Entwickler keine Möglichkeit, herauszufinden, warum der bfcache vor Ort für ihre Seiten blockiert wurde. Allerdings gab es einen Test in den Chrome-Entwicklertools. Die Klasse PerformanceNavigationTiming wurde um eine notRestoredReasons-Property erweitert, um das Monitoring im Außendienst zu ermöglichen. Dadurch wird ein Objekt zurückgegeben, das zugehörige Informationen zu allen im Dokument vorhandenen Frames enthält:

  • Details wie Frame id und name zur Identifizierung im HTML-Code.
  • Ob sie daran gehindert wurden, den bfcache zu verwenden.

  • Gründe, warum sie den bfcache nicht verwenden konnten.

    Dadurch können Entwickler Maßnahmen ergreifen, um diese Seiten bfcache-kompatibel zu machen, und so die Websiteleistung verbessern.

Beispiele

Eine PerformanceNavigationTiming-Instanz kann aus Features wie Performance.getEntriesByType() und PerformanceObserver abgerufen werden.

Sie können beispielsweise die folgende Funktion aufrufen, um alle PerformanceNavigationTiming-Objekte zurückzugeben, die derzeit in der Leistungszeitachse vorhanden sind, und ihre notRestoredReasons zu protokollieren:

function returnNRR() {
  const navEntries = performance.getEntriesByType("navigation");
  for (let i = 0; i < navEntries.length; i++) {
    console.log(`Navigation entry ${i}`);
    let navEntry = navEntries[i];
    console.log(navEntry.notRestoredReasons);
  }
}

Für die Navigation im Verlauf gibt die Eigenschaft PerformanceNavigationTiming.notRestoredReasons ein Objekt mit der folgenden Struktur zurück, die den Sperrstatus des Frames auf oberster Ebene darstellt:

{
  blocked: true,
  children: [],
  id: "",
  name: "",
  reasons: [ "Internal Error", "Unload handler" ],
  src: "",
  url: "a.com"
}

Folgende Eigenschaften sind verfügbar:

blocked
Ein boolescher Wert, der angibt, ob die aufgerufene Seite den bfcache nicht verwenden kann (true) oder nicht (false).
children
Ein Array mit Objekten, die den Blockierungsstatus aller Frames darstellen, die im Frame auf oberster Ebene eingebettet sind. Jedes Objekt hat die gleiche Struktur wie das übergeordnete Objekt. Auf diese Weise kann eine beliebige Anzahl von Ebenen eingebetteter Frames innerhalb des Objekts rekursiv dargestellt werden. Wenn der Frame keine untergeordneten Elemente hat, ist das Array leer.
id
Ein String, der den id-Attributwert des Frames darstellt (z. B. <iframe id="foo" src="...">). Wenn der Frame kein id hat, ist der Wert ein leerer String.
name
Ein String, der den name-Attributwert des Frames darstellt (z. B. <iframe name="bar" src="...">). Wenn der Frame kein name hat, ist der Wert ein leerer String.
reasons
Ein Array mit Strings, die jeweils einen Grund darstellen, warum die aufgerufene Seite den bfcache nicht verwenden konnte. Dafür gibt es viele verschiedene Gründe. Weitere Informationen finden Sie unten im Abschnitt Gründe für die Blockierung.
src
Ein String, der den Pfad zur Frame-Quelle darstellt (z. B. <iframe src="b.html">). Wenn der Frame keine src hat, ist der Wert ein leerer String.
url
Ein String, der die URL der aufgerufenen Seite darstellt.

Für PerformanceNavigationTiming-Objekte, die keine Verlaufsnavigationen darstellen, gibt das Attribut notRestoredReasons den Wert null zurück. Dies ist nützlich, um festzustellen, ob der bfcache für eine bestimmte Navigation relevant ist und ob notRestoredReasons nicht unterstützt wird. In diesem Fall würde undefined zurückgegeben.

Bf-Cache-Blockierung in Frames desselben Ursprungs melden

Wenn auf einer Seite Frames desselben Ursprungs eingebettet sind, enthält der zurückgegebene notRestoredReasons-Wert ein Objekt innerhalb der children-Eigenschaft, das den Blockierungsstatus jedes eingebetteten Frames darstellt.

Beispiel:

{
  blocked: false,
  children: [
    { url: "a.com", src: "b.a.com", id: "b", name: "b", blocked: false, reasons: [], children: [] },
    { url: "a.com", src: "c.a.com", id: "c", name: "c", blocked: true, reasons: [ "BroadcastChannel" ], children: [] },
    { url: "a.com", src: "d.a.com", id: "d", name: "d", blocked: false, reasons: [], children: [] }
  ],
  id: "",
  name: "",
  reasons: [],
  src: "",
  url:"a.com"
}

Berichterstellung zu bfcache-Blockierungen in ursprungsübergreifenden Frames

Wenn auf einer Seite ursprungsübergreifende Frames eingebettet sind, begrenzen wir die Menge an Informationen, die über sie weitergegeben werden, um die Offenlegung ursprungsübergreifender Informationen zu vermeiden. Wir fügen nur Informationen hinzu, die der äußeren Seite bereits bekannt sind, und ob die ursprungsübergreifende Unterstruktur den bfcache blockiert hat oder nicht. Wir fügen keine Blockierungsgründe oder Informationen zu niedrigeren Ebenen der Unterstruktur hinzu, selbst wenn einige Unterebenen denselben Ursprung haben.

Beispiel:

{
  blocked: false,
  children: [
    { url: "a.com", src: "c.a.com", id: "c", name: "c", blocked: true, reasons: [ "ScreenReader" ], children: [] },
    /* cross-origin frame */
    { url: "", src: "b.com", id: "d", name: "d", blocked: true, reasons: [], children: [] }
  ],
  id: "",
  name: "",
  reasons: [],
  src: "",
  url:"a.com"
}

Wenn mehrere ursprungsübergreifende Frames blockierende Gründe haben, wählen wir nach dem Zufallsprinzip einen ursprungsübergreifenden iFrame aus und geben an, ob bfcache blockiert wurde oder nicht. Für die restlichen Frames wird null als blocked-Wert gemeldet. Damit soll verhindert werden, dass böswillige Akteure auf Websites, auf die sie keine Kontrolle haben, Informationen zum Nutzerstatus ableiten, indem sie mehrere Frames von Drittanbietern in eine Seite einbetten und dann die Blockierungsinformationen von jedem einzelnen vergleichen.

{
  blocked: false,
  children: [
    /* cross-origin frames */
    {url: "", src: "b.com", id: "b", name: "b", blocked: null, reasons: [], children: []},
    {url: "", src: "c.com", id: "c", name: "c", blocked: true, reasons: [], children: []},
    {url: "", src: "d.com", id: "d", name: "d", blocked: null, reasons: [], children: []}
  ]
  id: "",
  name: "",
  reasons: [],
  src: "",
  url:"a.com"
}

Weitere Informationen zu Sicherheits- und Datenschutzaspekten finden Sie in der Erläuterung im Abschnitt Sicherheit und Datenschutz.

Gründe für die Blockierung

Wie bereits erwähnt, gibt es viele verschiedene Gründe für eine Blockierung. Wir haben eine praktische Tabelle zusammengestellt, in der alle Zeichenfolgen für die Gründe und deren Bedeutung aufgeführt sind.

Es gibt einige Hauptkategorien, die erwähnenswert sind:

  • Circumstantial: Bezieht sich auf Blockierungen, die nicht direkt mit dem Seitencode des Entwicklers zusammenhängen. Zum Beispiel ist eine zugehörige Komponente abgestürzt, ein Fehler beim Laden ist aufgetreten, die Seite befindet sich in einem temporären Status, der nicht im Cache gespeichert werden kann, der bfcache wurde aufgrund von unzureichendem Arbeitsspeicher deaktiviert oder ein Service Worker hat eine Aktion für die Seite vorgenommen, wodurch sie nicht im Cache gespeichert werden kann.
  • Extensions: Es gibt verschiedene Gründe für Meldungen im Zusammenhang mit Erweiterungen. Im Allgemeinen führen wir unter dem Grund „Erweiterungen“ einige unterschiedliche Gründe zusammen. Wir machen uns bewusst, welche Gründe es für das Blockieren von Erweiterungen gibt, da wir nicht allzu viele Informationen darüber preisgeben möchten, welche Erweiterungen der Nutzer installiert hat, welche auf der Seite aktiv sind, was er gerade tut usw.
  • PageSupportNeeded: Der Code des Entwicklers verwendet eine Webplattformfunktion, die ansonsten nicht durch den bfcache blockiert wird. Der Code befindet sich jedoch derzeit in einem bfcache-Blockierung. Beispielsweise hat die Seite derzeit einen BroadcastChannel mit registrierten Listenern oder eine offene IndexedDB-Verbindung. Oder die Seite hat einen unload-Handler registriert, der derzeit in einigen Browsern verhindert, dass der bfcache verwendet wird.
  • SupportPending: Im Code des Entwicklers wird eine Webplattformfunktion verwendet, durch die die Seite vom bfcache ausgeschlossen wird, z. B. die Web Serial API, die Web Authentication API, die File System Access API oder die Media Session API. Oder die Seite verwendet Cache-Control: no-store, wodurch derzeit in einigen Browsern der bfcache nicht verwendet wird. In dieser Kategorie wird auch gemeldet, dass außerhalb der Seite ein Tool vorhanden ist, das den bfcache blockiert, z. B. ein Screenreader oder der Passwortmanager von Chrome.

Feedback

Das Chromium-Team möchte mehr über Ihre Erfahrungen mit der notRestoredReasons API des bfcache erfahren.

Informationen zum API-Design

Gibt es etwas an der API, das nicht so funktioniert, wie Sie erwartet haben? Oder fehlen Methoden oder Eigenschaften, um Ihre Idee zu implementieren? Haben Sie eine Frage oder einen Kommentar zum Sicherheitsmodell? Melden Sie ein Spezifikationsproblem im entsprechenden [GitHub-Repository][Feedback] oder fügen Sie Ihre Gedanken zu einem vorhandenen Problem hinzu.

Problem mit der Implementierung melden

Haben Sie einen Fehler bei der Implementierung von Chromium gefunden? Oder unterscheidet sich die Implementierung von der Spezifikation? Melden Sie einen Fehler unter new.crbug.com. Geben Sie so viele Details wie möglich, eine einfache Anleitung zum Reproduzieren an und legen Sie die Komponente als UI > Browser > Navigation > bfcache fest. Glitch eignet sich perfekt, um schnelle und einfache Reproduzierungen zu teilen.

Unterstützung für die API zeigen

Möchten Sie die notRestoredReasons API von bfcache verwenden? Ihre öffentliche Unterstützung hilft dem Chromium-Team, Funktionen zu priorisieren und anderen Browseranbietern zu zeigen, wie wichtig es ist, sie zu unterstützen.

Senden Sie einen Tweet mit dem Hashtag #NotRestoredReasons an @ChromiumDev und teilen Sie uns mit, wo und wie Sie den Dienst verwenden.

Nützliche Links