Für eine sofortige Seitennavigation in Chrome vorab rendern

Barry Pollard

Veröffentlicht: 2. Dezember 2022, zuletzt aktualisiert: 29. Oktober 2026

Browser Support

  • Chrome: 109.
  • Edge: 109.
  • Firefox Technology Preview: supported.
  • Safari: behind a flag.

Source

Das Chrome-Team hat das vollständige Prerendering von zukünftigen Seiten, die ein Nutzer wahrscheinlich aufrufen wird, wieder eingeführt.

Kurzer Überblick über die Geschichte des Prerenderings

In der Vergangenheit hat Chrome den Ressourcenhinweis <link rel="prerender" href="/next-page"> unterstützt. Er wurde jedoch außerhalb von Chrome nicht allgemein unterstützt und war keine sehr aussagekräftige API.

Dieses alte Pre-Rendering mit dem Link-Hinweis rel=prerender wurde zugunsten von NoState Prefetch eingestellt. Dabei wurden die für die zukünftige Seite erforderlichen Ressourcen abgerufen, die Seite wurde jedoch nicht vollständig vorab gerendert und es wurde kein JavaScript ausgeführt. NoState Prefetch trägt zwar zur Verbesserung der Seitenleistung bei, da das Laden von Ressourcen optimiert wird, aber die Seite wird nicht sofort geladen, wie es bei einem vollständigen Pre-Rendering der Fall wäre.

Das Chrome-Team hat das vollständige Prerendering jetzt wieder in Chrome eingeführt. Um Komplikationen mit der bestehenden Nutzung zu vermeiden und eine zukünftige Erweiterung des Pre-Renderings zu ermöglichen, wird dieser neue Pre-Rendering-Mechanismus nicht die Syntax <link rel="prerender"...> verwenden, die für NoState Prefetch beibehalten wird, mit dem Ziel, diese irgendwann in der Zukunft einzustellen.

Wie wird eine Seite vorab gerendert?

Eine Seite kann auf eine von vier Arten vorgerendert werden, die alle darauf abzielen, die Navigation zu beschleunigen:

  1. Wenn Sie eine URL in die Chrome-Adressleiste (auch „Omnibox“ genannt) eingeben, kann Chrome die Seite automatisch vorab rendern, wenn die Wahrscheinlichkeit hoch ist, dass Sie diese Seite besuchen werden. Dies wird anhand Ihres bisherigen Browserverlaufs ermittelt.
  2. Wenn Sie die Lesezeichenleiste verwenden, kann Chrome die Seite automatisch vorab rendern, wenn Sie den Mauszeiger auf eine der Lesezeichenschaltflächen bewegen.
  3. Wenn Sie einen Suchbegriff in die Chrome-Adressleiste eingeben, rendert Chrome die Suchergebnisseite möglicherweise automatisch vor, wenn die Suchmaschine dies anweist.
  4. Websites können die Speculation Rules API verwenden, um Chrome programmatisch mitzuteilen, welche Seiten vorab gerendert werden sollen. Dies ersetzt die bisherige Funktion von <link rel="prerender"...> und ermöglicht es Websites, eine Seite proaktiv auf Grundlage von Spekulationsregeln auf der Seite vorab zu rendern. Diese können statisch auf den Seiten vorhanden sein oder dynamisch von JavaScript eingefügt werden, je nachdem, was der Seitenbetreiber für angemessen hält.

In jedem dieser Fälle verhält sich ein Prerender so, als ob die Seite in einem unsichtbaren Hintergrund-Tab geöffnet und dann „aktiviert“ wurde, indem der Vordergrund-Tab durch diese vorab gerenderte Seite ersetzt wurde. Wenn eine Seite aktiviert wird, bevor sie vollständig vorgerendert wurde, ist ihr aktueller Status „im Vordergrund“ und sie wird weiter geladen. Das bedeutet, dass Sie trotzdem einen guten Vorsprung haben.

Da die vorgerenderte Seite im Hintergrund geöffnet wird, werden einige APIs, die störendes Verhalten verursachen (z. B. Aufforderungen), in diesem Zustand nicht aktiviert, sondern erst, wenn die Seite aktiviert wird. In den wenigen Fällen, in denen dies noch nicht möglich ist, wird das Prerendering abgebrochen. Das Chrome-Team arbeitet daran, die Gründe für den Abbruch des Prerenderings als API bereitzustellen und die Funktionen der Entwicklertools zu verbessern, um solche Grenzfälle leichter zu erkennen.

Auswirkungen des Pre-Renderings

Das Prerendering ermöglicht einen nahezu sofortigen Seitenaufbau, wie im folgenden Video gezeigt:

Beispiel für die Auswirkungen des Pre-Renderings.

Die Beispielwebsite ist bereits schnell, aber selbst hier ist zu sehen, wie das Prerendering die Nutzerfreundlichkeit verbessert. Dies kann sich auch direkt auf die Core Web Vitals einer Website auswirken, da der LCP-Wert nahezu null ist, der CLS-Wert reduziert wird (da der CLS-Wert vor der ersten Ansicht auftritt) und der INP-Wert verbessert wird (da der Ladevorgang abgeschlossen sein sollte, bevor der Nutzer interagiert).

Selbst wenn eine Seite aktiviert wird, bevor sie vollständig geladen ist, sollte der Vorsprung beim Seitenaufbau die Ladeerfahrung verbessern. Wenn ein Link aktiviert wird, während das Vorab-Rendering noch läuft, wird die vorab gerenderte Seite in den Hauptframe verschoben und weiter geladen.

Das Prerendering verbraucht jedoch zusätzlichen Arbeitsspeicher und zusätzliche Netzwerkbandbreite. Achten Sie darauf, nicht zu viel vorab zu rendern, da dies Nutzerressourcen kostet. Prerendering nur dann verwenden, wenn die Wahrscheinlichkeit hoch ist, dass die Seite aufgerufen wird.

Weitere Informationen dazu, wie Sie die tatsächlichen Auswirkungen auf die Leistung in Ihren Analysen messen, finden Sie im Abschnitt Leistung messen.

Vervollständigungen in der Adressleiste von Chrome ansehen

Für den ersten Anwendungsfall können Sie sich die Vervollständigungen von Chrome für URLs auf der Seite chrome://predictors ansehen:

