Speculation Rules API

Spekulationsregeln können innerhalb von Inline-Elementen <script type="speculationrules"> und externen Textdateien, die im Speculation-Rules Antwort-Header referenziert werden, spezifiziert werden. Die Regeln werden als JSON-Struktur spezifiziert.

Beispiel eines Skripts:

<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, müssen explizit in der Content-Security-Policy script-src Direktive erlaubt werden, wenn die Seite diese enthält. Dies erfolgt durch Hinzufügen einer der 'inline-speculation-rules' Quellen, einer Hash-Quelle oder einer Nonce-Quelle.

Beispiel eines HTTP-Headers:

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

Die Textressource, die das JSON der Spekulationsregeln enthält, kann einen beliebigen gültigen Namen und eine beliebige Extension haben, muss aber mit einem application/speculationrules+json MIME-Typ ausgeliefert werden.

Sie spezifizieren ein unterschiedliches Array zur Aufnahme der Regeln für jeden spekulativen Laden-Typ (zum Beispiel "prerender" oder "prefetch"). Jede Regel wird in einem Objekt angegeben, zum Beispiel mit einer Liste von Ressourcen, die geholt werden sollen, plus Optionen wie eine explizite Referrer-Policy Einstellung für jede Regel. Beachten Sie, dass vorgerenderte URLs auch vorgeladen werden.

Siehe <script type="speculationrules"> für eine vollständige Erklärung der verfügbaren Syntax.

Das Einfügen von prefetch-Regeln innerhalb eines <script type="speculationrules"> Elements oder eines Speculation-Rules Headers wird dazu führen, dass unterstützende Browser den Antwortkörper der referenzierten Seiten herunterladen, aber keine der von der Seite referenzierten Subresources. Wenn zu einer vorgeladenen Seite navigiert wird, wird sie viel schneller gerendert als wenn sie nicht vorgeladen worden wäre.

Die Ergebnisse werden in einem pro-Dokument-Arbeitsspeicher-Cache behalten. Alle zwischengespeicherten Prefetches werden verworfen, wenn Sie die aktuelle Seite verlassen, ausgenommen ein vorgeladenes Dokument, zu dem Sie dann navigieren.

Das bedeutet, dass, wenn Sie etwas vorladen, zu dem der Benutzer nicht navigiert, es im Allgemeinen eine Verschwendung von Ressourcen ist, obwohl das Ergebnis den HTTP-Cache füllen kann, wenn es die Header erlauben. Das gesagt, die anfänglichen Kosten eines Prefetches sind viel geringer als die anfänglichen Kosten eines Prerendens, daher wird empfohlen, umfangreich Prefetching einzusetzen, zum Beispiel das Vorladen aller bedeutenden Seiten auf Ihrer Seite, vorausgesetzt sie sind sicher zum Vorladen (siehe Unsichere spekulative Ladebedingungen für mehr Details).

Same-Site und Cross-Site Prefetches funktionieren, aber Cross-Site Prefetches sind limitiert (siehe "same-site" und "cross-site" für eine Erklärung des Unterschieds zwischen beiden). Aus Datenschutzgründen funktionieren Cross-Site Prefetches derzeit nur, wenn der Benutzer für die Zielseite keine Cookies gesetzt hat — wir wollen vermeiden, dass Seiten die Benutzeraktivität über vorgeladene Seiten (die sie möglicherweise nie tatsächlich besuchen) verfolgen, basierend auf zuvor gesetzten Cookies.

Für Browser, die es unterstützen, sollte Spekulationsregeln-Prefetch älteren Prefetch-Mechanismen vorgezogen werden, nämlich <link rel="prefetch"> und fetch() mit einer priority: "low" Option. Weil wir wissen, dass Spekulationsregeln-Prefetch für Navigationen ist, nicht für allgemeines Ressourcen-Prefetching:

• Es kann für Cross-Site-Navigationen verwendet werden, im Gegensatz zu <link rel="prefetch">.
• Es wird nicht durch Cache-Control Header blockiert, wohingegen <link rel="prefetch"> dies oft tut.

Zudem:

• Senkt Spekulationsregeln-Prefetch automatisch die Priorität, wenn nötig (fetch() tut dies nicht).
• Respektiert es die Konfiguration des Benutzers. Zum Beispiel passiert Prefetching nicht, wenn das Gerät des Benutzers im Energiesparmodus oder Datensparmodus ist.
• Speichert die vorgeladenen Ressourcen in einem pro-Dokument-Arbeitsspeicher-Cache anstelle des HTTP-Caches, was möglicherweise zu etwas schnellerem Prefetching führt.

Das Einfügen von prerender-Regeln innerhalb eines <script type="speculationrules"> Elements oder eines Speculation-Rules Headers wird dazu führen, dass unterstützende Browser den Inhalt in einen unsichtbaren Tab holen, rendern und laden, der in einem pro-Dokument-Arbeitsspeicher-Cache gespeichert wird. Dies beinhaltet das Laden aller Subresources, das Ausführen aller JavaScripts und sogar das Laden von Subresources und das Durchführen von Datenabfragen, die von JavaScripts gestartet wurden. Jegliche zwischengespeicherten Prerendere und ihre Subresources werden verworfen, wenn Sie die aktuelle Seite verlassen, ausgenommen ein gerendertes Dokument, zu dem Sie dann navigieren.

Zukünftige Navigationen zu einer vorgerenderten Seite werden nahezu sofort erfolgen. Der Browser aktiviert den unsichtbaren Tab, anstatt den üblichen Navigationsprozess durchzuführen und ersetzt die alte Vordergrundseite mit der vorgerenderten Seite. Wenn eine Seite aktiviert wird, bevor sie vollständig vorgerendert ist, wird sie in ihrem aktuellen Zustand aktiviert und dann weiter geladen, was bedeutet, dass Sie immer noch eine erhebliche Leistungsverbesserung 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 füllen kann, wenn die Header es erlauben, wodurch eine spätere Verwendung möglich ist). Die anfänglichen Kosten eines Prerenders sind viel größer als die anfänglichen Kosten eines Prefetches, und andere Bedingungen könnten den Inhalt auch unsicher für Prerendering machen (siehe Unsichere spekulative Ladebedingungen für weitere Details). Es wird empfohlen, Prerendering sparsamer einzusetzen, bewusst in Fällen, in denen eine hohe Wahrscheinlichkeit besteht, dass zur Seite navigiert wird, und Sie glauben, dass der Vorteil für die Benutzererfahrung die zusätzlichen Kosten wert ist.

Prerendering ist standardmäßig auf gleichherkommende Dokumente beschränkt. Cross-Origin, Same-Site Prerendering ist möglich — es erfordert, dass das Navigationsziel mit dem Supports-Loading-Mode Header und einem Wert von credentialed-prerender eingeht. Cross-Site Prerendering ist derzeit nicht möglich.

Für Browser, die es unterstützen, sollte Spekulationsregeln-Prerender älteren Prerender-Mechanismen vorgezogen werden, nämlich <link rel="prerender">:

• <link rel="prerender"> ist Chrome-spezifisch und wurde nie standardisiert, und das Chrome-Entwicklungsteam ist dabei, es abzuschaffen.
• Es lädt Subresources, die über JavaScript geladen werden, während <link rel="prerender"> dies nicht tut.
• Es wird durch Cache-Control Einstellungen nicht blockiert, während <link rel="prerender"> dies oft tut.
• 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 sich entscheiden, den Hinweis nicht zu beachten, basierend auf Benutzereinstellungen, aktuellem Speicherverbrauch oder anderen Heuristiken.

Sie können überprüfen, ob die Speculation Rules API unterstützt wird, indem Sie den folgenden Code verwenden:

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

