Get to know MDN better
Dieser Inhalt wurde automatisch aus dem Englischen übersetzt, und kann Fehler enthalten. Erfahre mehr über dieses Experiment.
Die fetchLater()-API stellt eine Schnittstelle bereit, um einen verzögerten Abruf anzufordern, der nach einem festgelegten Zeitraum oder wenn die Seite geschlossen oder navigiert wurde, gesendet werden kann.
Entwickler müssen oft Daten zurück an den Server senden (oder signalisieren), insbesondere am Ende eines Besuchs eines Benutzers auf einer Seite — zum Beispiel für Analysedienste. Dafür gibt es mehrere Wege: vom Hinzufügen von ein-Pixel-großen <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 Zuverlässigkeit für Signalisierung am Ende des Besuchs Schwächen aufweisen. Während die Beacon-API und die keepalive-Eigenschaft der Fetch-API Daten senden, selbst wenn das Dokument zerstört wird (so gut es in dieser Situation geht), löst 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:
Das bedeutet, dass Entwickler, die Daten zuverlässig über ein Beacon senden möchten, dies häufiger tun müssen als ideal wäre. Zum Beispiel könnten sie ein Beacon bei jeder Änderung senden, selbst wenn der endgültige Wert für die Seite noch nicht erreicht wurde. Dies hat Kosten in der Netzwerknutzung, Serververarbeitung und dem Zusammenführen oder Verwerfen veralteter Beacons auf dem Server.
Alternativ können Entwickler entscheiden, ein gewisses Maß an fehlenden Daten zu akzeptieren — entweder durch:
Die fetchLater()-API erweitert die Fetch-API, um das Einrichten von Abrufanfragen im Voraus zu ermöglichen. Diese verzögerten Abrufe können 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 zuverlässiges Beacon innerhalb vernünftiger Erwartungen sicher (d.h. ausgenommen, wenn der Browserprozess während eines Absturzes unerwartet beendet wird).
Verzögerte Abrufe können auch mit einem AbortController abgebrochen werden, wenn sie nicht mehr benötigt werden, um weitere unnötige Kosten zu vermeiden.
Verzögerte Abrufe werden gesammelt und gesendet, sobald der Tab geschlossen wird; in diesem Moment gibt es keine Möglichkeit für 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 für ein Top-Level-Dokument auf 640 KiB begrenzt.
Aufrufer von fetchLater() sollten defensiv sein und in fast allen Fällen QuotaExceededError-Fehler abfangen, insbesondere wenn sie Drittanbieter-JavaScript einbetten.
Da diese Beschränkung die Bandbreite für verzögerte Abrufe zu einer knappen Ressource macht, die zwischen mehreren Meldungs-Ursprüngen (beispielsweise mehreren RUM-Bibliotheken) und Unterrahmen aus mehreren Ursprüngen aufgeteilt werden muss, bietet die Plattform eine vernünftige Standardaufteilung dieser Quote. Darüber hinaus bietet sie deferred-fetch und deferred-fetch-minimal Berechtigungsrichtlinien-Direktiven, um eine andere Aufteilung bei Bedarf zu ermöglichen.
Die Gesamtquote für fetchLater() beträgt 640 KiB pro Dokument. Standardmäßig ist diese in eine 512 KiB Top-Level-Quote und eine 128 KiB geteilte Quote aufgeteilt:
fetchLater()-Anfragen können an jede URL gesendet werden und sind nicht auf denselben Ursprung wie das Dokument oder den Unterrahmen beschränkt, daher ist es wichtig zu unterscheiden zwischen Anfragen, die im Top-Level-Dokumentinhalt (ob für ursprungsfremde oder erste Partei) und solche, die in Unterrahmen gemacht werden.
Zum Beispiel, wenn ein Top-Level-a.com-Dokument ein <script> enthält, das eine fetchLater()-Anfrage an analytics.example.com macht, wäre diese Anfrage durch das Top-Level-Limit von 512 KiB eingeschränkt. Andersherum, wenn das Top-Level-Dokument ein <iframe> mit einer Quelle von analytics.example.com einbettet, das eine fetchLater()-Anfrage macht, wäre diese Anfrage durch das 128 KiB-Limit eingeschränkt.
Nur 64 KiB der Top-Level-512 KiB-Quote können gleichzeitig für 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 erhält standardmäßig eine 8 KiB-Quote aus der geteilten 128 KiB-Quote, die zugeteilt wird, wenn der Unterrahmen dem DOM hinzugefügt 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 können, da sie die 128 KiB-Quote ausschöpfen.
Der Top-Level-Ursprung kann ausgewählten Cross-Origin-Unterrahmen eine erhöhte Quote von 64 KiB gewähren, die aus dem größeren Top-Level-512 KiB-Limit genommen wird. Dies geschieht, indem diese Ursprünge in der deferred-fetch-Berechtigungsrichtlinie aufgelistet werden. Dies wird zugeteilt, wenn der Unterrahmen dem DOM hinzugefügt wird, und hinterlässt weniger Quote für das Top-Level-Dokument und direkte gleiche Ursprungsrahmen. Mehrere gleiche Ursprungs-Subdomains können jeweils eine 64 KiB-Quote erhalten.
Der Top-Level-Ursprung kann auch die 128 KiB-geteilte Quote auf benannte Cross-Origin-Unterrahmen beschränken, indem diese Ursprünge in der deferred-fetch-minimal-Berechtigungsrichtlinie aufgelistet werden. Es kann auch die gesamte 128 KiB Standardunterrahmenquote widerrufen und stattdessen die volle 640 KiB-Quote für sich selbst und alle benannten deferred-fetch-Cross-Ursprünge behalten, indem die deferred-fetch-minimal-Berechtigungsrichtlinie auf () gesetzt wird.
Standardmäßig werden Unterrahmen von Unterrahmen keine Quote zugewiesen und können somit fetchLater() nicht verwenden. Unterrahmen, die die erhöhte 64 KiB-Quote erhalten, können 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 können ihre volle Quote nur auf weitere Unterrahmen und nicht nur Teile davon delegieren und können keine neuen Quoten festlegen. Unterrahmen, die die minimale 8 KiB-Quote verwenden, können keine Quoten an Unterrahmen delegieren. Um eine Quote zu erhalten, müssen Sub-Subrahmen sowohl im Top-Level- als auch im Unterrahmen deferred-fetch-Permissions-Policy-Direktiven enthalten sein.
Wenn Quoten überschritten werden, wird ein QuotaExceededError geworfen, wenn die fetchLater()-Methode aufgerufen wird, um den verzögerten Abruf zu initiieren.
Berechtigungsrichtlinienprüfungen sind von Quotenüberprüfungen nicht unterscheidbar. Das Aufrufen von fetchLater() wird einen QuotaExceededError sowohl dann werfen, wenn die Quote tatsächlich überschritten wurde als auch wenn die Quote für diesen Ursprung über eine Berechtigungsrichtlinie eingeschränkt wurde.
Aufrufer von fetchLater() sollten defensiv sein und in fast allen Fällen QuotaExceededError-Fehler abfangen, insbesondere wenn sie Drittanbieter-JavaScript einbetten.
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.
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.
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.
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:
Und, angenommen, b.com hat die folgende Berechtigungsrichtlinie:
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.
Zum Beispiel, wenn das folgende <iframe> auf https://www.example.com eingebettet wird:
Dies würde 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 standardmäßig eine 8 KiB-Quote aus der gesamten geteilten 128 KiB-Quote zugewiesen werden.
Sie können das <iframe> allow Attribut verwenden, um zu verhindern, dass fetchLater()-Quoten dem <iframe> zugewiesen werden:
Die allow="deferred-fetch"-Direktive wird benötigt, um zu verhindern, dass same-origin Iframes die 512 KiB-Quote nutzen, und die allow="deferred-fetch-minimal"-Direktive wird benötigt, um zu verhindern, dass cross-origin Iframes die 128 KiB-Quote nutzen. Durch das Einschließen beider Direktiven werden beide Quoten unabhängig vom src-Wert nicht genutzt.
In der folgenden Sequenz, die im Top-Level-Dokument enthalten ist, würden die ersten beiden Anfragen erfolgreich sein, aber die dritte würde einen Fehler werfen. Das liegt daran, dass, selbst wenn die gesamte 640 KiB-Quote nicht überschritten wurde, die dritte Anfrage das Meldungsursprungs-Limit für https://a.example.com überschreitet und einen Fehler werfen würde.
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:
Der Bauplan für ein besseres Internet.
Besuche die gemeinnützige Muttergesellschaft der Mozilla Corporation, die Mozilla Foundation.
Teile dieses Inhalts sind ©1998–2026 von einzelnen mozilla.org-Mitwirkenden. Inhalte sind verfügbar unter einer Creative-Commons-Lizenz.