Die Seite „Chrome Predictors“ (Chrome-Vervollständigungen), gefiltert nach niedrigen (grau), mittleren (gelb) und hohen (grün) Vervollständigungen basierend auf dem eingegebenen Text.
Seite „Chrome Predictors“

Grüne Linien weisen auf eine ausreichende Konfidenz hin, um das Prerendering auszulösen. In diesem Beispiel wird durch die Eingabe von „s“ eine angemessene Konfidenz (gelb) erreicht. Sobald Sie jedoch „sh“ eingeben, ist Chrome sich sicher genug, dass Sie fast immer zu https://sheets.google.com navigieren.

Dieser Screenshot wurde in einer relativ neuen Chrome-Installation aufgenommen, wobei Vervollständigungen mit einer Konfidenz von null herausgefiltert wurden. Wenn Sie sich Ihre eigenen Vervollständigungen ansehen, werden Sie wahrscheinlich wesentlich mehr Einträge sehen und möglicherweise mehr Zeichen benötigen, um ein ausreichend hohes Konfidenzniveau zu erreichen.

Diese Prädiktoren sind auch für die Vorschläge in der Adressleiste verantwortlich, die Sie vielleicht schon bemerkt haben:

Die Funktion „Typeahead“ in der Chrome-Adressleiste
Funktion „Typeahead“ in der Adressleiste

Chrome aktualisiert die Vorhersagen kontinuierlich basierend auf Ihren Eingaben und Ihrer Auswahl.

  • Bei einem Konfidenzniveau von mehr als 30 % (orange dargestellt) stellt Chrome proaktiv eine Verbindung zur Domain her, rendert die Seite aber nicht vorab.
  • Bei einem Konfidenzniveau von mehr als 50 % (grün dargestellt) wird die URL in Chrome vorab gerendert.

Die Speculation Rules API

Für die Vorrendering-Option der Speculation Rules API können Webentwickler JSON-Anweisungen in ihre Seiten einfügen, um dem Browser mitzuteilen, welche URLs vorgerendert werden sollen.

URL-Listen

Spekulationsregeln können auf Listen von URLs basieren:

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

Dokumentregeln

Spekulationsregeln können auch „Dokumentregeln“ sein, die die where-Syntax verwenden. Dabei werden Links im Dokument anhand von href-Selektoren (basierend auf der URL Pattern API) oder CSS-Selektoren ermittelt:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"href_matches": "/wp-admin"}},
        { "not": {"href_matches": "/*\\?*(^|&)add-to-cart=*"}},
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel~=nofollow]"}}
      ]
    }
  }]
}
</script>

Eifer

Browser Support

  • Chrome: 121.
  • Edge: 121.
  • Firefox Technology Preview: supported.
  • Safari: behind a flag.

Source

Mit der Einstellung eagerness wird angegeben, wann die Spekulationen ausgelöst werden sollen. Das ist besonders für Dokumentregeln nützlich:

  • conservative: Hier wird spekuliert, ob der Nutzer den Mauszeiger oder den Finger auf den Bildschirm bewegt.
  • moderate: Auf dem Computer werden Spekulationen durchgeführt, wenn Sie den Mauszeiger 200 Millisekunden lang auf einem Link halten (oder beim pointerdown-Ereignis, falls dieses früher eintritt, und auf Mobilgeräten, wo es kein hover-Ereignis gibt). Auf Mobilgeräten basiert die Berechnung seit August 2025 auf komplexen Viewport-Heuristiken. Komplexe Heuristiken für den Darstellungsbereich werden 500 ms nach dem Beenden des Scrollens durch den Nutzer ausgelöst, und zwar für Anker, die sich innerhalb von 30 % des vertikalen Abstands vom vorherigen Pointer-Down-Ereignis befinden, wobei die Anker mindestens 0,5-mal so groß sind wie der größte Anker im Darstellungsbereich. Wie in diesem Dokument beschrieben.
  • eager: Diese Eagerness-Stufe verhielt sich früher identisch mit immediate, wurde aber ab Chrome 143 geändert. Auf dem Computer werden Spekulationen durchgeführt, wenn Sie den Mauszeiger 10 Millisekunden lang über einen Link halten. Auf Mobilgeräten haben wir die Berechnung im Januar 2026 auf einfache Darstellungsbereich-Heuristiken umgestellt. Einfache Darstellungsbereich-Heuristiken werden 50 ms nach dem Eintritt des Ankers in den Darstellungsbereich ausgelöst.
  • immediate: Damit wird so schnell wie möglich spekuliert, d. h. sobald die Spekulationsregeln erkannt werden.

Der Standardwert für eagerness für list-Regeln ist immediate. Mit den Optionen eager, moderate und conservative können Sie list-Regeln auf URLs beschränken, mit denen ein Nutzer interagiert, und zwar auf eine bestimmte Liste. In vielen Fällen sind jedoch document-Regeln mit einer entsprechenden where-Bedingung besser geeignet.

Der Standardwert für eagerness für document-Regeln ist conservative. Da ein Dokument aus vielen URLs bestehen kann, sollte immediate für document-Regeln mit Vorsicht verwendet werden (siehe auch den Abschnitt Chrome-Limits unten).

Welche eagerness-Einstellung Sie verwenden sollten, hängt von Ihrer Website ab. Bei einer einfachen, statischen Website ist die Spekulation möglicherweise mit geringen Kosten verbunden und für Nutzer von Vorteil. Bei Websites mit komplexeren Architekturen und größeren Seitennutzlasten kann es sinnvoll sein, weniger häufig zu spekulieren, bis mehr positive Signale von Nutzern vorliegen, um die Verschwendung von Ressourcen zu begrenzen.

Die Option moderate ist ein Mittelweg. Viele Websites könnten von der folgenden Spekulationsregel profitieren, die einen Link vorab rendert, wenn der Mauszeiger 200 Millisekunden lang über dem Link gehalten wird, oder beim pointerdown-Ereignis. Das ist eine einfache, aber leistungsstarke Implementierung von Spekulationsregeln:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "href_matches": "/*"
    },
    "eagerness": "moderate"
  }]
}
</script>

Prefetch

Spekulationsregeln können auch verwendet werden, um Seiten nur vorab abzurufen, ohne ein vollständiges Pre-Rendering durchzuführen. Das kann oft ein guter erster Schritt auf dem Weg zum Prerendering sein:

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

