Speculation Rules API

Konzepte und Verwendung

Spekulationsregeln knnen innerhalb von inline <script type="speculationrules">-Elementen und externen Textdateien, die durch den Speculation-Rules Antwortheader referenziert werden, spezifiziert werden. Die Regeln werden als JSON-Struktur angegeben.

Ein Skriptbeispiel:

<script type="speculationrules">
  {
    "prerender": [
      {
        "where": {
          "and": [
            { "href_matches": "/*" },
            { "not": { "href_matches": "/logout" } },
            { "not": { "href_matches": "/*\\?*(^|&)add-to-cart=*" } },
            { "not": { "selector_matches": ".no-prerender" } },
            { "not": { "selector_matches": "[rel~=nofollow]" } }
          ]
        }
      }
    ],
    "prefetch": [
      {
        "urls": ["next.html", "next2.html"],
        "requires": ["anonymous-client-ip-when-cross-origin"],
        "referrer_policy": "no-referrer"
      }
    ]
  }
</script>

Spekulationsregeln, die ein <script>-Element verwenden, mssen explizit in der Content-Security-Policy script-src Direktive erlaubt werden, wenn die Seite diese enthlt. Dies erfolgt durch das Hinzufgen einer der 'inline-speculation-rules' Quelle, einer Hash-Quelle oder einer Nonce-Quelle.

Ein HTTP-Header-Beispiel:

Speculation-Rules: "/rules/prefetch.json"

Die Textressource, die das Spekulationsregeln-JSON enthlt, kann einen beliebigen gltigen Namen und eine beliebige Erweiterung haben, muss jedoch mit einem application/speculationrules+json MIME-Typ bereitgestellt werden.

Sie spezifizieren ein unterschiedliches Array, um die Regeln fr jeden spekulativen Ladetyp zu enthalten (zum Beispiel "prerender" oder "prefetch"). Jede Regel ist in einem Objekt enthalten, das zum Beispiel eine Liste von zu holenden Ressourcen spezifiziert, plus Optionen wie eine explizite Referrer-Policy Einstellung fr jede Regel. Beachten Sie, dass vorgerenderte URLs ebenfalls vorgeladen werden.

Siehe <script type="speculationrules"> fr eine vollstndige Erklrung der verfgbaren Syntax.

Verwendung von Prefetching

Das Einfgen von prefetch-Regeln in ein <script type="speculationrules">-Element oder einen Speculation-Rules-Header fhrt dazu, dass untersttzende Browser den Antwortkrper der referenzierten Seiten herunterladen, jedoch keine der von der Seite referenzierten Subressourcen. Wenn auf eine vorgeladene Seite navigiert wird, wird sie wesentlich schneller gerendert als wenn sie nicht vorgeladen wurde.

Die Ergebnisse werden in einem pro-Dokument-In-Memory-Cache gehalten. Alle gecachten Vorladungen werden verworfen, wenn Sie die aktuelle Seite verlassen, auer natrlich ein vorgeladenes Dokument, zu dem Sie dann navigieren.

Dies bedeutet, dass, wenn Sie etwas vorladen, zu dem der Benutzer nicht navigiert, dies im Allgemeinen eine Verschwendung von Ressourcen ist, obwohl das Ergebnis den HTTP-Cache fllen kann, wenn Header dies zulassen. Das gesagt, die Vorabkosten eines Prefetches sind viel kleiner als die Vorabkosten eines Prerenders, daher wird empfohlen, das Prefetching breit anzuwenden, zum Beispiel alle bedeutenden Seiten Ihrer Seite vorzuhalten, vorausgesetzt sie sind sicher vorzuholen (siehe Unsichere spekulative Ladebedingungen fr mehr Details).

Same-Site und Cross-Site Prefetches funktionieren, aber Cross-Site Prefetches sind begrenzt (siehe "same-site" und "cross-site" fr eine Erklrung der Unterschiede zwischen den beiden). Aus Datenschutzgrnden funktionieren Cross-Site Prefetches derzeit nur, wenn der Benutzer keine Cookies fr die Zielseite gesetzt hat wir mchten nicht, dass Seiten die Benutzeraktivitt ber vorgeladene Seiten (die sie unter Umstnden nie besuchen) basierend auf vorher gesetzten Cookies verfolgen.

Fr Browser, die es untersttzen, sollten Spekulationsregeln Prefetch gegenber lteren Prefetch-Mechanismen bevorzugt werden, namentlich <link rel="prefetch"> und fetch() mit einer priority: "low"-Option. Weil wir wissen, dass Spekulationsregeln Prefetch fr Navigationen ist, nicht fr allgemeine Ressourcenvorhaltung:

• Es kann fr Cross-Site-Navigationen verwendet werden, whrend <link rel="prefetch"> dies nicht kann.
• Es wird nicht durch Cache-Control Header blockiert, whrend <link rel="prefetch"> hufig blockiert wird.