Zum Beispiel möchten Sie möglicherweise Spekulationsregeln für Prefetching in unterstützenden Browsern einfügen, aber eine ältere Technologie wie <link rel="prefetch"> in anderen 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);
}

Dieser Abschnitt untersucht verschiedene Möglichkeiten, um zu erkennen, ob eine angeforderte Seite vorgeladen oder vorgerendert wurde.

Anfragen zu vorgeladenen und vorgerenderten Seiten werden mit dem Sec-Purpose Anfrage-Header gesendet:

Für Prefetch:

Sec-Purpose: prefetch

Für Prerender:

Sec-Purpose: prefetch;prerender

Server können basierend auf diesem Header antworten, zum Beispiel um spekulative Ladeanforderungen zu protokollieren, anderen Inhalt zurückzugeben oder sogar spekulatives Laden zu verhindern. Wenn ein Nicht-Erfolg-Antwortcode zurückgegeben wird (jeder HTTP-Status außerhalb des 200-299-Bereichs nach Weiterleitungen), wird die Seite nicht vorgeladen/vorgerendert. Zusätzlich verhindern die Statuscodes 204 und 205 Prerendering (verhindern aber nicht Prefetch).

Die Verwendung eines Nicht-Erfolg-Codes (zum Beispiel 503) ist der einfachste Weg, serverseitig spekulatives Laden zu verhindern, obwohl es in der Regel eine bessere Vorgehensweise ist, den Prefetch/Prerender zuzulassen und JavaScript zu verwenden, um Aktionen zu verzögern, die nur ausgeführt werden sollen, wenn die Seite tatsächlich angezeigt wird.

Wenn eine Seite vorgeladen wird, gibt ihr PerformanceResourceTiming.deliveryType Eintrag einen Wert von "navigational-prefetch" zurück. Sie könnten das folgende verwenden, um eine Funktion auszuführen, wenn ein Leistungseintrag des Typs "navigational-prefetch" empfangen wird:

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

Diese Technik ist nützlich, wenn Sie die Leistung messen oder wenn Sie Aktionen verzögern möchten, die Probleme verursachen könnten, wenn sie während des Prefetchings stattfinden (siehe Unsicheres Prefetching).

Um während des Prerenderings eine Aktivität durchzuführen, können Sie die Document.prerendering Eigenschaft überprüfen. Beispielsweise könnten Sie einige Analysen durchführen:

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

Wenn ein vorgerendertes Dokument aktiviert wird, wird PerformanceNavigationTiming.activationStart auf einen DOMHighResTimeStamp gesetzt, der die Zeit zwischen dem Beginn des Prerenders und der Aktivierung des Dokuments darstellt. Die folgende Funktion kann sowohl für die Erkennung von vorgerenderten als auch prerendereden Seiten verwendet werden:

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

Wenn die vorgerenderte Seite durch das Ansehen der Seite durch den Benutzer aktiviert wird, wird das prerenderingchange Ereignis ausgelöst. Dies kann verwendet werden, um Aktivitäten zu aktivieren, die bisher standardmäßig beim Laden der Seite gestartet wurden, die Sie jedoch bis zum Ansehen der Seite durch den Benutzer verzögern möchten. Der folgende Code richtet einen Ereignis-Listener ein, um eine Funktion einmal auszuführen, wenn das Prerendering auf einer vorgerenderten Seite abgeschlossen ist, oder führt es sofort auf einer nicht vorgerenderten Seite aus:

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

Dieser Abschnitt behandelt Bedingungen, auf die Sie achten sollten, unter denen Prefetching und/oder Prerendering unsicher ist. Das bedeutet, dass das Prefetching/Prerendering von Seiten, die diese Bedingungen aufweisen, in Ihrem Code abgeschwächt oder vollständig vermieden werden müssen.