Prerender until script

Das Chrome-Team arbeitet außerdem daran, prerender_until_script zur Speculation Rules API hinzuzufügen (siehe Implementierungsfehler). Dies wäre ein Schritt zwischen Prefetch und Prerender und würde auf ähnliche Weise verwendet werden:

<script type="speculationrules">
{
  "prerender_until_script": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

Ähnlich wie bei NoState prefetch werden hier sowohl das HTML-Dokument als auch die in diesem HTML-Dokument verfügbaren Unterressourcen vorab abgerufen. Es geht jedoch noch weiter und beginnt auch mit dem Vorrendering der Seite. Dieser Vorgang wird beendet, wenn das erste Script gefunden wird.

Das bedeutet, dass Seiten ohne JavaScript oder mit JavaScript nur in der Fußzeile fast vollständig im Voraus gerendert werden können. Seiten mit Skripts im <head> können nicht vorab gerendert werden, profitieren aber trotzdem vom Abrufen von Unterressourcen.

So werden die Risiken unbeabsichtigter Nebenwirkungen durch die Ausführung von JavaScript vermieden, aber es wird ein viel größerer Leistungszuwachs als nur prefetch erzielt.

Chrome-Limits

Chrome hat Limits, um eine übermäßige Nutzung der Spekulationsregeln-API zu verhindern:

Eifer Prefetch Pre-Rendering
immediate 50 10
eager/moderate auf Mobilgeräten 6 (FIFO) 2 (FIFO)
eager / moderate auf dem Computer 2 (FIFO) 2 (FIFO)
conservative 2 (FIFO) 2 (FIFO)
Limits für Spekulationen in Chrome

Die Einstellungen eager, moderate und conservative, die von der Nutzerinteraktion abhängen, funktionieren nach dem First-In-First-Out-Prinzip (FIFO): Wenn das Limit erreicht ist, wird die älteste Spekulation durch eine neue Spekulation abgebrochen und ersetzt, um Arbeitsspeicher zu sparen.

Eine abgebrochene Spekulation kann wieder ausgelöst werden, z. B. wenn der Nutzer den Mauszeiger wieder auf den Link bewegt. Dadurch wird die URL noch einmal spekuliert und die älteste Spekulation wird entfernt. In diesem Fall wurden bei der vorherigen Spekulation alle im HTTP-Cache speicherbaren Ressourcen für diese URL im Cache gespeichert. Eine weitere Spekulation sollte daher weniger kosten. Aus diesem Grund ist das Limit standardmäßig auf den moderaten Schwellenwert 2 festgelegt. Für das Prefetching auf Mobilgeräten verwenden wir einen höheren Schwellenwert von 6, da es kein „Hover“ gibt, die alternativen Heuristiken für den mobilen Darstellungsbereich weniger genau sind und das Prefetching weniger kostspielig ist als das Prerendering (für das Prerendering auf Mobilgeräten gilt weiterhin der Grenzwert von 2).

Regeln für statische Listen werden nicht durch eine Nutzeraktion ausgelöst und haben daher ein höheres Limit, da der Browser nicht wissen kann, welche Regeln wann benötigt werden.

Chrome erwägt auch, das Limit auf Mobilgeräten für eager und moderate zumindest für das Prefetching auf 5 zu erhöhen, da es sich hierbei um eine weniger präzise Heuristik handelt. Entwickler, die eager verwenden, sollten zusätzlich conservative-Regeln verwenden, wenn mehrere Links im Darstellungsbereich verfügbar sind. So wird auch dann spekuliert, wenn sie nicht als einer der ersten beiden Links ausgewählt werden.

Das Limit für immediate ist ebenfalls dynamisch. Wenn Sie also ein list-URL-Skriptelement entfernen, wird Kapazität frei, da die entfernten Spekulationen abgebrochen werden.

Chrome verhindert auch, dass Spekulationen unter bestimmten Bedingungen verwendet werden, z. B.:

  • Save-Data:
  • Energiesparmodus, wenn er aktiviert ist und der Akkustand niedrig ist.
  • Speicherbeschränkungen.
  • Wenn die Einstellung „Seiten vorab laden“ deaktiviert ist (was auch durch Chrome-Erweiterungen wie uBlock Origin explizit deaktiviert wird).
  • Seiten, die in Hintergrund-Tabs geöffnet wurden.

Außerdem werden ursprungsübergreifende iFrames auf vorab gerenderten Seiten erst nach der Aktivierung gerendert.

Alle diese Bedingungen zielen darauf ab, die Auswirkungen von übermäßiger Spekulation zu reduzieren, wenn sie für Nutzer schädlich wäre.

Spekulationsregeln auf einer Seite einfügen

Spekulationsregeln können statisch in den HTML-Code der Seite eingefügt oder dynamisch per JavaScript in die Seite eingefügt werden:

  • Statisch enthaltene Spekulationsregeln: Auf einer Nachrichten- oder Blogwebsite kann beispielsweise der neueste Artikel vorgerendert werden, wenn dies für einen großen Teil der Nutzer oft der nächste Schritt ist. Alternativ können Dokumentregeln mit moderate oder conservative verwendet werden, um Spekulationen anzustellen, wenn Nutzer mit Links interagieren.
  • Dynamisch eingefügte Spekulationsregeln: Diese können auf der Anwendungslogik basieren, für den Nutzer personalisiert sein oder auf anderen Heuristiken beruhen.

Wenn Sie die dynamische Einfügung basierend auf Aktionen wie dem Bewegen des Mauszeigers über einen Link oder dem Klicken auf einen Link bevorzugen, wie es in der Vergangenheit bei vielen Bibliotheken mit <link rel=prefetch> der Fall war, sollten Sie sich die Dokumentregeln ansehen. Damit kann der Browser viele Ihrer Anwendungsfälle verarbeiten.

Spekulationsregeln können entweder im <head> oder im <body> des Hauptframes hinzugefügt werden. Spekulationsregeln in Subframes werden nicht berücksichtigt. Spekulationsregeln auf vorgerenderten Seiten werden erst berücksichtigt, wenn die Seite aktiviert wird.

Der Speculation-Rules-HTTP-Header

Browser Support

  • Chrome: 121.
  • Edge: 121.
  • Firefox: not supported.
  • Safari: behind a flag.

Source

Spekulationsregeln können auch über einen Speculation-Rules-HTTP-Header bereitgestellt werden, anstatt sie direkt in den HTML-Code des Dokuments einzufügen. Dies ermöglicht eine einfachere Bereitstellung durch CDNs, ohne dass der Dokumentinhalt selbst geändert werden muss.

Der HTTP-Header Speculation-Rules wird mit dem Dokument zurückgegeben und verweist auf den Speicherort einer JSON-Datei, die die Spekulationsregeln enthält:

Speculation-Rules: "/speculationrules.json"

Diese Ressource muss den richtigen MIME-Typ verwenden und, wenn es sich um eine ursprungsübergreifende Ressource handelt, eine CORS-Prüfung bestehen.

Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *

Wenn Sie relative URLs verwenden möchten, sollten Sie den Schlüssel "relative_to": "document" in Ihre Spekulationsregeln aufnehmen. Andernfalls beziehen sich relative URLs auf die URL der JSON-Datei mit den Spekulationsregeln. Das kann besonders nützlich sein, wenn Sie einige oder alle Links mit demselben Ursprung auswählen müssen.

Tag-Feld für Spekulationsregeln

Browser Support

  • Chrome: 136.
  • Edge: 136.
  • Firefox: not supported.
  • Safari: behind a flag.

Source

Es ist auch möglich, in der JSON-Syntax der Spekulationsregeln auf der Gesamtebene für alle Spekulationsregeln in einem Regelsatz „Tags“ hinzuzufügen:

{
  "tag": "my-rules",
  "prefetch": [{
      "urls": ["next.html"]
  }],
  "prerender": [{
      "urls": ["next2.html"]
  }]
}

Oder auf der Ebene der einzelnen Regeln:

{
  "prefetch": [{
    "tag": "my-prefetch-rules",
    "urls": ["next.html"]
  }],
  "prerender": [{
    "tag": "my-prerender-rules",
    "urls": ["next2.html"]
  }]
}

Dieses Tag wird dann im HTTP-Header Sec-Speculation-Tags wiedergegeben, mit dem Spekulationsregeln auf dem Server gefiltert werden können. Der HTTP-Header Sec-Speculation-Tags kann mehrere Tags enthalten, wenn die Spekulation durch mehrere Regeln abgedeckt ist, wie im folgenden Beispiel gezeigt:

Sec-Speculation-Tags: null
Sec-Speculation-Tags: null, "cdn-prefetch"
Sec-Speculation-Tags: "my-prefetch-rules"
Sec-Speculation-Tags: "my-prefetch-rules", "my-rules", "cdn-prefetch"

Einige CDNs fügen automatisch Spekulationsregeln ein, blockieren jedoch Spekulationen für Seiten, die nicht im Edge-Cache gespeichert sind, um zu verhindern, dass diese Funktion zu einer erhöhten Nutzung des Ursprungsservers führt. Mithilfe von Tags können sie Spekulationen identifizieren, die durch ihren Standardregelsatz initiiert wurden, aber dennoch alle von der Website hinzugefügten Regeln an den Ursprung weitergeben.

Regelsatz-Tags werden auch in den Chrome-Entwicklertools angezeigt.

Feld target_hint für Spekulationsregeln

Browser Support

  • Chrome: 138.
  • Edge: 138.
  • Firefox: not supported.
  • Safari: not supported.

Source

Spekulationsregeln können auch ein target_hint-Feld enthalten, das einen gültigen Namen oder ein gültiges Schlüsselwort für den Browserkontext enthält, der angibt, wo die Seite erwartet, dass der vorgerenderte Inhalt aktiviert wird:

<script type=speculationrules>
{
  "prerender": [{
    "target_hint": "_blank",
    "urls": ["next.html"]
  }]
}
</script>

Mit diesem Hinweis können Prerendering-Spekulationen für target="_blank"-Links verarbeitet werden:

<a target="_blank" href="next.html">Open this link in a new tab</a>

Derzeit werden in Chrome nur "target_hint": "_blank" und "target_hint": "_self" (Standard, wenn nicht angegeben) unterstützt, und zwar nur für das Prerendering. Prefetching wird nicht unterstützt.

target_hint ist nur für urls-Spekulationsregeln erforderlich, da bei Dokumentregeln die target aus dem Link selbst bekannt ist.

Spekulationsregeln und SPAs

Spekulationsregeln werden nur für die Navigation auf ganzen Seiten unterstützt, die vom Browser verwaltet wird, und nicht für Single-Page-Anwendungen (SPAs) oder Anwendungsshell-Seiten. Diese Architekturen verwenden keine Dokumentabrufe, sondern rufen Daten oder Seiten über die API oder teilweise ab. Diese werden dann verarbeitet und auf der aktuellen Seite dargestellt. Die für diese sogenannten „Soft Navigations“ erforderlichen Daten können von der App außerhalb von Spekulationsregeln vorab abgerufen, aber nicht vorab gerendert werden.

Mit Spekulationsregeln kann die Anwendung selbst von einer vorherigen Seite vorab gerendert werden. So können Sie einen Teil der zusätzlichen anfänglichen Ladekosten ausgleichen, die bei einigen SPAs anfallen. Routenänderungen innerhalb der App können jedoch nicht vorab gerendert werden.

Spekulationsregeln debuggen

Im speziellen Beitrag zum Debuggen von Spekulationsregeln finden Sie Informationen zu neuen Chrome-Entwicklertools-Funktionen, mit denen Sie diese neue API aufrufen und debuggen können.

Mehrere Spekulationsregeln

Es können auch mehrere Spekulationsregeln auf derselben Seite hinzugefügt werden, die dann an die vorhandenen Regeln angehängt werden. Daher führen die folgenden verschiedenen Möglichkeiten alle zum Prerendering von one.html und two.html:

URL-Liste:

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["one.html", "two.html"]
  }]
}
</script>

