Verwenden von Deferred Fetch

berblick

Entwickler mssen oft Daten zurck an den Server senden (oder signalisieren), insbesondere am Ende eines Besuchs eines Benutzers auf einer Seite zum Beispiel fr Analysedienste. Dafr gibt es mehrere Wege: vom Hinzufgen von ein-Pixel-groen <img>-Elementen zur Seite, ber XMLHttpRequest, bis hin zur dedizierten Beacon-API und der Fetch-API selbst.

Das Problem ist jedoch, dass alle diese Methoden bei der Zuverlssigkeit fr Signalisierung am Ende des Besuchs Schwchen aufweisen. Whrend die Beacon-API und die keepalive-Eigenschaft der Fetch-API Daten senden, selbst wenn das Dokument zerstrt wird (so gut es in dieser Situation geht), lst dies nur einen Teil des Problems.

Der andere schwierigere Teil besteht darin, zu entscheiden, wann die Daten gesendet werden sollen, da es keinen idealen Zeitpunkt im Lebenszyklus einer Seite gibt, um den JavaScript-Aufruf zum Senden des Beacons zu machen:

• Die Ereignisse unload und beforeunload sind unzuverlssig und werden von mehreren groen Browsern ignoriert.
• Die Ereignisse pagehide und visibilitychange sind zuverlssiger, haben jedoch auf Mobilplattformen immer noch Probleme.

Das bedeutet, dass Entwickler, die Daten zuverlssig ber ein Beacon senden mchten, dies hufiger tun mssen als ideal wre. Zum Beispiel knnten sie ein Beacon bei jeder nderung senden, selbst wenn der endgltige Wert fr die Seite noch nicht erreicht wurde. Dies hat Kosten in der Netzwerknutzung, Serververarbeitung und dem Zusammenfhren oder Verwerfen veralteter Beacons auf dem Server.

Alternativ knnen Entwickler entscheiden, ein gewisses Ma an fehlenden Daten zu akzeptieren entweder durch:

• Beaconing nach einer bestimmten Cut-off-Zeit und das sptere Sammeln von Daten zu unterlassen.
• Beaconing am Ende des Seitenlebenszyklus, aber zu akzeptieren, dass dies manchmal nicht zuverlssig sein wird.

Die fetchLater()-API erweitert die Fetch-API, um das Einrichten von Abrufanfragen im Voraus zu ermglichen. Diese verzgerten Abrufe knnen aktualisiert werden, bevor sie gesendet wurden, sodass die Nutzlast die neuesten Daten widerspiegelt, die gesendet werden sollen.

Der Browser sendet dann das Beacon, wenn der Tab geschlossen oder navigiert wird, oder nach einer festgelegten Zeitspanne, falls angegeben. Dies vermeidet das Senden mehrerer Beacons, stellt jedoch dennoch ein zuverlssiges Beacon innerhalb vernnftiger Erwartungen sicher (d.h. ausgenommen, wenn der Browserprozess whrend eines Absturzes unerwartet beendet wird).

Verzgerte Abrufe knnen auch mit einem AbortController abgebrochen werden, wenn sie nicht mehr bentigt werden, um weitere unntige Kosten zu vermeiden.

Quoten

Verzgerte Abrufe werden gesammelt und gesendet, sobald der Tab geschlossen wird; in diesem Moment gibt es keine Mglichkeit fr den Benutzer, sie abzubrechen. Um Situationen zu vermeiden, in denen Dokumente diese Bandbreite missbrauchen, um unbegrenzte Datenmengen ber das Netzwerk zu senden, wird die Gesamtquote fr ein Top-Level-Dokument auf 640 KiB begrenzt.

Aufrufer von fetchLater() sollten defensiv sein und in fast allen Fllen QuotaExceededError-Fehler abfangen, insbesondere wenn sie Drittanbieter-JavaScript einbetten.