Darber hinaus hat Spekulationsregelsymbolisierung Prefetch:

• Senkt automatisch die Prioritt, wenn ntig (fetch() tut dies nicht).
• Respektiert die Konfiguration des Benutzers. Zum Beispiel passiert das Vorladen nicht, wenn das Gert des Benutzers sich im Energiesparmodus oder Datensparmodus befindet.
• Speichert die vorgeladenen Ressourcen in einem pro-Dokument-In-Memory-Cache im Gegensatz zum HTTP-Cache, was zu einem leicht schnelleren Vorladen fhren kann.

Verwendung von Prerendering

Das Einfgen von prerender-Regeln in ein <script type="speculationrules">-Element oder einen Speculation-Rules-Header fhrt dazu, dass untersttzende Browser den Inhalt in einem unsichtbaren Tab abrufen, rendern und laden, der in einem pro-Dokument-In-Memory-Cache gespeichert wird. Dies schliet das Laden aller Subressourcen ein, das Ausfhren aller JavaScript, und sogar das Laden von Subressourcen und Durchfhren von Datenabrufen, die von JavaScript gestartet werden. Alle gecachten Prerender und ihre Subressourcen werden verworfen, wenn Sie die aktuelle Seite verlassen, auer natrlich ein prerendertes Dokument, zu dem Sie dann navigieren.

Zuknftige Navigationen zu einem prerenderten Dokument werden nahezu sofort ausgefhrt. Der Browser aktiviert den unsichtbaren Tab anstelle des blichen Navigationsprozesses und ersetzt die alte Vordergrundseite durch die prerenderte Seite. Wenn eine Seite aktiviert wird, bevor sie vollstndig prerendert wurde, wird sie im aktuellen Zustand aktiviert und ldt dann weiter, was bedeutet, dass Sie trotzdem einen erheblichen Performancevorteil sehen werden.

Prerendering verwendet Speicher und Netzwerkbandbreite. Wenn Sie etwas prerendern, zu dem der Benutzer nicht navigiert, werden diese verschwendet (obwohl das Ergebnis den HTTP-Cache fllen kann, wenn Header dies zulassen, was eine sptere Verwendung erlaubt). Die Vorabkosten eines Prerenders sind viel grer als die Vorabkosten eines Prefetches, und andere Bedingungen knnten auch dazu fhren, dass Inhalte unsicher zum Prerendern sind (siehe Unsichere spekulative Ladebedingungen fr mehr Details). Daher wird empfohlen, das Prerendering sparsamer zu verwenden und sorgfltig Flle zu prfen, in denen eine hohe Wahrscheinlichkeit besteht, dass die Seite navigiert wird und Sie denken, dass der Vorteil fr die Benutzererfahrung die zustzlichen Kosten wert ist.

Prerendering ist standardmig auf same-origin Dokumente beschrnkt. Cross-origin, same-site Prerendering ist mglich es erfordert, dass das Navigationsziel ber den Supports-Loading-Mode Header mit einem Wert von credentialed-prerender eingewilligt wird. Cross-Site Prerendering ist derzeit nicht mglich.

Fr Browser, die es untersttzen, sollte die Spekulationsregeln Prerender gegenber lteren Prerender-Mechanismen bevorzugt werden, nmlich <link rel="prerender">:

• <link rel="prerender"> ist Chrome-spezifisch und wurde nie standardisiert, und das Chrome-Entwicklungsteam ist dabei, es abzuschaffen.
• Es ldt Subressourcen, die ber JavaScript geladen werden, whrend <link rel="prerender"> dies nicht tut.
• Es wird nicht durch Cache-Control Einstellungen blockiert, whrend <link rel="prerender"> oft blockiert wird.
• Spekulationsregeln Prerender sollte als ein Hinweis und eine progressive Verbesserung behandelt werden. Im Gegensatz zu <link rel="prerender"> ist es ein spekulativer Hinweis und der Browser kann whlen, den Hinweis nicht umzusetzen, basierend auf Benutzereinstellungen, aktuellem Speicherverbrauch oder anderen Heuristiken.

Spekulationsregeln API Feature-Erkennung

Sie knnen berprfen, ob die Spekulationsregeln API untersttzt wird, indem Sie den folgenden Code verwenden:

if (
  HTMLScriptElement.supports &&
  HTMLScriptElement.supports("speculationrules")
) {
  console.log("Your browser supports the Speculation Rules API.");
}

Zum Beispiel mchten Sie Spekulationsregeln fr das Vorladen in untersttzenden Browsern einfgen, aber in anderen eine ltere Technologie wie <link rel="prefetch"> verwenden:

if (
  HTMLScriptElement.supports &&
  HTMLScriptElement.supports("speculationrules")
) {
  const specScript = document.createElement("script");
  specScript.type = "speculationrules";
  const specRules = {
    prefetch: [
      {
        source: "list",
        urls: ["/next.html"],
      },
    ],
  };
  specScript.textContent = JSON.stringify(specRules);
  document.body.append(specScript);
} else {
  const linkElem = document.createElement("link");
  linkElem.rel = "prefetch";
  linkElem.href = "/next.html";
  document.head.append(linkElem);
}

Erkennung von vorgeladenen und prerenderten Seiten

Dieser Abschnitt betrachtet verschiedene Mglichkeiten, um festzustellen, ob eine angeforderte Seite vorgeladen oder prerendert wurde.

Serverseitige Erkennung

Vorgeladene und prerenderte Seitenanforderungen werden mit dem Sec-Purpose Anfrage-Header gesendet:

Fr Prefetch:

Sec-Purpose: prefetch

Fr Prerender:

Sec-Purpose: prefetch;prerender

Server knnen basierend auf diesem Header antworten, zum Beispiel um spekulative Ladevorgnge zu protokollieren, anderen Inhalt zurckzugeben oder sogar zu verhindern, dass spekulatives Laden stattfindet. Wenn ein Nicht-Erfolgs-Response-Code zurckgegeben wird (jeder HTTP-Status, der nicht im Bereich von 200 bis 299 nach Umleitungen liegt), dann wird die Seite nicht vorgeladen/vorgerendert. Zustzlich verhindern die Statuscodes 204 und 205 ebenfalls das Prerendering (aber nicht das Prefetching).

Die Verwendung eines Nicht-Erfolgs-Codes (zum Beispiel eines 503) ist der einfachste Weg, um spekulatives Laden serverseitig zu verhindern, obwohl es in der Regel besser ist, das Prefetch/Prerender zuzulassen und JavaScript zu verwenden, um alle Aktionen zu verzgern, die nur passieren sollen, wenn die Seite tatschlich angesehen wird.

Erkennung von Prefetching mit JavaScript

Wenn eine Seite vorgeladen wird, wird ihr PerformanceResourceTiming.deliveryType Eintrag einen Wert von "navigational-prefetch" zurckgeben. Sie knnten das folgende verwenden, um eine Funktion auszufhren, wenn ein Performance-Eintrag vom Typ "navigational-prefetch" empfangen wird:

if (
  performance.getEntriesByType("navigation")[0].deliveryType ===
  "navigational-prefetch"
) {
  respondToPrefetch(); // Author-defined function
}

Diese Technik ist ntzlich, wenn die Leistung gemessen wird oder wenn Sie Aktionen verzgern mchten, die Probleme verursachen knnten, wenn sie whrend des Prefetching auftreten (siehe Unsicheres Prefetching).

Erkennung von Prerendering mit JavaScript

Um eine Aktivitt whrend des Prerenderings der Seite auszufhren, knnen Sie die Document.prerendering Eigenschaft berprfen. So knnten Sie zum Beispiel einige Analysen ausfhren:

if (document.prerendering) {
  analytics.sendInfo("got this far during prerendering!");
}

Wenn ein prerendertes Dokument aktiviert wird, wird PerformanceNavigationTiming.activationStart auf einen DOMHighResTimeStamp gesetzt, der die Zeit zwischen dem Beginn des Prerenderings und der Aktivierung des Dokuments darstellt. Die folgende Funktion kann sowohl das Prerendering als auch prerenderte Seiten berprfen:

function pagePrerendered() {
  return (
    document.prerendering ||
    self.performance?.getEntriesByType?.("navigation")[0]?.activationStart > 0
  );
}

Wenn die prerenderte Seite durch das Ansehen durch den Benutzer aktiviert wird, wird das prerenderingchange Ereignis ausgelst. Dies kann verwendet werden, um Aktivitten zu aktivieren, die zuvor standardmig beim Laden der Seite gestartet wrden, die Sie jedoch aufschieben mchten, bis die Seite vom Benutzer angesehen wird. Der folgende Code richtet einen Ereignislistener ein, um eine Funktion auszufhren, sobald das Prerendering auf einer prerenderten Seite beendet ist, oder fhrt sie sofort auf einer nicht prerenderten Seite aus:

if (document.prerendering) {
  document.addEventListener("prerenderingchange", initAnalytics, {
    once: true,
  });
} else {
  initAnalytics();
}

Unsichere spekulative Ladebedingungen

Dieser Abschnitt behandelt Bedingungen, auf die Sie achten sollten und unter denen Prefetching und/oder Prerendering unsicher sind. Das bedeutet, dass Prefetching/Prerendering Seiten, die diese Bedingungen aufweisen, mglicherweise Abhilfemanahmen in Ihrem Code erfordern oder ganz vermieden werden mssen.