Mehrere speculationrules-Skripts:

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["one.html"]
  }]
}
</script>
<script type="speculationrules">
{
  "prerender": [{
    "urls": ["two.html"]
  }]
}
</script>

Mehrere Listen innerhalb einer Gruppe von speculationrules

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    },
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

Browser Support

  • Chrome: 141.
  • Edge: 141.
  • Firefox: 154.
  • Safari: not supported.

Source

Beim Prefetching oder Prerendering einer Seite sind bestimmte URL-Parameter (technisch als Suchparameter bezeichnet) für die vom Server tatsächlich bereitgestellte Seite möglicherweise nicht relevant und werden nur von clientseitigem JavaScript verwendet.

Beispielsweise werden UTM-Parameter von Google Analytics für die Kampagnenanalyse verwendet, führen aber in der Regel nicht dazu, dass unterschiedliche Seiten vom Server bereitgestellt werden. Das bedeutet, dass page1.html?utm_content=123 und page1.html?utm_content=456 dieselbe Seite vom Server liefern, sodass dieselbe Seite aus dem Cache wiederverwendet werden kann.

Ebenso können Anwendungen andere URL-Parameter verwenden, die nur clientseitig verarbeitet werden.

Mit dem Vorschlag No-Vary-Search kann ein Server Parameter angeben, die keinen Unterschied zur bereitgestellten Ressource bewirken. Dadurch kann ein Browser zuvor im Cache gespeicherte Versionen eines Dokuments wiederverwenden, die sich nur durch diese Parameter unterscheiden. Dies wird in Chrome (und Chromium-basierten Browsern) für Navigationsspekulationen sowohl für Prefetch als auch für Prerender unterstützt.