Da diese Beschrnkung die Bandbreite fr verzgerte Abrufe zu einer knappen Ressource macht, die zwischen mehreren Meldungs-Ursprngen (beispielsweise mehreren RUM-Bibliotheken) und Unterrahmen aus mehreren Ursprngen aufgeteilt werden muss, bietet die Plattform eine vernnftige Standardaufteilung dieser Quote. Darber hinaus bietet sie deferred-fetch und deferred-fetch-minimal Berechtigungsrichtlinien-Direktiven, um eine andere Aufteilung bei Bedarf zu ermglichen.

Die Gesamtquote fr fetchLater() betrgt 640 KiB pro Dokument. Standardmig ist diese in eine 512 KiB Top-Level-Quote und eine 128 KiB geteilte Quote aufgeteilt:

• Die 512 KiB Top-Level-Quote ist standardmig fr alle fetchLater()-Anfragen reserviert, die vom Top-Level-Dokument und direkten Unterrahmen gemacht werden, die diesen Ursprung verwenden.
• Die 128 KiB geteilte Quote ist standardmig fr alle fetchLater()-Anfragen reserviert, die in Cross-Origin-Unterrahmen gemacht werden (z. B. <iframe>, <object>, <embed> und <frame>-Elemente).

fetchLater()-Anfragen knnen an jede URL gesendet werden und sind nicht auf denselben Ursprung wie das Dokument oder den Unterrahmen beschrnkt, daher ist es wichtig zu unterscheiden zwischen Anfragen, die im Top-Level-Dokumentinhalt (ob fr ursprungsfremde oder erste Partei) und solche, die in Unterrahmen gemacht werden.

Zum Beispiel, wenn ein Top-Level-a.com-Dokument ein <script> enthlt, das eine fetchLater()-Anfrage an analytics.example.com macht, wre diese Anfrage durch das Top-Level-Limit von 512 KiB eingeschrnkt. Andersherum, wenn das Top-Level-Dokument ein <iframe> mit einer Quelle von analytics.example.com einbettet, das eine fetchLater()-Anfrage macht, wre diese Anfrage durch das 128 KiB-Limit eingeschrnkt.

Quotengrenzen nach Meldungs-Ursprung und Unterrahmen

Nur 64 KiB der Top-Level-512 KiB-Quote knnen gleichzeitig fr denselben Meldungs-Ursprung (den Ursprung der Anforderungs-URL) genutzt werden. Dies verhindert, dass Drittanbieter-Bibliotheken Quoten opportunistisch reservieren, bevor sie Daten zu senden haben.

Jeder Cross-Origin-Unterrahmen erhlt standardmig eine 8 KiB-Quote aus der geteilten 128 KiB-Quote, die zugeteilt wird, wenn der Unterrahmen dem DOM hinzugefgt wird (ob fetchLater() in diesem Unterrahmen verwendet wird oder nicht). Dies bedeutet, dass im Allgemeinen nur die ersten 16 Cross-Origin-Unterrahmen auf einer Seite fetchLater() verwenden knnen, da sie die 128 KiB-Quote ausschpfen.

Erhhung der Unterrahmenquoten durch Teilen der Top-Level-Quote

Der Top-Level-Ursprung kann ausgewhlten Cross-Origin-Unterrahmen eine erhhte Quote von 64 KiB gewhren, die aus dem greren Top-Level-512 KiB-Limit genommen wird. Dies geschieht, indem diese Ursprnge in der deferred-fetch-Berechtigungsrichtlinie aufgelistet werden. Dies wird zugeteilt, wenn der Unterrahmen dem DOM hinzugefgt wird, und hinterlsst weniger Quote fr das Top-Level-Dokument und direkte gleiche Ursprungsrahmen. Mehrere gleiche Ursprungs-Subdomains knnen jeweils eine 64 KiB-Quote erhalten.

Einschrnkung der geteilten Quote

Der Top-Level-Ursprung kann auch die 128 KiB-geteilte Quote auf benannte Cross-Origin-Unterrahmen beschrnken, indem diese Ursprnge in der deferred-fetch-minimal-Berechtigungsrichtlinie aufgelistet werden. Es kann auch die gesamte 128 KiB Standardunterrahmenquote widerrufen und stattdessen die volle 640 KiB-Quote fr sich selbst und alle benannten deferred-fetch-Cross-Ursprnge behalten, indem die deferred-fetch-minimal-Berechtigungsrichtlinie auf () gesetzt wird.