Unsicheres Prefetching

Wie bereits erwhnt, empfehlen wir, Prefetching breit anzuwenden, da das Risiko-Nutzen-Verhltnis relativ gering ist die potenzielle Ressourcenverschwendung ist minimal, und die Leistungsverbesserungen knnen signifikant sein. Sie mssen jedoch sicherstellen, dass vorgeladene Seiten keine Probleme mit dem Ablauf Ihrer Anwendung verursachen.

Wenn ein Prefetch durchgefhrt wird, ldt der Browser den Antwortkrper der referenzierten Seite ber eine einzige GET-Anfrage herunter, die der Benutzer zu einem spteren Zeitpunkt navigieren kann. Probleme knnen insbesondere dann auftreten, wenn die URL der Anfrage einen serverinitiierten Seiteneffekt hat, den Sie nicht wnschen, bis zur eigentlichen Navigation zur URL.

Zum Beispiel:

• Abmelde-URLs.
• Sprachwechselfunktionen.
• "In den Warenkorb legen"-URLs.
• Sign-In-Flow-URLs, bei denen der Server eine SMS sendet, zum Beispiel als Einmalpasswort (OTP).
• URLs, die die Verbrauchszahlen eines Benutzerlimits erhhen, zum Beispiel die Verwendung des monatlichen Kontingents an freien Artikeln oder des Starts eines Timers fr monatliche Minuten.
• URLs, die serverseitiges Anzeigen-Conversion-Tracking initiieren.

Solche Probleme knnen auf dem Server dadurch gemildert werden, dass Sie auf den Sec-Purpose: prefetch Header achten, whrend die Anfragen hereinkommen, und dann spezifischen Code auszufhren, um problematische Funktionalitt zu verzgern. Spter, wenn zur Seite tatschlich navigiert wird, knnen Sie mit JavaScript die aufgeschobene Funktionalitt einleiten, wenn ntig.

Es ist auch potenziell riskant, ein Dokument vorzuholen, dessen servergerenderte Inhalte durch Aktionen des Benutzers auf der aktuellen Seite gendert werden. Dies knnte zum Beispiel Flash-Verkaufsseiten oder Kinosaal-Seatmaps umfassen. Testen Sie solche Flle sorgfltig und mildern Sie solche Probleme, indem Sie Inhalte aktualisieren, sobald die Seite geladen wird. Siehe Servergerenderter variierender Zustand fr mehr Details zu diesen Fllen.

Veraltete Vorholungen knnen mit dem prefetchCache Wert des Clear-Site-Data Antwortheaders gelscht werden. Dies knnte verwendet werden, zum Beispiel wenn sich durch Anfragen, die den Zustand ndern, die gecachten Daten als nicht mehr gltig erweisen, wie etwa beim Abmelden von einer Seite.

Prefetching ist sicher, wenn alle Seiteneffekte des Abrufens der Seite aus JavaScript-Ausfhrung resultieren, da das JavaScript erst bis zur Aktivierung ausgefhrt wird.

Ein letzter Tipp ist, die in Ihrer robots.txt als nicht erlaubt gelisteten URLs zu prfen normalerweise verweisen diese URLs auf Seiten, die nur von authentifizierten Benutzern abgerufen werden knnen und daher nicht in Suchmaschinenergebnissen enthalten sein sollten. Viele davon werden in Ordnung sein, aber es kann ein guter Ort sein, um URLs zu finden, die unsicher zum Vorladen sind (das heit, sie weisen die oben beschriebenen Bedingungen auf).

Unsicheres Prerendering

Prerendering ist riskanter als Prefetching, deshalb sollte es sparsam eingesetzt werden, in Fllen, bei denen es sich lohnt. Es gibt mehr unsichere Bedingungen, die beim Prerendering zu beachten sind. Daher ist, auch wenn der Nutzen hher ist, das Risiko ebenfalls hher.

Wenn ein Prerendering durchgefhrt wird, ruft der Browser die URL per GET ab und rendert und ldt den Inhalt in einen unsichtbaren Tab. Dies schliet das Ausfhren des JavaScripts des Inhalts und das Laden aller Subressourcen ein, die von JavaScript abgerufen werden. Inhalte knnen potenziell unsicher zum Prerendern sein, wenn eine der folgenden Bedingungen beobachtet wird:

• Die URL ist unsicher zu vorzuholen. Lesen Sie den vorherigen Abschnitt, wenn Sie dies noch nicht getan haben, und verstehen Sie, dass diese Bedingungen auch fr unsicheres Prerendering gleichermaen zutreffen.
• Das JavaScript der Seite modifiziert clientseitigen Speicher (zum Beispiel Web Storage oder IndexedDB) beim Laden in einer Weise, die zu verwirrenden Effekten auf anderen, nicht prerenderten Seiten fhren kann, die der Benutzer derzeit betrachtet.
• Die Seite fhrt JavaScript aus oder ldt Bilder, die Seiteneffekte verursachen wie das Senden von Analysen, das Aufzeichnen von Anzeigen-Impressionen oder das anderweitige Modifizieren des Status der Anwendung, als ob der Benutzer bereits damit interagiert htte. Auch dies kann den Ablauf der Anwendung beeinflussen oder zu ungenauen Leistungs- oder Nutzungsberichten fhren. Siehe Servergerenderter variierender Zustand fr weitere Details zu solchen Anwendungsfllen.

Um solche Probleme abzumildern, knnen Sie die folgenden Techniken verwenden:

• Achten Sie auf den Sec-Purpose: prefetch Header auf dem Server, whrend die Anfragen hereinkommen, und dann spezifischen Code auszufhren, um problematische Funktionalitt zu verzgern.
• Verwenden Sie das prerenderingchange Ereignis, um zu erkennen, wann die prerenderte Seite tatschlich aktiviert wird und fhren Sie entsprechend Code aus. Dies ist in zwei Fllen ntzlich:
  • Zurckstellen von Code, der Probleme verursachen knnte, wenn er ausgefhrt wird, bevor die Seite angesehen wird. Zum Beispiel mchten Sie mglicherweise bis nach der Aktivierung warten, um clientseitigen Speicher zu aktualisieren oder serverseitigen Status mit JavaScript zu modifizieren. Dies kann Situationen vermeiden, in denen die Benutzeroberflche und der Anwendungsstatus nicht mehr synchron sind, zum Beispiel ein Einkaufswagen, der keine Artikel anzeigt, obwohl der Benutzer welche hinzugefgt hat.
  • Wenn das oben Genannte nicht mglich ist, knnten Sie trotzdem den Code nach der Aktivierung neu ausfhren, um die App wieder auf den neuesten Stand zu bringen. Eine Seite mit sehr dynamischen Flash-Sales knnte sich auf Inhaltsaktualisierungen verlassen, die von einer Drittanbieter-Bibliothek bereitgestellt werden. Wenn Sie die Updates nicht verschieben knnen, knnen Sie immer frische Updates abrufen, sobald der Benutzer die Seite ansieht. Prerendered-Seiten knnen in Echtzeit mithilfe der Broadcast Channel API oder eines anderen Mechanismus wie fetch() oder einem WebSocket aktualisiert werden. Dies stellt sicher, dass der Benutzer aktuelle Inhalte nach der Aktivierung des Prerenderings sieht.
• Verwenden Sie Ihre Drittanbieter-Analysenskripte sorgfltig verwenden Sie nach Mglichkeit Skripte, die prerendering-empfindlich sind (zum Beispiel die Nutzung der Document.prerendering Eigenschaft, um das Ausfhren auf prerenderten Seiten zu verzgern) wie Google Analytics oder NewRelic.
  • Beachten Sie, dass das Laden der Inhalte von Cross-Origin <iframe>s whrend des Prerenderings verzgert wird, bis die Aktivierung erfolgt. Dies geschieht, um Probleme zu vermeiden, die durch das Laden von Cross-Origin-Seiten entstehen, die sich des Prerenderings nicht bewusst sind, und um Komplexitten zu vermeiden, welche Anmeldedaten und Speicher diesen Frames zur Verfgung gestellt werden sollen. Es bedeutet, dass Benutzer in einigen Fllen zunchst leere Frames sehen knnen, es bedeutet aber auch, dass die meisten Drittanbieter-Widgets wie Ad-Tech whrend des Prerenderings sicher verwendet werden knnen.
  • Bei Drittanbieter-Skripten, die nicht prerendering-empfindlich sind, vermeiden Sie das Laden, bis nach der Aktivierung mithilfe des prerenderingchange Ereignisses, wie zuvor erwhnt.

Servergerenderter variierender Zustand

Es gibt zwei Hauptarten von servergerendertem Zustand, mit denen Sie sich befassen mssen: veralteter Zustand und benutzerspezifischer Zustand. Dies kann sowohl unsicheres Prefetching als auch Prerendering verursachen.