Wie bereits erwähnt, empfehlen wir, Prefetching breit einzusetzen, da das Risiko-Nutzen-Verhältnis recht gering ist — das Potenzial für Ressourcenverschwendung ist minimal, und die Leistungsverbesserungen können erheblich sein. Sie müssen jedoch sicherstellen, dass vorgeladene Seiten den Ablauf Ihrer Anwendung nicht beeinträchtigen.

Wenn ein Prefetch durchgeführt wird, lädt der Browser den Antwortkörper der referenzierten Seite über eine einzelne GET-Anfrage herunter, die der Benutzer zu einem späteren Zeitpunkt navigieren kann. Probleme können speziell dann auftreten, wenn die URL der Anfrage einen serverinitiierten Nebeneffekt ausführt, den Sie nicht möchten, dass er passiert, bis die URL navigiert wird.

Beispiele könnten sein:

• Abmelde-URLs.
• Sprachwechsel-URLs.
• "In den Warenkorb" URLs.
• Anmeldefluss-URLs, bei denen der Server eine SMS sendet, zum Beispiel als Einmalpasswort (OTP).
• URLs, die die Nutzungszahlen eines Benutzers erhöhen, wie das Aufbrauchen ihres monatlichen Freizeilenvolumens oder das Starten des Timers für ihre monatlichen Minuten.
• URLs, die serverseitiges Ad-Conversion-Tracking initiieren.

Solche Probleme können auf dem Server durch das Beobachten des Sec-Purpose: prefetch Headers während der Anfragen verhindert werden, wobei spezifischer Code ausgeführt wird, um problematische Funktionalitäten zu verzögern. Später können Sie bei der tatsächlichen Navigation zur Seite die verzögerte Funktionalität bei Bedarf per JavaScript einleiten.

Es ist auch potenziell riskant, ein Dokument vorzuladen, dessen server-gerenderte Inhalte sich aufgrund von Aktionen ändern, die der Benutzer auf der aktuellen Seite durchführen kann. Dies könnte beispielsweise Flash-Sale-Seiten oder Sitzpläne von Kinosälen umfassen. Testen Sie solche Fälle sorgfältig und mindern Sie solche Probleme, indem Sie den Inhalt aktualisieren, sobald die Seite geladen ist. Siehe Server-rendered varying state für weitere Details zu diesen Fällen.

Prefetching ist sicher, wenn alle Nebenwirkungen des Abrufs der Seite aus der Ausführung von JavaScript resultieren, da das JavaScript erst bei der Aktivierung ausgeführt wird.

Ein letzter Tipp ist, die in Ihrer robots.txt Datei als verboten gelisteten URLs zu überprüfen — normalerwiese zeigen diese URLs auf Seiten, die nur von authentifizierten Benutzern zugänglich sind und daher nicht in Suchmaschinenergebnissen erscheinen sollten. Viele davon werden unbedenklich sein, aber es kann ein guter Ort sein, um URLs zu finden, die unsicher für das Prefetching sind (d.h. sie weisen die oben beschriebenen Bedingungen auf).

Prerendering ist risikoreicher als Prefetching zu implementieren und sollte daher sparsamer erfolgen, in Fällen, in denen es sich wirklich lohnt. Es gibt mehr unsichere Bedingungen, auf die Sie beim Prerendering achten müssen, sodass, während der Vorteil höher ist, auch das Risiko höher ist.

Wenn ein Prerender durchgeführt wird, holt sich der Browser die URL via GET und rendert und lädt den Inhalt in einen unsichtbaren Tab. Dies umfasst das Ausführen des Inhalts JavaScript und das Laden sämtlicher Subresources, einschließlich derjenigen, die durch JavaScript abgerufen werden. Inhalt kann potenziell unsicher zum Prerendern sein, wenn eines der folgenden Bedingungen beobachtet wird:

• Die URL ist unsicher zum Prefetchen. Lesen Sie den vorherigen Abschnitt zuerst, wenn Sie ihn noch nicht gemacht haben, und verstehen Sie, dass diese Bedingungen auch für unsicheres Prerendering gelten.
• Das JavaScript der Seite modifiziert den clientseitigen Speicher (zum Beispiel Web Storage oder IndexedDB) beim Laden in einer Weise, die verwiesene Effekte in anderen, nicht-vorgerenderten Seiten verursachen kann, die der Benutzer gerade ansieht.
• Die Seite führt JavaScript aus oder lädt Bilder, die Nebeneffekte verursachen, wie das Senden von Analysen, das Aufzeichnen von Anzeigeneindrücken oder auf andere Weise den Status der Anwendung modifizieren, als ob der Benutzer bereits mit ihr interagiert hätte. Auch dies kann den Ablauf der Anwendung beeinträchtigen oder zu falschem Leistungs- oder Nutzungsbericht führen. Siehe Server-rendered varying state für mehr Details zu solchen Anwendungsszenarien.

Um solche Probleme abzuschwächen, können Sie folgende Techniken verwenden:

• Beobachten Sie den Sec-Purpose: prefetch Header auf dem Server, sobald die Anfragen hereinkommen, und dann führen Sie spezifischen Code aus, um problematische Funktionen zu verzögern.
• Verwenden Sie das prerenderingchange Ereignis, um zu erkennen, wann die vorgerenderte Seite tatsächlich aktiviert wird, und führen Sie als Ergebnis Code aus. Dies ist in zwei Fällen nützlich:
  • Verzögern von Code, der problematisch sein könnte, wenn er ausgeführt wird, bevor die Seite angesehen wird. Zum Beispiel möchten Sie möglicherweise warten, bis nach der Aktivierung clientspezifischer Speicher oder serverseitiger Status mit JavaScript aktualisiert werden, um zu vermeiden, dass die Benutzeroberfläche und der Anwendungsstatus asynchron sind, beispielsweise ein Einkaufswagen, der keine Artikel anzeigt, obwohl der Benutzer welche hinzugefügt hat.
  • Wenn das oben Genannte nicht möglich ist, könnten Sie dennoch Code nach der Aktivierung erneut ausführen, um die Anwendung wieder auf den neuesten Stand zu bringen. Beispielsweise könnte eine sehr dynamische Flash-Sale-Seite auf Content-Updates angewiesen sein, die durch eine Drittanbieter-Bibliothek bereitgestellt werden. Wenn Sie die Updates nicht verzögern können, können Sie dennoch neue Updates erhalten, sobald der Benutzer die Seite anzeigt. Vorgerenderte Seiten können in Echtzeit mit der Broadcast Channel API oder über einen anderen Mechanismus wie fetch() oder einen WebSocket aktualisiert werden. Dies garantiert, dass der Benutzer aktuelle Inhalte nach der Prerendering-Aktivierung sieht.
• Verwalten Sie Ihre Drittanbieter-Analyseskripts sorgfältig — wenn möglich, verwenden Sie skripte, die sich ihrer Prerendering-Bewusstheit sind (zum Beispiel verwenden Sie die Document.prerendering Eigenschaft, um das Ausführen auf Prerendering-Seiten zu verzögern), wie Google Analytics oder NewRelic.
  • Beachten Sie, dass das Laden von Inhalten von Cross-Origin <iframe>s während des Prerenderings verzögert wird, bis die Aktivierung erfolgt. Dies geschieht, um Fehler zu vermeiden, die durch das Laden von Cross-Origin-Pages entstehen, die sich ihres Prerenderings nicht bewusst sind, und um Komplexitäten bezüglich der Frage zu vermeiden, welche Anmeldeinformationen und Speicherelemente diesen Rahmen zugänglich gemacht werden sollen. Dies bedeutet, dass Benutzer in einigen Fällen anfangs leere Frames sehen können, aber es bedeutet auch, dass die meisten Drittanbieter-Widgets wie Ad-Tech während des Prerenderings sicher verwendet werden können.
  • Für Skripts von Drittanbietern, die sich nicht bewusst sind, dass das Prerendering blockiert ist, vermeiden Sie deren Laden, bis nach der Aktivierung mithilfe des prerenderingchange Ereigntis, wie zuvor erwähnt.