Quoten an Unterrahmen von Unterrahmen delegieren

Standardmig werden Unterrahmen von Unterrahmen keine Quote zugewiesen und knnen somit fetchLater() nicht verwenden. Unterrahmen, die die erhhte 64 KiB-Quote erhalten, knnen die volle 64 KiB-Quote an weitere Unterrahmen delegieren und ihnen die Verwendung von fetchLater() erlauben, indem sie ihre eigene deferred-fetch-Berechtigungsrichtlinie setzen. Sie knnen ihre volle Quote nur auf weitere Unterrahmen und nicht nur Teile davon delegieren und knnen keine neuen Quoten festlegen. Unterrahmen, die die minimale 8 KiB-Quote verwenden, knnen keine Quoten an Unterrahmen delegieren. Um eine Quote zu erhalten, mssen Sub-Subrahmen sowohl im Top-Level- als auch im Unterrahmen deferred-fetch-Permissions-Policy-Direktiven enthalten sein.

Wenn Quoten berschritten werden

Wenn Quoten berschritten werden, wird ein QuotaExceededError geworfen, wenn die fetchLater()-Methode aufgerufen wird, um den verzgerten Abruf zu initiieren.

Berechtigungsrichtlinienprfungen sind von Quotenberprfungen nicht unterscheidbar. Das Aufrufen von fetchLater() wird einen QuotaExceededError sowohl dann werfen, wenn die Quote tatschlich berschritten wurde als auch wenn die Quote fr diesen Ursprung ber eine Berechtigungsrichtlinie eingeschrnkt wurde.

Aufrufer von fetchLater() sollten defensiv sein und in fast allen Fllen QuotaExceededError-Fehler abfangen, insbesondere wenn sie Drittanbieter-JavaScript einbetten.

Quotenbeispiele

Ausschpfen der minimalen Quote

Permissions-Policy: deferred-fetch=(self "https://b.com")

1. Ein <iframe src="https://b.com/page"> erhlt 64 KiB, wenn es dem Top-Level-Dokument hinzugefgt wird, aus dem Top-Level 512 KiB Limit.
2. Ein <iframe src="https://c.com/page"> ist nicht aufgelistet und erhlt somit 8 KiB, wenn es dem Top-Level-Dokument aus dem geteilten 128 KiB-Limit hinzugefgt wird.
3. 15 weitere Cross-Origin-Iframes wrden jeweils 8 KiB erhalten, wenn sie dem Top-Level-Dokument hinzugefgt werden (hnlich wie c.com).
4. Das nchste Cross-Origin-Iframe wrde keine Quote erhalten.
5. Wenn eines der Cross-Origin-Iframes entfernt wird, werden seine verzgerten Abrufe gesendet.
6. Das nchste Cross-Origin-Iframe wrde eine 8 KiB-Quote erhalten, da wieder eine Quote verfgbar ist.

Widerrufen der Begrenzung der minimalen Quote auf benannte Ursprnge

Permissions-Policy: deferred-fetch-minimal=("https://b.com")

1. Ein <iframe src="https://b.com/page"> erhlt 8 KiB, wenn es dem Top-Level-Dokument hinzugefgt wird.
2. Ein <iframe src="https://c.com/page"> erhlt keine Quote, wenn es dem Top-Level-Dokument hinzugefgt wird.
3. Das Top-Level-Dokument und seine same-origin Nachkommen knnen bis zu 512 KiB verwenden.

Vollstndiger Widerruf der minimalen Quote mit Top-Level-Ausnahmen

Permissions-Policy: deferred-fetch=(self "https://b.com")
Permissions-Policy: deferred-fetch-minimal=()