• Veralteter Zustand: Betrachten Sie das Beispiel einer servergerenderten Liste von Blog-Kommentaren, die zwischen Prerendering und Ansicht des Blog-Posts veraltet sein knnen. Dies knnte insbesondere problematisch sein, wenn die aktuelle Seite ein Admin-Panel ist, in dem der Benutzer Spam-Kommentare lscht. Wenn der Benutzer dann zum Blog-Post wechselt, knnte er verwirrt sein, warum er die Spam-Kommentare sieht, die er gerade gelscht hat.
• Benutzerspezifischer Zustand: Betrachten Sie den Fall, Anmeldungen ber einen Cookie zu verfolgen. Probleme knnen wie folgt auftreten:
  • Der Benutzer besucht https://site.example/a in Tab 1 und https://site.example/b in Tab 2, whrend er nicht angemeldet ist.
  • https://site.example/b prerendert https://site.example/c. Es wird im abgemeldeten Zustand prerendert.
  • Der Benutzer meldet sich bei https://site.example in Tab 1 an.
  • Der Benutzer wechselt zu Tab 2 und klickt auf den Link zu https://site.example/c, was die prerendered-Seite aktiviert.
  • Tab 2 zeigt eine abgemeldete Ansicht von https://site.example/c an, was den Benutzer verwirrt, da er dachte, er sei angemeldet.

Benutzerspezifische Zustandsprobleme knnen auch fr andere Benutzereinstellungen auftreten, zum Beispiel Spracheinstellungen, Dunkelmodusprferenzen oder das Hinzufgen von Artikeln zu einem Warenkorb. Sie knnen sich auch dann ergeben, wenn nur ein einzelner Tab beteiligt ist:

• Angenommen, der Benutzer besucht https://site.example/product.
• https://site.example.com/product prerendert https://site.example.com/cart. Es wird mit 0 Artikeln im Warenkorb prerendert.
• Der Benutzer klickt auf die "In den Warenkorb legen"-Schaltflchen, was eine Abrufanfrage startet, um den Artikel zum Warenkorb des Benutzers hinzufgen (ohne Neuladen der Seite).
• Der Benutzer klickt auf den Link zu https://site.example.com/cart, was die prerendered-Seite aktiviert.
• Der Benutzer sieht einen leeren Warenkorb, obwohl er gerade etwas hinzugefgt hat.

Die beste Abhilfe fr diese Flle und tatschlich jedes Mal, wenn Inhalte mit dem Server aus der Synchronisation geraten knnen, besteht darin, dass sich Seiten bei Bedarf selbst aktualisieren. Beispielsweise knnte ein Server die Broadcast Channel API oder einen anderen Mechanismus wie fetch() oder einen WebSocket verwenden. Seiten knnen sich dann selbst angemessen aktualisieren, einschlielich spekulativ geladener Seiten, die noch nicht aktiviert wurden.

Wo Aktualisierungen nicht mglich sind, knnen Spekulationen durch den Clear-Site-Data Antwortheader mit den prefetchCache oder prerenderCache Werten (oder beiden) bereinigt werden, je nachdem.

Der Header kann auf jede gleiche Website HTTP-Anfrage zurckgegeben werden (wie ein /api/add-to-cart API-Aufruf).

Sitzungsverlauf-Verhalten fr prerenderte Dokumente

Das Aktivieren eines prerendering/prerendered Dokuments verhlt sich aus der Sicht des Endbenutzers wie jede herkmmliche Navigation. Das aktivierte Dokument wird im Tab angezeigt und dem Sitzungsverlauf hinzugefgt, und alle vorhandenen Vorlauf-Historieneintrge werden beschnitten. Alle Navigationen, die im Prerendering-Browsing-Kontext vor der Aktivierung stattfinden, beeinflussen den Sitzungsverlauf nicht.

Aus Sicht des Entwicklers kann ein prerendering Dokument als trivialer Sitzungsverlauf betrachtet werden, bei dem nur ein Eintrag der aktuelle Eintrag existiert. Alle Navigationen im Prerendering-Kontext werden effektiv ersetzt.

Whrend API-Funktionen, die auf Sitzungsverlauf wirken (zum Beispiel History und Navigation), innerhalb prerendered Dokumente aufgerufen werden knnen, operieren sie nur auf dem trivialen Sitzungsverlauf des Kontextes. Folglich nehmen prerendered Dokumente nicht am gemeinsamen Sitzungsverlauf ihrer verweisenden Seite teil. Zum Beispiel knnen sie ihren Verweis nicht ber History.back() navigieren.

Dieses Design stellt sicher, dass Benutzer das erwartete Erlebnis beim Verwenden des Zurck-Buttons haben das heit, dass sie zu dem letzten Gesehenen zurckgebracht werden. Sobald ein prerendering Dokument aktiviert wird, wird nur ein einzelner Eintrag im gemeinsamen Sitzungsverlauf hinzugefgt, unter den bisherigen Navigationen, die im Prerendering-Browsing-Kontext stattfanden. Ein Schritt im gemeinsamen Sitzungsverlauf zurckgehen zum Beispiel durch Drcken des Zurck-Buttons bringt den Benutzer zur Ursprungsseite zurck.

Plattformfunktionen, die whrend des Prerenderings zurckgestellt oder eingeschrnkt sind