Spekulationsregeln unterstützen die Verwendung von expects_no_vary_search, um anzugeben, wo ein No-Vary-Search-HTTP-Header zurückgegeben werden soll. So können Sie unnötige Downloads vermeiden, bevor die Antworten angezeigt werden.

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["/products"],
    "expects_no_vary_search": "params=(\"id\")"
  }]
}
</script>

<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>

In diesem Beispiel ist der ursprüngliche HTML-Code der Seite /products für beide Produkt-IDs 123 und 124 identisch. Der Seiteninhalt unterscheidet sich jedoch letztendlich aufgrund des clientseitigen Renderings mit JavaScript, um Produktdaten mit dem Suchparameter id abzurufen. Wir rufen diese URL also vorab ab. Sie sollte einen No-Vary-Search-HTTP-Header zurückgeben, der zeigt, dass die Seite für jeden id-Suchparameter verwendet werden kann.

Wenn der Nutzer jedoch auf einen der Links klickt, bevor der Prefetch abgeschlossen ist, hat der Browser die /products-Seite möglicherweise noch nicht empfangen. In diesem Fall weiß der Browser nicht, ob er den HTTP-Header No-Vary-Search enthalten wird. Der Browser kann dann entscheiden, ob er den Link noch einmal abruft oder wartet, bis der Prefetch abgeschlossen ist, um zu sehen, ob er einen No-Vary-Search-HTTP-Header enthält. Mit der Einstellung expects_no_vary_search wird der Browser darüber informiert, dass die Seitenantwort voraussichtlich einen No-Vary-Search-HTTP-Header enthält, und wartet, bis der Prefetch abgeschlossen ist.

Sie können expects_no_vary_search auch mehrere Parameter hinzufügen, die durch ein Leerzeichen getrennt sind, da No-Vary-Search ein strukturierter HTTP-Header ist:

    "expects_no_vary_search": "params=(\"param1\" \"param2\" \"param3\")"

Einschränkungen und zukünftige Verbesserungen bei Spekulationsregeln

Spekulationsregeln sind auf Seiten beschränkt, die im selben Tab geöffnet werden. Wir arbeiten jedoch daran, diese Einschränkung zu reduzieren.