Es gibt zwei Haupttypen des server-gerenderten Status, über die man sich Sorgen machen sollte: veralteter Zustand und benutzerspezifischer Zustand. Dies kann sowohl unsicheres Prefetching als auch Prerendering verursachen.

• Veralteter Zustand: Betrachten Sie das Beispiel einer servermäßig gerenderten Liste von Blog-Kommentaren, die zwischen dem Prerendern des Blogposts und dessen Ansehen veraltet sein kann. Dies könnte besonders problematisch sein, wenn die aktuelle Seite ein Administrationsbereich ist, in dem der Benutzer Spam-Kommentare löscht. Wenn der Benutzer dann zum Blog-Post navigiert, könnte er verwirrt darüber sein, warum er die Spam-Kommentare sieht, die er gerade gelöscht hat.
• Benutzerspezifischer Zustand: Betrachten Sie das Beispiel der Verfolgung des Anmeldestatus von Benutzern über ein Cookie. Probleme können wie folgt auftreten:
  • Der Benutzer besucht https://site.example/a in Tab 1 und https://site.example/b in Tab 2, während er abgemeldet ist.
  • https://site.example/b rendert https://site.example/c vor. Es wird in einem abgemeldeten Zustand vorgerendert.
  • Der Benutzer meldet sich in https://site.example in Tab 1 an.
  • Der Benutzer wechselt zu Tab 2 und klickt auf den Link zu https://site.example/c, der die vorgerenderte Seite aktiviert.
  • Tab 2 zeigt eine abgeschlossene Ansicht von https://site.example/c an, was den Benutzer verwirrt, da er dachte, er sei angemeldet.

Benutzerspezifische Zustandsprobleme können für andere Benutzereinstellungen auftreten, beispielsweise Spracheinstellungen, Dark-Mode-Präferenzen oder das Hinzufügen von Artikeln zu einem Warenkorb. Sie können auch auftreten, wenn nur ein einzelner Tab beteiligt ist:

• Angenommen der Benutzer besucht https://site.example/product.
• https://site.example.com/product rendert https://site.example.com/cart vor. Es rendert mit 0 Artikeln im Warenkorb.
• Der Benutzer klickt auf die "In den Warenkorb"-Buttons, was eine Abfragung zum Hinzufügen des Artikels zum Benutzer-Warenkorb initiert (ohne das Neuladen der Seite).
• Der Benutzer klickt auf den Link zu https://site.example.com/cart, was die gerenderte Seite aktiviert.
• Der Benutzer sieht einen leeren Warenkorb, obwohl er gerade etwas hinzugefügt hat.

Die beste Vorbeugung gegen diese Fälle und in der Tat zu jeder Zeit, wenn Inhalte nicht synchron mit dem Server gelangen können, ist, dass sich Seiten bei Bedarf selbst aktualisieren. Zum Beispiel könnte ein Server die Broadcast Channel API oder einen anderen Mechanismus wie fetch() oder einen WebSocket verwenden. Seiten können sich dann entsprechend aktualisieren, einschließlich spekulativ geladener Seiten, die noch nicht aktiviert wurden.

Die Aktivierung eines prerendered/prerendering Dokuments verhält sich wie jede herkömmliche Navigation aus Sicht des Endbenutzers. Das aktivierte Dokument wird im Tab angezeigt und der Sitzungsgeschichte hinzugefügt, und alle vorhandenen Weitergeschichten-Einträge werden gekürzt. Alle Navigationen, die im Prerendering Browsing-Kontext vor der Aktivierung stattfinden, wirken sich nicht auf die Sitzungsgeschichte aus.

Aus der Sicht des Entwicklers kann ein Prerendering-Dokument als eine triviale Sitzungsgeschichte betrachtet werden, bei der nur ein einziger Eintrag — der aktuelle Eintrag — existiert. Alle Navigationen innerhalb des Prerendering-Kontexts werden effektiv ersetzt.