Da eine prerendered Seite in einem ausgeblendeten Zustand geffnet ist, werden mehrere API-Funktionen, die potenziell aufdringliche Verhaltensweisen verursachen, nicht in diesem Zustand aktiviert und werden stattdessen zurckgestellt bis die Seite aktiviert wird. Andere Webplattformfunktionen, die beim Prerendering problematisch sind, sind ganz eingeschrnkt. Dieser Abschnitt bietet Details darber, welche Funktionen zurckgestellt oder eingeschrnkt sind.

Asynchrone API-Zurckstellung

Zurckstellen bedeutet, dass die API-Funktion sofort ein ausstehendes Versprechen zurckgibt und dann nichts unternimmt bis zur Aktivierung der Seite. Nach der Aktivierung luft die Funktion normal und das Versprechen wird normal erfllt oder abgelehnt.

Die Ergebnisse der folgenden asynchronen Funktionen werden in prerendered Dokumenten bis zur Aktivierung zurckgestellt:

• Audio Output Devices API: MediaDevices.selectAudioOutput()
• Background Fetch API: BackgroundFetchManager.fetch()
• Broadcast Channel API: BroadcastChannel.postMessage()
• Credential Management API: CredentialsContainer.create(), CredentialsContainer.get(), CredentialsContainer.store()
• Encrypted Media Extensions API: Navigator.requestMediaKeySystemAccess()
• Gamepad API: Navigator.getGamepads(), gamepadconnected Ereignis, gamepaddisconnected Ereignis
• Geolocation API: Geolocation.getCurrentPosition(), Geolocation.watchPosition(), Geolocation.clearWatch()
• HTMLMediaElement API: Die Wiedergabeposition wird whrend das enthaltende Dokument prerendert wird nicht fortschreiten
• Idle Detection API: IdleDetector.start()
• Media Capture and Streams API: MediaDevices.getUserMedia() (und die ltere Navigator.getUserMedia() Version), MediaDevices.enumerateDevices()
• Notifications API: Notification() Konstruktor, Notification.requestPermission()
• Push API: PushManager.subscribe()
• Screen Orientation API: ScreenOrientation.lock(), ScreenOrientation.unlock()
• Sensor-APIs: Sensor.start()
• Service Worker API: ServiceWorker.postMessage(), ServiceWorkerContainer.register(), ServiceWorkerRegistration.update(), ServiceWorkerRegistration.unregister()
• Storage API: StorageManager.persist()
• Web Audio API: AudioContexts drfen nicht starten, whrend das enthaltene Dokument prerendert wird
• Web Bluetooth API: Bluetooth.getDevices(), Bluetooth.requestDevice()
• WebHID API: HID.getDevices(), HID.requestDevice()
• Web Locks API: LockManager.query(), LockManager.request()
• Web MIDI API: Navigator.requestMIDIAccess()
• Web NFC API: NDefReader.write(), NDefReader.scan()
• Web Serial API: Serial.getPorts(), Serial.requestPort()
• Web Speech API: SpeechRecognition.abort(), SpeechRecognition.start(), SpeechRecognition.stop(), SpeechSynthesis.cancel(), SpeechSynthesis.pause(), SpeechSynthesis.resume(), SpeechSynthesis.speak()
• WebUSB API: USB.getDevices(), USB.requestDevice()
• WebXR Device API: XRSystem.requestSession()

Implizit eingeschrnkte APIs

Die folgenden Funktionen schlagen automatisch fehl oder verhalten sich nicht in aktivierten Dokumenten.

APIs, die vorbergehende Aktivierung oder angeklebte Aktivierung erfordern:

• Besttigungsdialoge, die von dem beforeunload Ereignis generiert werden
• Das Auslsen von Ereignissen im Clipboard API.
• File System API: Window.showDirectoryPicker(), Window.showOpenFilePicker(), Window.showSaveFilePicker()
• Fullscreen API: Element.requestFullscreen()
• Idle Detection API: IdleDetector.requestPermission()
• Keyboard API: Keyboard.lock() (erfordert Vollbild)
• Payment Request API: PaymentRequest.show()
• Presentation API: PresentationRequest.start()
• Pointer Lock API: Element.requestPointerLock()
• Screen Capture API: MediaDevices.getDisplayMedia()
• Web Share API: Navigator.share()

APIs, die erfordern, dass das enthaltende Dokument fokussiert ist:

• Clipboard API: Clipboard.read(), Clipboard.readText(), Clipboard.write(), Clipboard.writeText()

APIs, die erfordern, dass der Document.visibilityState des enthaltenden Dokuments "visible" ist:

• Picture-in-Picture API: HTMLVideoElement.requestPictureInPicture() (erfordert, dass der Sichtbarkeitsstatus des enthaltenden Dokuments "visible" ist, oder vorbergehende Aktivierung)
• Screen Wake Lock API: WakeLock.request()

Andere eingeschrnkte Funktionen