1. Ein <iframe src="https://b.com/page"> erhlt 64 KiB, wenn es dem Top-Level-Dokument hinzugefgt wird.
2. Ein <iframe src="https://c.com/page"> erhlt keine Quote, wenn es dem Top-Level-Dokument hinzugefgt wird.
3. Das Top-Level-Dokument und seine same-origin Nachkommen knnen bis zu volle 640 KiB verwenden, das jedoch auf 574 KiB reduziert wird, wenn ein b.com-Subrahmen erstellt wird (oder noch weniger, wenn mehrere b.com-Subrahmen erstellt werden, von denen jeder eine 64 KiB-Quote erhlt).

Vollstndiger Widerruf der minimalen Quote ohne Ausnahmen

Permissions-Policy: deferred-fetch-minimal=()

1. Das Top-Level-Dokument und seine same-origin Nachkommen knnen die volle 640 KiB nutzen.
2. Unterrahmen wird keine Quote zugewiesen und knnen fetchLater() nicht verwenden.

Same-origin Unterrahmen teilen sich die Quote mit dem Top-Level und knnen an Unterrahmen delegieren

Angenommen, ein Top-Level-Dokument auf a.com, das einen Unterrahmen von a.com einbettet, der einen Unterrahmen von b.com einbettet, und keine expliziten Berechtigungsrichtlinien.

1. Das Top-Level-Dokument von a.com hat die Standard-512 KiB-Quote.
2. <iframe src="https://a.com/embed"> teilt die 512 KiB-Quote, wenn es dem Top-Level-Dokument hinzugefgt wird.
3. <iframe src="https://b.com/embed"> erhlt eine 8 KiB-Quote, wenn es dem Top-Level-Dokument hinzugefgt wird.

Same-origin Unterrahmen knnen keine Quote mit dem Top-Level teilen, wenn sie von einem Cross-Origin-Unterrahmen getrennt sind

Angenommen, ein Top-Level-Dokument auf a.com, das ein <iframe src="https://b.com/"> einbettet, das einen Unterrahmen von <iframe src="https://a.com/embed"> einbettet, und keine expliziten Berechtigungsrichtlinien.

1. Das Top-Level-Dokument von a.com hat die Standard-512 KiB-Quote.
2. <iframe src="https://b.com/"> teilt die 8 KiB-Quote.
3. <iframe src="https://a.com/embed"> erhlt keine Quote; selbst wenn dies same-origin mit dem Top-Ursprung ist, wird es von einem Cross-Origin getrennt.

Sekundre Unterrahmen von Unterrahmen erhalten standardmig keine Quote

Angenommen, ein Top-Level-Dokument auf a.com, das ein <iframe src="https://b.com/"> einbettet, das ein <iframe src="https://c.com/"> einbettet, und keine expliziten Berechtigungsrichtlinien.

1. Der Top-Level-Rahmen von a.com hat die Standard-512 KiB-Quote.
2. <iframe src="https://b.com/"> erhlt 8 KiB der Standard-geteilten Quote.
3. <iframe src="https://c.com/"> erhlt keine Quote.

Gewhren der vollen Quote an einen weiteren Unterrahmen

Angenommen, ein Top-Level-Dokument auf a.com, das ein <iframe src="https://b.com/"> einbettet, das ein <iframe src="https://c.com/"> einbettet.

Angenommen, a.com hat die folgende Berechtigungsrichtlinie:

Permissions-Policy: deferred-fetch=("https://c.com" "https://c.com")

Und, angenommen, b.com hat die folgende Berechtigungsrichtlinie:

Permissions-Policy: deferred-fetch=("https://c.com")

1. Der Top-Level-Rahmen von a.com hat die Standard-512 KiB-Quote.
2. <iframe src="https://b.com/"> erhlt 64 KiB der Standardquote.
3. <iframe src="https://b.com/"> delegiert seine volle Quote von 8 KiB an c.com. b.com kann fetchLater() nicht verwenden.
4. <iframe src="https://c.com/"> erhlt 8 KiB der Quote.

Weiterleitungen bertragen keine Quote

Angenommen, ein Top-Level-Dokument auf a.com, das ein <iframe src="https://b.com/"> einbettet, das zu c.com weiterleitet, und keine expliziten Top-Level-Berechtigungsrichtlinien.