Während API-Funktionen, die auf Sitzungsgeschichte arbeiten (zum Beispiel History und Navigation) innerhalb von Prerendering-Dokumenten aufgerufen werden können, arbeiten sie nur an der trivialen Sitzungsgeschichte des Kontexts. Folglich nehmen Prerendering-Dokumente nicht an der gemeinsamen Sitzungsgeschichte ihrer verweisenden Seite teil. Zum Beispiel können sie ihren Referrer nicht über History.back() navigieren.

Dieses Design stellt sicher, dass Benutzer die erwartete Erfahrung erhalten, wenn sie den Rückwärtspfeil verwenden — das heißt, dass sie zurück zu dem letzten, was sie gesehen haben, gelangen. Sobald ein Prerendering-Dokument aktiviert wird, wird nur ein einzelner Sitzungsgeschichteeintrag an die gemeinsame Sitzungsgeschichte angefügt, wobei alle vorherigen Navigationen, die im Prerendering-Browsing-Kontext stattgefunden haben, ignoriert werden. Ein Schritt zurück zu gehen in der gemeinsamen Sitzungsgeschichte — zum Beispiel, indem Sie den Rückwärtspfeil drücken — führt den Benutzer zurück zur verweisenden Seite.

Da eine vorgerenderte Seite in einem verborgenen Zustand geöffnet wird, werden mehrere API-Funktionalitäten, die potenziell intrusives Verhalten verursachen können, in diesem Zustand nicht aktiviert und sind stattdessen zurückgestellt, bis die Seite aktiviert wird. Andere Webplattform-Funktionen, die problematisch beim Prerendering sind, werden ganz eingeschränkt. Dieser Abschnitt bietet Details darüber, welche Merkmale zurückgestellt oder eingeschränkt sind.

Zurückstellung bedeutet, dass die API-Funktion sofort ein ausstehendes Versprechen zurückgibt und dann nichts tut, bis die Seite aktiviert wird. Nach der Aktivierung läuft die Funktion wie gewohnt und das Versprechen wird wie gewohnt aufgelöst oder abgelehnt.

Die Ergebnisse der folgenden asynchronen Funktionen werden in vorgerenderten Dokumenten bis zur Aktivierung aufgeschoben:

• 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 nicht fortschreiten, während das enthaltende Dokument prerendert wird
• 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 dürfen nicht gestartet werden, während 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()

Die folgenden Features werden in Dokumenten, die nicht aktiviert sind, automatisch fehlschlagen oder nicht ausgeführt.

APIs, die transiente Aktivierung oder dauerhafte Aktivierung erfordern:

• Bestätigungsdialoge, die durch das beforeunload Event erzeugt werden
• Das Auslösen von Events in der Zwischenablage-API.
• Dateisystem-API: Window.showDirectoryPicker(), Window.showOpenFilePicker(), Window.showSaveFilePicker()
• Vollbild-API: Element.requestFullscreen()
• Idle Detection API: IdleDetector.requestPermission()
• Tastatur-API: Keyboard.lock() (erfordert Vollbildschirm)
• Payment Request API: PaymentRequest.show()
• Präsentations-API: PresentationRequest.start()
• Zeiger-Sperr-API: Element.requestPointerLock()
• Bildschirmaufnahme-API: MediaDevices.getDisplayMedia()
• Web Share API: Navigator.share()
• Window.open()

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

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

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

• Bild-im-Bild-API: HTMLVideoElement.requestPictureInPicture() (erfordert den Sichtbarkeitsstatus des enthaltenden Dokuments auf "sichtbar" oder transiente Aktivierung)
• Bildschirmwach-Sperre-API: WakeLock.request()