• Download-Links, das heit <a> und <area> Elemente mit dem download Attribut, werden ihre Downloads verzgern, bis das Prerendering beendet ist.
• Keine Cross-Site-Navigationen: Jedes prerendering Dokument, das zu einer anderen Seite navigiert, wird sofort verworfen, bevor eine Anfrage an diese andere Seite gesendet wird.
• Einschrnkte URLs: Prerendering Dokumente knnen keine Nicht-HTTP(S) Top-Level-URLs hosten. Das Einfgen der folgenden URL-Typen wird dazu fhren, dass das Prerendering sofort verworfen wird:
  • javascript: URLs
  • data: URLs
  • blob: URLs
  • about: URLs, einschlielich about:blank und about:srcdoc
• Sitzungsspeicher: Window.sessionStorage kann verwendet werden, aber das Verhalten ist sehr spezifisch, um Seiten zu vermeiden, die erwarten, dass nur eine Seite auf den Sitzungsspeicher der Registerkarte gleichzeitig zugreifen kann. Eine prerendered-Seite beginnt daher mit einem Klon des Sitzungsspeicherstatus der Tabelle von dem Zeitpunkt, an dem sie erstellt wurde. Nach der Aktivierung wird der Klon des Speichers der prerendered-Seite verworfen und der Hauptspeicherstatus der Tabelle wird stattdessen verwendet. Seiten, die Sitzungsspeicher verwenden, knnen das prerenderingchange Ereignis verwenden, um zu erkennen, wann dieser Speichertausch auftritt.
• Window.print(): Alle Aufrufe dieser Methode werden ignoriert.
• "Einfache Dialogmethoden" sind wie folgt eingeschrnkt:
  • Window.alert() kehrt sofort zurck, ohne einen Dialog anzuzeigen.
  • Window.confirm() kehrt sofort mit false zurck, ohne einen Dialog anzuzeigen.
  • Window.prompt() kehrt sofort mit einem leeren String ("") zurck, ohne einen Dialog anzuzeigen.
• Dedizierte/geteilte Workerskripte werden geladen, aber deren Ausfhrung wird aufgeschoben, bis das prerendered Dokument aktiviert wird.
• Cross-Origin <iframe> Loads werden whrend des Prerenderings verzgert, bis die Seite aktiviert wird.

Schnittstellen

Die Spekulationsregeln API definiert keine eigenen Schnittstellen.

Erweiterungen zu anderen Schnittstellen

Document.prerendering

Eine boolesche Eigenschaft, die true zurckgibt, wenn das Dokument derzeit im Prozess des Prerenderings ist.

prerenderingchange Ereignis

Wird auf einem prerendered Dokument ausgelst, wenn es aktiviert wird (das heit, der Benutzer betrachtet die Seite).

PerformanceNavigationTiming.activationStart

Eine Zahl, die die Zeit zwischen dem Start des Prerenderings eines Dokuments und dessen Aktivierung darstellt.

PerformanceResourceTiming.deliveryType "navigational-prefetch" Wert

Signalisiert, dass der Typ eines Performance-Eintrags ein Prefetch ist.

HTTP-Header

Content-Security-Policy 'inline-speculation-rules' Wert

Wird verwendet, um die Nutzung von <script type="speculationrules"> zu erlauben, um Spekulationsregeln im Dokument zu definieren, das abgerufen wird.

Clear-Site-Data 'prefetchCache' und 'prerenderCache' Werte

Verwendung zum Lschen von Spekulationen. Zum Beispiel, wenn Zustandsnderungen die Spekulationen veraltet machen.

Speculation-Rules

Liefert eine Liste von URLs, die auf Textressourcen verweisen, welche Spekulationsregeln JSON-Definitionen enthalten. Wenn die Antwort ein HTML-Dokument ist, werden diese Regeln dem Spekulationsregelsatz des Dokuments hinzugefgt.

Supports-Loading-Mode

Wird von einem Navigationsziel gesetzt, um die Nutzung verschiedener risikoreicher Lade-Modi zu erlauben. Zum Beispiel erfordert Cross-Origin, Same-Site Prerendering einen Supports-Loading-Mode Wert von credentialed-prerender.

HTML-Funktionen

<script type="speculationrules">

Wird verwendet, um ein Set von Prefetch- und/oder Prerender-Spekulationsregeln im aktuellen Dokument zu definieren, die dem Spekulationsregelsatz des Dokuments hinzugefgt werden.

Beispiele

Fr Codebeispiele siehe Prerender pages in Chrome for instant page navigations auf developer.chrome.com (2025)

Spezifikationen

Browser-Kompatibilitt

html.elements.script.type.speculationrules

http.headers.Speculation-Rules

Siehe auch

• Spekulatives Laden fr einen Vergleich von Spekulationsregeln und anderen hnlichen Leistungsverbesserungsfunktionen.