Standardmäßig ist das Prerendering auf Seiten mit demselben Ursprung beschränkt. Das Pre-Rendering von ursprungsübergreifenden Seiten auf derselben Website (z. B. kann https://a.example.com eine Seite auf https://b.example.com vorab rendern) kann aktiviert werden. Damit dies funktioniert, muss die spekulierte Seite (in diesem Beispiel https://b.example.com) die Funktion aktivieren, indem sie einen Supports-Loading-Mode: credentialed-prerender-HTTP-Header enthält. Andernfalls bricht Chrome die Spekulation ab.

In zukünftigen Versionen ist möglicherweise auch das Pre-Rendering für ursprungsübergreifende Seiten auf anderen Websites zulässig, sofern für die vorab gerenderte Seite keine Cookies vorhanden sind und die vorab gerenderte Seite einen ähnlichen Supports-Loading-Mode: uncredentialed-prerender-HTTP-Header verwendet.

Spekulationsregeln unterstützen bereits ursprungsübergreifende Prefetches. Für ursprungsübergreifende Prefetches auf derselben Website gibt es keine Einschränkungen. Ursprungsübergreifendes Prefetching für andere Websites wird nur unterstützt, wenn keine Cookies für die ursprungsübergreifende Domain vorhanden sind. Wenn Cookies vorhanden sind, weil der Nutzer die Website schon einmal besucht hat, wird die Spekulation nicht verwendet und in den DevTools wird ein Fehler angezeigt.

Angesichts dieser aktuellen Einschränkungen gibt es ein Muster, mit dem Sie die Nutzerfreundlichkeit sowohl für interne als auch für externe Links verbessern können, sofern möglich: Rendern Sie URLs desselben Ursprungs vorab und versuchen Sie, ursprungsübergreifende URLs vorab abzurufen:

<script type="speculationrules">
  {
    "prerender": [{
      "where": { "href_matches": "/*" },
      "eagerness": "moderate"
    }],
    "prefetch": [{
      "where": { "not": { "href_matches": "/*" } },
      "eagerness": "moderate"
    }]
  }
</script>

Die Einschränkung, die standardmäßig Cross-Origin-Spekulationen für Cross-Origin-Links verhindert, ist aus Sicherheitsgründen erforderlich. Es ist eine Verbesserung gegenüber <link rel="prefetch"> für ursprungsübergreifende Ziele, bei denen ebenfalls keine Cookies gesendet werden, aber dennoch versucht wird, den Prefetch durchzuführen. Dies führt entweder zu einem verschwendeten Prefetch, der noch einmal gesendet werden muss, oder, was noch schlimmer ist, zum Laden der falschen Seite.

Unterstützung der Speculation Rules API erkennen

Sie können die Unterstützung der Speculation Rules API mit Standard-HTML-Prüfungen erkennen:

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

Spekulationsregeln dynamisch über JavaScript hinzufügen

Hier ein Beispiel für das Hinzufügen einer prerender-Spekulationsregel mit JavaScript:

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {
  const specScript = document.createElement('script');
  specScript.type = 'speculationrules';
  specRules = {
    prerender: [
      {
        urls: ['/next.html'],
      },
    ],
  };
  specScript.textContent = JSON.stringify(specRules);
  console.log('added speculation rules to: next.html');
  document.body.append(specScript);
}

Auf dieser Prerender-Demoseite finden Sie eine Demo des Prerenderings der Speculation Rules API mit JavaScript-Einfügung.

Wenn Sie ein <script type = "speculationrules">-Element mit innerHTML direkt in das DOM einfügen, werden die Spekulationsregeln aus Sicherheitsgründen nicht registriert. Sie müssen wie oben beschrieben hinzugefügt werden. Inhalte, die dynamisch mit innerHTML eingefügt werden und neue Links enthalten, werden jedoch von vorhandenen Regeln auf der Seite erfasst.

Wenn Sie das Elements-Steuerfeld in den Chrome-Entwicklertools direkt bearbeiten, um das <script type = "speculationrules">-Element hinzuzufügen, werden die Spekulationsregeln nicht registriert. Stattdessen muss das Skript, mit dem das Element dynamisch dem DOM hinzugefügt wird, über die Konsole ausgeführt werden, um die Regeln einzufügen.

Spekulationsregeln über einen Tag-Manager hinzufügen

Wenn Sie Spekulationsregeln mit einem Tag-Manager wie Google Tag Manager (GTM) hinzufügen möchten, müssen diese über JavaScript eingefügt werden. Das <script type = "speculationrules">-Element kann aus den oben genannten Gründen nicht direkt über GTM hinzugefügt werden:

Konfiguration des benutzerdefinierten HTML-Tags in Google Tag Manager
Spekulationsregeln über Google Tag Manager hinzufügen

In diesem Beispiel wird var verwendet, da GTM const nicht unterstützt.

Spekulationsregeln abbrechen

Wenn Sie Spekulationsregeln entfernen, wird das Pre-Rendering abgebrochen. Bis dahin wurden jedoch wahrscheinlich bereits Ressourcen für das Initiieren des Prerenderings aufgewendet. Daher wird empfohlen, kein Prerendering durchzuführen, wenn die Wahrscheinlichkeit besteht, dass es abgebrochen werden muss. Im Cache gespeicherte Ressourcen können jedoch weiterhin wiederverwendet werden. Abbrüche sind also möglicherweise nicht völlig vergebens und können für zukünftige Spekulationen und Navigationen von Vorteil sein.

Browser Support

  • Chrome: 138.
  • Edge: 138.
  • Firefox: not supported.
  • Safari: not supported.

Source

Spekulationen können auch mit dem HTTP-Header Clear-Site-Data und den Anweisungen prefetchCache und prerenderCache abgebrochen werden.

Das kann nützlich sein, wenn der Status auf dem Server geändert wird. Beispiel: beim Aufrufen einer API für „In den Warenkorb legen“ oder einer API für die Anmeldung oder Abmeldung.

Idealerweise werden diese Statusaktualisierungen mithilfe von APIs wie der Broadcast Channel API an vorgerenderte Seiten weitergegeben. Wenn dies nicht möglich ist oder bis eine solche Logik implementiert ist, kann es einfacher sein, die Spekulation abzubrechen.

Spekulationsregeln und Content Security Policy

Da Spekulationsregeln ein <script>-Element verwenden, obwohl sie nur JSON enthalten, müssen sie in die script-src Content-Security-Policy aufgenommen werden, wenn die Website diese verwendet – entweder mit einem Hash oder einer Nonce.

script-src kann ein neues inline-speculation-rules hinzugefügt werden, damit <script type="speculationrules">-Elemente unterstützt werden, die aus Hash- oder Nonce-Skripts eingefügt werden. Regeln, die im ursprünglichen HTML-Code enthalten sind, werden nicht unterstützt. Daher müssen Regeln für Websites, die eine strikte CSP verwenden, per JavaScript eingefügt werden.

Prerendering erkennen und deaktivieren

Prerendering ist für Nutzer in der Regel eine positive Erfahrung, da Seiten schnell und oft sofort gerendert werden. Davon profitieren sowohl die Nutzer als auch die Websiteinhaber, da vorgerenderte Seiten eine bessere Nutzererfahrung ermöglichen, die sonst nur schwer zu erreichen wäre.

Es kann jedoch vorkommen, dass Sie kein Prerendering von Seiten wünschen, z. B. wenn sich der Status von Seiten ändert – entweder aufgrund der ursprünglichen Anfrage oder aufgrund von JavaScript, das auf der Seite ausgeführt wird.

Prerendering in Chrome aktivieren und deaktivieren

Prerender ist nur für Chrome-Nutzer aktiviert, die in chrome://settings/performance/ die Einstellung „Seiten vorab laden“ aktiviert haben. Außerdem ist das Prerendering auf Geräten mit wenig Arbeitsspeicher oder im Datenspar- oder Energiesparmodus des Betriebssystems deaktiviert. Weitere Informationen finden Sie im Abschnitt Chrome-Limits.

Prerendering serverseitig erkennen und deaktivieren

Vorab gerenderte Seiten werden mit dem HTTP-Header Sec-Purpose gesendet:

Sec-Purpose: prefetch;prerender

Bei Seiten, die mit der Speculation Rules API vorab abgerufen werden, wird dieser Header auf prefetch gesetzt:

Sec-Purpose: prefetch

Server können auf Grundlage dieses Headers reagieren, um Spekulationsanfragen zu protokollieren, andere Inhalte zurückzugeben oder ein Prerendering zu verhindern. Wenn ein nicht erfolgreicher endgültiger Antwortcode zurückgegeben wird, d. h. nach Weiterleitungen nicht im Bereich 200–299, wird die Seite nicht vorab gerendert und alle Prefetch-Seiten werden verworfen. Beachten Sie auch, dass 204- und 205-Antworten zusätzlich nicht für das Prerendering gültig sind, aber für das Prefetching.

Wenn Sie nicht möchten, dass eine bestimmte Seite vorab gerendert wird, geben Sie am besten einen Antwortcode zurück, der nicht 2XX ist (z. B. 503). Für eine optimale Nutzerfreundlichkeit wird jedoch empfohlen, das Prerendering zuzulassen und stattdessen alle Aktionen, die nur dann ausgeführt werden sollen, wenn die Seite tatsächlich aufgerufen wird, mithilfe von JavaScript zu verzögern.

Prerendering in JavaScript erkennen

Die document.prerendering API gibt true zurück, während die Seite vorgerendert wird. Damit können Seiten bestimmte Aktivitäten während des Vorab-Renderings verhindern oder verzögern, bis die Seite tatsächlich aktiviert wird.

Sobald ein vorab gerendertes Dokument aktiviert wird, wird auch die activationStart von PerformanceNavigationTiming auf einen Wert ungleich null gesetzt. Dieser Wert entspricht der Zeit zwischen dem Start des Vorab-Renderings und der tatsächlichen Aktivierung des Dokuments.

Sie können eine Funktion erstellen, die nach Prerendering und vorab gerenderten Seiten sucht, z. B.:

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

Am einfachsten lässt sich feststellen, ob eine Seite vollständig oder teilweise vorgerendert wurde, indem Sie die Entwicklertools nach der Aktivierung der Seite öffnen und performance.getEntriesByType('navigation')[0].activationStart in die Konsole eingeben. Wenn ein Wert ungleich null zurückgegeben wird, wurde die Seite vorab gerendert:

Konsole in den Chrome-Entwicklertools mit einem positiven activationStart-Wert, der angibt, dass die Seite vorab gerendert wurde
Prerendering in der Console testen

Wenn die Seite vom Nutzer aufgerufen wird, wird das Ereignis prerenderingchange für document ausgelöst. Damit können Sie Aktivitäten aktivieren, die zuvor standardmäßig beim Seitenaufbau gestartet wurden, die Sie aber erst dann starten möchten, wenn die Seite tatsächlich vom Nutzer aufgerufen wird.

Mit diesen APIs kann Frontend-JavaScript vorab gerenderte Seiten erkennen und entsprechend darauf reagieren.

Auswirkungen auf Analysen

Analysen werden verwendet, um die Websitenutzung zu messen, z. B. mit Google Analytics, um Seitenaufrufe und Ereignisse zu messen. Oder durch Messen der Leistungsmesswerte von Seiten mithilfe von Real User Monitoring (RUM).

Seiten sollten nur dann vorab gerendert werden, wenn die Wahrscheinlichkeit hoch ist, dass die Seite vom Nutzer geladen wird. Deshalb werden die Optionen für das Pre-Rendering in der Chrome-Adressleiste nur dann verwendet, wenn die Wahrscheinlichkeit so hoch ist (mehr als 80 %).

Vorgerenderte Seiten können sich jedoch auf die Analysen auswirken, insbesondere wenn die Speculation Rules API verwendet wird. Websiteinhaber müssen dann möglicherweise zusätzlichen Code hinzufügen, damit Analysen für vorgerenderte Seiten nur bei der Aktivierung aktiviert werden, da dies nicht alle Analyseanbieter standardmäßig tun.

Dies kann mit einem Promise erreicht werden, der auf das prerenderingchange-Ereignis wartet, wenn ein Dokument vorgerendert wird, oder sofort aufgelöst wird, wenn es jetzt so ist:

// Set up a promise for when the page is activated,
// which is needed for prerendered pages.
const whenActivated = new Promise((resolve) => {
  if (document.prerendering) {
    document.addEventListener('prerenderingchange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenActivated;
  // Initialise your analytics
}

initAnalytics();

Alternativ können Sie Analyseaktivitäten verzögern, bis die Seite zum ersten Mal sichtbar ist. Das würde sowohl das Prerendering als auch das Öffnen von Tabs im Hintergrund abdecken (z. B. per Rechtsklick und „In neuem Tab öffnen“):

// Set up a promise for when the page is first made visible
const whenFirstVisible = new Promise((resolve) => {
  if (document.hidden) {
    document.addEventListener('visibilitychange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenFirstVisible;
  // Initialise your analytics
}

initAnalytics();

Das kann für Analysen und ähnliche Anwendungsfälle sinnvoll sein. In anderen Fällen möchtest du aber vielleicht, dass mehr Inhalte geladen werden. Dann kannst du document.prerendering und prerenderingchange verwenden, um gezielt Seiten vorab zu rendern.

Andere Inhalte während des Prerenderings zurückhalten

Dieselben APIs, die zuvor erläutert wurden, können verwendet werden, um andere Inhalte während der Prerendering-Phase zurückzuhalten. Das können bestimmte Teile von JavaScript oder ganze Skriptelemente sein, die während der Vorrendering-Phase nicht ausgeführt werden sollen.

Beispiel für ein Skript:

<script src="https://example.com/app/script.js" async></script>

Sie können dies in ein dynamisch eingefügtes Skriptelement ändern, das nur basierend auf der vorherigen whenActivated-Funktion eingefügt wird:

async function addScript(scriptUrl) {
  await whenActivated;
  const script = document.createElement('script');
  script.src = 'scriptUrl';
  document.body.appendChild(script);
}

addScript('https://example.com/app/script.js');

Das kann nützlich sein, um bestimmte Skripts zurückzuhalten, die Analysen enthalten oder Inhalte basierend auf dem Status oder anderen Variablen rendern, die sich während eines Besuchs ändern können. Beispielsweise können Empfehlungen, der Anmeldestatus oder Einkaufswagensymbole zurückgehalten werden, um sicherzustellen, dass die Informationen auf dem neuesten Stand angezeigt werden.

Dies ist zwar bei der Verwendung von Prerendering wahrscheinlich häufiger der Fall, aber diese Bedingungen gelten auch für Seiten, die in Hintergrund-Tabs geladen werden (daher könnte die Funktion whenFirstVisible anstelle von whenActivated verwendet werden).

In vielen Fällen sollte der Status idealerweise auch bei allgemeinen visibilitychange-Änderungen geprüft werden. Wenn Sie beispielsweise zu einer Seite zurückkehren, die im Hintergrund war, sollten alle Einkaufswagenzähler mit der aktuellen Anzahl der Artikel im Einkaufswagen aktualisiert werden. Es handelt sich also nicht um ein Prerender-spezifisches Problem, sondern Prerender macht ein bestehendes Problem nur deutlicher.

Chrome reduziert die Notwendigkeit, Skripts oder Funktionen manuell zu umschließen, indem bestimmte APIs wie bereits erwähnt zurückgehalten werden. Außerdem werden iFrames von Drittanbietern nicht gerendert, sodass nur Inhalte darüber manuell zurückgehalten werden müssen.

Leistung messen

Bei der Messung von Leistungsmesswerten sollten Sie überlegen, ob es besser ist, diese anhand der Aktivierungszeit und nicht anhand der Seitenladezeit zu messen, die von Browser-APIs gemeldet wird.

Die Core Web Vitals, die von Chrome über den Chrome User Experience Report gemessen werden, sollen die Nutzerfreundlichkeit messen. Diese werden also anhand der Aktivierungszeit gemessen. Dies führt oft zu einem LCP von 0 Sekunden, was zeigt, dass dies eine hervorragende Möglichkeit ist, Ihre Core Web Vitals zu verbessern.

Ab Version 3.1.0 wurde die web-vitals-Bibliothek aktualisiert, um vorgerenderte Navigationen auf dieselbe Weise zu verarbeiten, wie Chrome die Core Web Vitals misst. In dieser Version werden auch vorab gerenderte Navigationen für diese Messwerte im Attribut Metric.navigationType gekennzeichnet, wenn die Seite vollständig oder teilweise vorab gerendert wurde.

Prerendering messen

Ob eine Seite vorab gerendert wird, lässt sich an einem activationStart-Eintrag von PerformanceNavigationTiming erkennen, der ungleich null ist. Dies kann dann mithilfe einer benutzerdefinierten Dimension oder ähnlichem beim Protokollieren der Seitenaufrufe protokolliert werden, z. B. mit der zuvor beschriebenen pagePrerendered-Funktion:

// Set Custom Dimension for Prerender status
gtag('set', { 'dimension1': pagePrerendered() });
// Initialise GA - including sending page view by default
gtag('config', 'G-12345678-1');

So können Sie in Ihren Analysen sehen, wie viele Navigationen im Vergleich zu anderen Navigationstypen vorgerendert werden. Außerdem können Sie Leistungsmesswerte oder Geschäftsmesswerte mit diesen verschiedenen Navigationstypen korrelieren. Schnellere Seiten bedeuten zufriedenere Nutzer, was sich oft auf die Geschäftsergebnisse auswirkt, wie unsere Fallstudien zeigen.

Wenn Sie die geschäftlichen Auswirkungen des Prerenderings von Seiten für die sofortige Navigation messen, können Sie entscheiden, ob es sich lohnt, mehr Aufwand in die Verwendung dieser Technologie zu investieren, um mehr Navigationsvorgänge vorab zu rendern, oder zu untersuchen, warum Seiten nicht vorab gerendert werden.

Trefferquoten messen

Neben der Messung der Auswirkungen von Seiten, die nach einem Prerendering besucht werden, ist es auch wichtig, Seiten zu messen, die vorab gerendert und nicht anschließend besucht werden. Das könnte darauf hindeuten, dass Sie zu viel vorab rendern und wertvolle Ressourcen des Nutzers für wenig Nutzen verbrauchen.

Das lässt sich messen, indem ein Analytics-Ereignis ausgelöst wird, wenn Spekulationsregeln eingefügt werden. Dazu muss zuerst geprüft werden, ob der Browser Prerendering mit HTMLScriptElement.supports('speculationrules') unterstützt, um anzugeben, dass Prerendering angefordert wurde. (Hinweis: Nur weil ein Pre-Rendering angefordert wurde, bedeutet das nicht, dass es auch gestartet oder abgeschlossen wurde. Wie bereits erwähnt, ist ein Pre-Rendering ein Hinweis für den Browser. Er kann sich aufgrund von Nutzereinstellungen, der aktuellen Arbeitsspeichernutzung oder anderer Heuristiken gegen das Pre-Rendering von Seiten entscheiden.)

Anschließend können Sie die Anzahl dieser Ereignisse mit den tatsächlichen Seitenaufrufen mit Prerendering vergleichen. Alternativ können Sie bei der Aktivierung ein anderes Ereignis auslösen, wenn das den Vergleich erleichtert.

Die „erfolgreiche Trefferquote“ kann dann anhand der Differenz zwischen diesen beiden Zahlen geschätzt werden. Bei Seiten, auf denen Sie die Speculation Rules API zum Prerendering verwenden, können Sie die Regeln entsprechend anpassen, um eine hohe Trefferquote zu erzielen. So können Sie die Ressourcen der Nutzer optimal nutzen, ohne sie unnötig zu belasten.

Beachten Sie, dass ein Teil des Prerenderings möglicherweise auf das Prerendering der Adressleiste und nicht nur auf Ihre Spekulationsregeln zurückzuführen ist. Wenn Sie diese unterscheiden möchten, können Sie document.referrer prüfen. Bei der Navigation über die Adressleiste, einschließlich vorgerenderter Navigation über die Adressleiste, ist dieser Wert leer.

Sehen Sie sich auch Seiten an, die nicht vorab gerendert wurden. Das könnte darauf hindeuten, dass diese Seiten nicht für das Vorab-Rendering geeignet sind, auch nicht über die Adressleiste. Das bedeutet, dass Sie möglicherweise nicht von dieser Leistungssteigerung profitieren. Das Chrome-Team möchte zusätzliche Tools zum Testen der Prerender-Eignung hinzufügen, möglicherweise ähnlich dem bfcache-Testtool, und eventuell eine API hinzufügen, um zu zeigen, warum ein Prerender fehlgeschlagen ist.

Auswirkungen auf Erweiterungen

Weitere Informationen zu zusätzlichen Überlegungen, die Autoren von Erweiterungen für vorab gerenderte Seiten anstellen sollten, finden Sie im Beitrag Chrome-Erweiterungen: API zur Unterstützung der sofortigen Navigation erweitern.

Feedback

Das Prerendering wird vom Chrome-Team aktiv weiterentwickelt und es gibt viele Pläne, den Umfang der in Chrome 108 verfügbaren Funktionen zu erweitern. Wir freuen uns über Feedback im GitHub-Repository oder über unseren Issue Tracker. Außerdem sind wir gespannt auf Fallstudien zu dieser neuen API.

Danksagungen

Miniaturansicht von Marc-Olivier Jodoin auf Unsplash