• Download-Links, d.h. <a> und <area> Elemente mit dem download Attribut, werden ihre Downloads verzögern, bis das Prerendering abgeschlossen 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.
• Eingeschränkte URLs: Prerendering-Dokumente können keine nicht-HTTP(S) Top-Level-URLs hosten. Das Einfügen der folgenden URL-Typen führt dazu, dass das Prerendering sofort verworfen wird:
  • javascript: URLs
  • data: URLs
  • blob: URLs
  • about: URLs, einschließlich about:blank und about:srcdoc
• Sitzungsspeicher: Window.sessionStorage kann verwendet werden, aber das Verhalten ist sehr spezifisch, um keine Websites zu unterbrechen, die erwarten, dass nur eine Seite auf den Sitzungsspeicher des Tabs gleichzeitig zugreift. Eine vorgerenderte Seite startet daher mit einem Klon des Sitzungsspeicherstatus des Tabs, ab wann sie erstellt wird. Nach der Aktivierung des Klons der vorgerenderten Seite wird verworfen, und der Hauptspeicherstatus des Tabs wird stattdessen verwendet. Seiten, die Sitzungsspeicher verwenden, können das prerenderingchange Ereignis nutzen, um zu erkennen, wann dieser Speicherungstausch erfolgt.
• Window.print(): Alle Aufrufe dieser Methode werden ignoriert.
• "Einfache Dialogmethoden" sind wie folgt eingeschränkt:
  • Window.alert() gibt sofort ohne Anzeige eines Dialogs zurück.
  • Window.confirm() gibt sofort false ohne Anzeige eines Dialogs zurück.
  • Window.prompt() gibt sofort einen leeren String ("") ohne Anzeige eines Dialogs zurück.
• Dedizierte/geteilte Worker-Skripte werden geladen, aber ihre Ausführung wird bis zur Aktivierung des vorgerenderten Dokuments aufgeschoben.
• Cross-origin <iframe> Ladevorgänge werden während des Prerenderings bis nach der Aktivierung der Seite aufgeschoben.

Die Speculation Rules API definiert keine eigenen Schnittstellen.

Document.prerendering Experimentell

Eine boolesche Eigenschaft, die true zurückgibt, wenn das Dokument sich derzeit im Prozess des Vorbereitens befindet.

prerenderingchange Ereignis Experimentell

Ausgelöst bei einem vorgerenderten Dokument, wenn es aktiviert wird (d.h. der Benutzer die Seite ansieht).

PerformanceNavigationTiming.activationStart Experimentell

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

PerformanceResourceTiming.deliveryType "navigational-prefetch" Wert Experimentell

Signalisiert, dass es sich bei der Art eines Leistungseintrags um ein Prefetch handelt.

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

Wird verwendet, um die Verwendung von <script type="speculationrules"> zu erlauben, um Spekulationsregeln für das abzurufende Dokument festzulegen.

Speculation-Rules Experimentell

Bietet eine Liste von URLs, die auf Textressourcen mit Spekulationsregel-JSON-Definitionen zeigen. Wenn die Antwort ein HTML-Dokument ist, werden diese Regeln zur Spekulationsregelmenge des Dokuments hinzugefügt.

Supports-Loading-Mode Experimentell

Wird von einem Navigationsziel gesetzt, um verschiedene höher riskierende Lademoden zu verwenden. Zum Beispiel erfordert das Cross-Origin, Same-Site Prerendering einen Supports-Loading-Mode Wert von credentialed-prerender.

<script type="speculationrules"> Experimentell

Wird verwendet, um ein Set von Prefetch- und/oder Prerender Spekulationsregeln innerhalb des aktuellen Dokuments zu definieren, die zur Spekulationsregelmenge des Dokuments hinzugefügt werden.

Sie finden eine vollständige Demo zum Prerendering hier.

• Prerender pages in Chrome for instant page navigations auf developer.chrome.com (2023)
• Spekulatives Laden für einen Vergleich von Spekulationsregeln und anderen ähnlichen Leistungsoptimierungsfunktionen.