1. Der Top-Level-Rahmen von a.com hat die Standard-512 KiB-Quote.
2. <iframe src="https://b.com/"> erhlt 8 KiB der Standard-geteilten Quote.
3. Die 8 KiB werden nicht an c.com bertragen, wenn <iframe src="https://b.com/"> dorthin weiterleitet, aber die 8 KiB werden nicht freigegeben.

Sandboxed same-origin Iframes sind effektiv separate Ursprnge

Zum Beispiel, wenn das folgende <iframe> auf https://www.example.com eingebettet wird:

<iframe src="https://www.example.com/iframe" sandbox="allow-scripts"></iframe>

Dies wrde nicht als "same-origin" betrachtet werden, obwohl es auf demselben Ursprung wie das Top-Level-Dokument gehostet wird, da das <iframe> in einer Sandbox-Umgebung ist. Daher sollte es standardmig eine 8 KiB-Quote aus der gesamten geteilten 128 KiB-Quote zugewiesen werden.

fetchLater() von Iframes nicht erlauben

Sie knnen das <iframe> allow Attribut verwenden, um zu verhindern, dass fetchLater()-Quoten dem <iframe> zugewiesen werden:

<iframe
  src="https://www.example.com/iframe"
  allow="deferred-fetch;deferred-fetch-minimal;"></iframe>

Die allow="deferred-fetch"-Direktive wird bentigt, um zu verhindern, dass same-origin Iframes die 512 KiB-Quote nutzen, und die allow="deferred-fetch-minimal"-Direktive wird bentigt, um zu verhindern, dass cross-origin Iframes die 128 KiB-Quote nutzen. Durch das Einschlieen beider Direktiven werden beide Quoten unabhngig vom src-Wert nicht genutzt.

Beispiele, die einen QuotaExceededError werfen

// Maximum of 64KiB per origin
const url = "<72KiB of characters>";
fetchLater(url);

// Maximum of 64KiB per origin including headers
fetchLater("https://origin.example.com", { headers: headersExceeding64KiB });

// Maximum of 64KiB per origin including body and headers
fetchLater("<32KiB of characters>", { headers: headersExceeding32KiB });

// Maximum of 64KiB per origin including body
fetchLater("https://origin.example.com", {
  method: "POST",
  body: bodyExceeding64KiB,
});

// Maximum of 64KiB per origin including body and automatically added headers
fetchLater("<62KiB of characters>" /* with a 3kb referrer */);

Beispiele, die schlielich einen QuotaExceededError werfen

In der folgenden Sequenz, die im Top-Level-Dokument enthalten ist, wrden die ersten beiden Anfragen erfolgreich sein, aber die dritte wrde einen Fehler werfen. Das liegt daran, dass, selbst wenn die gesamte 640 KiB-Quote nicht berschritten wurde, die dritte Anfrage das Meldungsursprungs-Limit fr https://a.example.com berschreitet und einen Fehler werfen wrde.

fetchLater("https://a.example.com", { method: "POST", body: a40KiBBody });
fetchLater("https://b.example.com", { method: "POST", body: a40KiBBody });
fetchLater("https://a.example.com", { method: "POST", body: a40KiBBody });

Weiterleitungen von Unterrahmen zurck zum Top-Level-Ursprung erlauben die Nutzung der Top-Level-Quote

Angenommen, ein Top-Level-Dokument auf a.com, das <iframe src="https://b.com/"> einbettet, das zu a.com weiterleitet, und keine expliziten Top-Level-Berechtigungsrichtlinien:

1. Der Top-Level-Rahmen von a.com hat die Standard-512 KiB-Quote.
2. <iframe src="https://b.com/"> erhlt 8 KiB der Standard-geteilten Quote von 128 KiB.
3. Die 8 KiB werden nicht an a.com bertragen, wenn <iframe src="https://b.com/"> dorthin weiterleitet, aber es kann wieder die volle Top-Level-Quote teilen, und die zuvor zugewiesene 8 KiB-Quote wird freigegeben.