Für eine sofortige Seitennavigation in Chrome vorab rendern

Das Chrome-Team hat das vollständige Vorab-Rendering zukünftiger Seiten wieder eingeführt, zu denen ein Nutzer wahrscheinlich weitersurft.

Eine kurze Geschichte des Prerenderings

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

Dieses alte Prerendering mit dem Link-Hinweis rel=prerender wurde zugunsten von NoState Prefetch eingestellt. Dabei werden die für die zukünftige Seite benötigten Ressourcen abgerufen, die Seite wird jedoch nicht vollständig vorab gerendert und JavaScript wird nicht ausgeführt. NoState Prefetch trägt dazu bei, die Seitenleistung durch eine verbesserte Ressourcenauslieferung zu verbessern. Es führt jedoch nicht zu einem sofortigen Seitenaufbau wie ein vollständiges Pre-Rendering.

Das Chrome-Team hat das vollständige Prerendering jetzt wieder in Chrome eingeführt. Um Komplikationen bei der bestehenden Nutzung zu vermeiden und eine zukünftige Erweiterung des Prerenderings zu ermöglichen, wird bei diesem neuen Prerendering-Mechanismus nicht die <link rel="prerender"...>-Syntax verwendet. Diese bleibt für den NoState-Prefetch erhalten, der aber irgendwann eingestellt werden soll.

Wie wird eine Seite vorab gerendert?

Eine Seite kann auf vier verschiedene Arten vorab gerendert werden, um die Navigation zu beschleunigen:

1. Wenn Sie eine URL in die Chrome-Adressleiste (auch „Omnibox“ genannt) eingeben, wird die Seite möglicherweise automatisch vorab gerendert, wenn Chrome anhand Ihres bisherigen Browserverlaufs mit hoher Wahrscheinlichkeit davon ausgeht, dass Sie diese Seite aufrufen werden.
2. Wenn Sie die Lesezeichenleiste verwenden, rendert Chrome die Seite automatisch für Sie, wenn Sie den Mauszeiger über eine der Lesezeichenschaltflächen halten.
3. Wenn Sie einen Suchbegriff in die Chrome-Adressleiste eingeben, wird die Suchergebnisseite möglicherweise automatisch von Chrome gerendert, wenn die Suchmaschine dies anfordert.
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 basierend auf Spekulationsregeln auf der Seite vorab zu rendern. Diese können statisch auf den Seiten vorhanden sein oder dynamisch durch JavaScript eingefügt werden, wie es der Seiteninhaber für angebracht hält.

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

Da die vorab gerenderte Seite im ausgeblendeten Zustand geöffnet wird, werden eine Reihe von APIs, die aufdringliches Verhalten verursachen (z. B. Prompts), in diesem Zustand nicht aktiviert. Stattdessen werden sie verzögert, bis die Seite aktiviert wird. In den wenigen Fällen, in denen dies noch nicht möglich ist, wird das Vorab-Rendering abgebrochen. Das Chrome-Team arbeitet daran, die Gründe für das Abbruchverfahren für das Pre-Rendering als API verfügbar zu machen und die Funktionen der Entwicklertools zu verbessern, damit solche Grenzfälle leichter identifiziert werden können.

Auswirkungen des Prerenderings

Durch das Vorab-Rendering wird das Laden der Seite nahezu sofort ermöglicht, wie im folgenden Video zu sehen:

Die Beispielwebsite ist bereits schnell, aber selbst hier können Sie sehen, wie das Pre-Rendering die Nutzererfahrung verbessert. Dies kann sich auch direkt auf die Core Web Vitals einer Website auswirken, mit einem LCP von nahezu null, einem reduzierten CLS (da alle CLS-Ladevorgänge vor der ersten Ansicht erfolgen) und einer verbesserten INP (da der Ladevorgang abgeschlossen sein sollte, bevor der Nutzer interagiert).

Selbst wenn eine Seite aktiviert wird, bevor sie vollständig geladen ist, sollte das Laden schneller erfolgen, da der Ladevorgang schon früher gestartet wird. Wenn ein Link aktiviert wird, während das Pre-Rendering noch läuft, wird die Pre-Rendering-Seite in den Hauptframe verschoben und weiter geladen.

Beim Pre-Rendering werden jedoch zusätzlicher Arbeitsspeicher und Netzwerkbandbreite benötigt. Achten Sie darauf, nicht zu viel zu pre-rendern, da dies zu einem erhöhten Ressourcenverbrauch der Nutzer führt. Die Seiten werden nur dann vorab gerendert, wenn die Wahrscheinlichkeit hoch ist, dass die Seite aufgerufen wird.

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

Vervollständigungen in der Chrome-Adressleiste ansehen

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

Grüne Linien geben an, dass die Wahrscheinlichkeit hoch genug ist, um das Vorab-Rendering auszulösen. In diesem Beispiel ist die Wahrscheinlichkeit, dass Sie „s“ eingeben, relativ hoch (orange). Wenn Sie jedoch „sh“ eingeben, ist Chrome ziemlich sicher, dass Sie fast immer zu https://sheets.google.com wechseln.

Dieser Screenshot wurde in einer relativ neuen Chrome-Installation aufgenommen und Vorhersagen mit Null-Konfidenz wurden herausgefiltert. Wenn Sie sich Ihre eigenen Vorhersagen ansehen, sehen Sie wahrscheinlich deutlich mehr Einträge und möglicherweise mehr Zeichen, die erforderlich sind, um ein ausreichend hohes Konfidenzniveau zu erreichen.

Anhand dieser Vorhersagen werden auch die Vorschläge in der Adressleiste erstellt, die Ihnen vielleicht schon aufgefallen sind:

Chrome aktualisiert die Prädiktoren laufend auf der Grundlage Ihrer Eingabe und Auswahl.

• Bei einer Wahrscheinlichkeit von über 50 % (gelb dargestellt) stellt Chrome proaktiv eine Vorabverbindung zur Domain her, aber die Seite wird nicht vorab gerendert.
• Bei einem Konfidenzniveau von mehr als 80 % (grün dargestellt) rendert Chrome die URL vorab.

Die Speculation Rules API

Für die Pre-Render-Option der Speculation Rules API können Webentwickler JSON-Anweisungen auf ihren Seiten einfügen, um den Browser darüber zu informieren, welche URLs vorzeitig gerendert werden sollen:

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

Oder mit Dokumentregeln (verfügbar ab Chrome 121), mit denen Links im Dokument basierend auf href-Selektoren (basierend auf der URL Pattern API) oder CSS-Selektoren vorab gerendert werden:

<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>

Das Chrome-Team hat ein Codelab zu Spekulationsregeln erstellt, in dem Sie Schritt für Schritt durch die Vorgehensweise zum Hinzufügen von Spekulationsregeln zu einer Website geführt werden.

Begeisterung

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

• immediate: Damit wird so schnell wie möglich spekuliert, d. h. sobald die Spekulationsregeln eingehalten werden.
• eager: Diese Einstellung verhält sich identisch wie die Einstellung immediate. Künftig soll sie jedoch zwischen immediate und moderate liegen.
• moderate: Es werden Spekulationen durchgeführt, wenn Sie den Mauszeiger 200 Millisekunden lang auf einen Link halten (oder auf das Ereignis pointerdown, falls dies früher eintritt, und auf Mobilgeräten, wo es kein hover-Ereignis gibt).
• conservative: Hier wird auf den Zeiger oder das Tippen spekuliert.

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

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

Welche eagerness-Einstellung Sie verwenden, hängt von Ihrer Website ab. Bei einer einfachen, statischen Website kann eine größere Spekulation mit wenig Aufwand verbunden sein und für Nutzer von Vorteil sein. Bei Websites mit komplexeren Architekturen und größeren Seitennutzlasten sollten Sie die Auslieferung von Anzeigen mit weniger Spekulationen reduzieren, bis Sie mehr positive Signale von Nutzern erhalten, um die Auslieferung von Anzeigen zu begrenzen.

Die Option moderate stellt einen Mittelweg dar und viele Websites könnten von der folgenden Spekulationsregel profitieren, die einen Link vorab rendern würde, wenn der Mauszeiger 200 Millisekunden über den Link gehalten wird, oder das Zeigerdown-Ereignis als einfache, aber dennoch effektive – Implementierung von Spekulationsregeln verwenden:

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

Prefetch

Mit Spekulationsregeln können auch Seiten ohne vollständiges Vorab-Rendering vorab abgerufen werden. Dies kann oft ein guter erster Schritt zum Pre-Rendering sein:

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

Chrome-Einschränkungen

Für Chrome gelten Beschränkungen, um eine übermäßige Verwendung der Speculation Rules API zu verhindern:

Eifer	Prefetch	Prerender
immediate/eager	50	10
moderate/conservative	2 (FIFO)	2 (FIFO)

Die Einstellungen moderate und conservative, die von der Nutzerinteraktion abhängen, funktionieren nach First In, First Out (FIFO): Nach Erreichen des Limits wird eine neue Spekulation dazu führen, dass die älteste Spekulation abgebrochen und durch die neue ersetzt wird, um Arbeitsspeicher zu sparen. Eine abgebrochene Spekulation kann noch einmal ausgelöst werden, indem Sie beispielsweise den Mauszeiger wieder auf den Link bewegen. Dadurch wird die URL noch einmal geschätzt und die älteste Spekulation wird verdrängt. In diesem Fall wurden bei der vorherigen Spekulation alle cachebaren Ressourcen für diese URL im HTTP-Cache gespeichert. Eine weitere Spekulation sollte daher mit geringeren Kosten verbunden sein. Deshalb ist das Limit auf den bescheidenen Grenzwert 2 festgelegt. Regeln für statische Listen werden nicht durch eine Nutzeraktion ausgelöst und haben daher ein höheres Limit, da der Browser nicht weiß, welche Regeln wann benötigt werden.

Die Limits für immediate und eager sind ebenfalls dynamisch. Wenn Sie also ein list-URL-Skriptelement entfernen, schaffen Sie Kapazität, indem diese entfernten Spekulationen aufgehoben werden.

Außerdem verhindert Chrome, dass in bestimmten Fällen Spekulationen verwendet werden, z. B.:

• Save-Data
• Energiesparmodus, wenn er aktiviert ist und der Akkustand niedrig ist.
• Arbeitsspeichereinschränkungen
• Wenn die Einstellung „Seiten vorab laden“ deaktiviert ist (was auch von Chrome-Erweiterungen wie uBlock Origin ausdrücklich deaktiviert wird).
• In Tabs im Hintergrund geöffnete Seiten.

Chrome rendert auch keine ursprungsübergreifenden iframes auf vorab gerenderten Seiten, bis sie aktiviert wurden.

All diese Bedingungen zielen darauf ab, die Auswirkungen übermäßiger Spekulationen zu reduzieren, wenn diese für Nutzer schädlich sein könnten.

Spekulationsregeln auf einer Seite einfügen

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

• Statisch eingefügte Spekulationsregeln: Beispielsweise kann eine Nachrichtenwebsite oder ein Blog den neuesten Artikel vorab rendern, wenn dies für einen großen Teil der Nutzer häufig die nächste Navigationsaktion ist. Alternativ können Dokumentregeln mit moderate oder conservative verwendet werden, um zu spekulieren, wenn Nutzer mit Links interagieren.
• Dynamische Spekulationsregeln: Diese können auf Anwendungslogik, auf personalisierten Nutzerdaten oder auf anderen Heuristiken basieren.

Wenn Sie dynamisches Einfügen basierend auf Aktionen wie dem Bewegen des Mauszeigers auf einen Link oder dem Klicken auf einen Link bevorzugen, wie es viele Bibliotheken in der Vergangenheit mit <link rel=prefetch> getan haben, sollten Sie sich Dokumentregeln ansehen. Mit diesen kann der Browser viele Ihrer Anwendungsfälle verarbeiten.

Spekulationsregeln können entweder im <head> oder im <body> im Hauptframe hinzugefügt werden. Spekulationsregeln in Subframes werden nicht angewendet und Spekulationsregeln in vorab gerenderten Seiten werden erst angewendet, wenn die Seite aktiviert ist.

Der Speculation-Rules-HTTP-Header

Spekulationsregeln können auch über einen Speculation-Rules-HTTP-Header übermittelt 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 Speculation-Rules-HTTP-Header wird mit dem Dokument zurückgegeben und verweist auf den Speicherort einer JSON-Datei mit den Spekulationsregeln:

Speculation-Rules: "/speculationrules.json"

Diese Ressource muss den richtigen MIME-Typ verwenden und, falls es sich um eine plattformü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 sind relative URLs relativ zur URL der JSON-Datei mit den Spekulationsregeln. Das ist besonders nützlich, wenn Sie einige oder alle Links mit demselben Ursprung auswählen möchten.

Spekulationsregeln und SPAs

Spekulationsregeln werden nur für vom Browser verwaltete Navigationen auf der gesamten Seite unterstützt, nicht für Single-Page-Anwendungen (SPAs) oder App-Shells. Bei dieser Architektur werden keine Dokumente abgerufen, sondern Daten oder Seiten per API oder teilweise abgerufen. Diese werden dann verarbeitet und auf der aktuellen Seite dargestellt. Die für diese sogenannten „weichen Navigationen“ erforderlichen Daten können von der App außerhalb der Spekulationsregeln vorab abgerufen, aber nicht vorab gerendert werden.

Spekulationsregeln können verwendet werden, um die Anwendung selbst von einer vorherigen Seite vorab zu rendern. So lassen sich einige der zusätzlichen Kosten für die Erstauslieferung von SPAs kompensieren. Routenänderungen innerhalb der App können jedoch nicht vorab gerendert werden.

Spekulationsregeln debuggen

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

Mehrere Spekulationsregeln

Es können auch mehrere Spekulationsregeln auf dieselbe Seite angewendet werden. Sie werden an die vorhandenen Regeln angehängt. Daher führen die folgenden verschiedenen Möglichkeiten sowohl zu einem one.html- als auch zu einem two.html-Prerendering:

Liste der URLs:

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

Mehrere speculationrules-Scripts:

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

Mehrere Listen innerhalb eines Satzes von speculationrules

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

No-Vary-Search-Support

Beim Vorabladen oder Vorabrendering einer Seite sind bestimmte URL-Parameter (technisch Suchparameter genannt) möglicherweise für die vom Server tatsächlich bereitgestellte Seite nicht wichtig und werden nur von clientseitigem JavaScript verwendet.

UTM-Parameter werden beispielsweise in Google Analytics für die Kampagnenmessung verwendet, führen aber in der Regel nicht dazu, dass vom Server unterschiedliche Seiten ausgeliefert werden. Das bedeutet, dass page1.html?utm_content=123 und page1.html?utm_content=456 dieselbe Seite vom Server ausliefern, 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 können Server Parameter angeben, die keine Auswirkungen auf die bereitgestellte Ressource haben. So kann ein Browser zuvor im Cache gespeicherte Versionen eines Dokuments wiederverwenden, die sich nur durch diese Parameter unterscheiden. Dies wird in Chrome und in Chromium-basierten Browsern für Spekulationen zur Prefetch-Navigation unterstützt. Wir arbeiten jedoch daran, dies auch für Pre-Rendering zu unterstützen.

Spekulationsregeln unterstützen die Verwendung von expects_no_vary_search, um anzugeben, wo ein No-Vary-Search-HTTP-Header voraussichtlich zurückgegeben wird. Dadurch lassen sich unnötige Downloads vermeiden.

<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 HTML-Code der Startseite /products für die beiden Produkt-IDs 123 und 124 identisch. Der Seiteninhalt unterscheidet sich jedoch je nach clientseitigem Rendering mit JavaScript, um Produktdaten mit dem Suchparameter id abzurufen. Daher wird diese URL vorab abgerufen und es sollte ein No-Vary-Search-HTTP-Header zurückgegeben werden, der angibt, dass die Seite für jeden id-Suchparameter verwendet werden kann.

Klickt der Nutzer jedoch auf einen der Links, bevor der Prefetch abgeschlossen ist, hat der Browser möglicherweise die Seite /products nicht erhalten. In diesem Fall weiß der Browser nicht, ob er den HTTP-Header No-Vary-Search enthält. Der Browser kann dann wählen, ob er den Link noch einmal abrufen oder warten möchte, bis der Prefetch abgeschlossen ist, um zu sehen, ob er einen No-Vary-Search-HTTP-Header enthält. Durch die Einstellung expects_no_vary_search weiß der Browser, ob die Seitenantwort einen No-Vary-Search-HTTP-Header enthalten muss, und wartet, bis dieser Prefetch abgeschlossen ist.

Einschränkungen der Spekulationsregeln und zukünftige Verbesserungen

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

Standardmäßig sind Spekulationen auf Seiten desselben Ursprungs beschränkt. Spekulationen für Seiten mit demselben Ursprung, die aber unterschiedliche Ursprünge haben (z. B. könnte https://a.example.com eine Seite auf https://b.example.com vorrendern). Dazu muss die Seite, für die die Spekulation verwendet werden soll (in diesem Beispiel https://b.example.com), die Funktion aktivieren, indem sie einen Supports-Loading-Mode: credentialed-prerender-HTTP-Header enthält. Andernfalls wird die Spekulation von Chrome abgebrochen.

In zukünftigen Versionen wird möglicherweise auch das Pre-Rendering für nicht auf derselben Website befindliche, plattformübergreifende Seiten zugelassen, sofern für die vorab gerenderte Seite keine Cookies vorhanden sind und die vorab gerenderte Seite mit einem ähnlichen Supports-Loading-Mode: uncredentialed-prerender-HTTP-Header aktiviert wird.

Spekulationsregeln unterstützen bereits vorab geladene Inhalte, die von mehreren Websites stammen, aber auch nur dann, wenn keine Cookies für die domainübergreifende Domain vorhanden sind. Wenn Cookies vorhanden sind, die der Nutzer bei einem früheren Besuch der Website hinterlassen hat, wird die Spekulation nicht ausgelöst und in den DevTools wird ein Fehler angezeigt.

Angesichts dieser aktuellen Einschränkungen können Sie die Nutzerfreundlichkeit sowohl für interne als auch für externe Links verbessern, wenn Sie URLs mit demselben Ursprung vorab rendern und ursprungsübergreifende URLs vorab abrufen:

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

Die Standardeinschränkung, die ursprungsübergreifende Spekulationen für ursprungsübergreifende Links verhindert, ist aus Sicherheitsgründen erforderlich. Es ist eine Verbesserung gegenüber <link rel="prefetch"> für plattformübergreifende Ziele, bei denen auch keine Cookies gesendet werden, aber trotzdem der Prefetch versucht wird. Dies führt entweder zu einem verschwendeten Prefetch, der noch einmal gesendet werden muss, oder, schlimmer noch, zu einer falschen Seitenladezeit.

Vorauswahlregeln werden für das Vorabladen von Seiten, die von Service Workers gesteuert werden, nicht unterstützt. Wir arbeiten daran, diese Unterstützung hinzuzufügen. Aktuelle Informationen zu diesem Problem finden Sie unter Support-Service Worker-Problem. Pre-Rendering wird für Seiten unterstützt, die von Service Workern verwaltet werden.

Unterstützung der Speculation Rules API erkennen

Sie können die Unterstützung der Speculation Rules API mit standardmäßigen HTML-Prüfungen ermitteln:

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-Regel für Spekulationen 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 Demoseite für das Pre-Rendering können Sie sich eine Demo des Pre-Renderings mit der Speculation Rules API ansehen, bei der JavaScript-Code eingefügt wird.

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

Wenn Sie das <script type = "speculationrules">-Element auch direkt im Bereich Elemente in den Chrome-Entwicklertools hinzufügen, werden die Spekulationsregeln nicht registriert. Stattdessen muss das Script, das das Element dynamisch dem DOM hinzufügt, über die Console ausgeführt werden, um die Regeln einzufügen.

Spekulationsregeln über ein Tag Manager-Konto hinzufügen

Wenn Sie Spekulationsregeln mit einem Tag-Manager wie Google Tag Manager (GTM) hinzufügen möchten, müssen diese aus denselben Gründen wie oben erwähnt über JavaScript eingefügt werden, anstatt das <script type = "speculationrules">-Element direkt über GTM hinzuzufügen:

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

Spekulationsregeln abbrechen

Wenn Sie Spekulationsregeln entfernen, wird das Pre-Rendering abgebrochen. Zu diesem Zeitpunkt wurden jedoch wahrscheinlich bereits Ressourcen für die Initiierung des Pre-Renderings verbraucht. Daher wird empfohlen, kein Pre-Rendering durchzuführen, wenn das Pre-Rendering wahrscheinlich abgebrochen werden muss.

Regeln zu Spekulationen und Content Security Policy

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

script-src kann eine neue inline-speculation-rules hinzugefügt werden, damit <script type="speculationrules">-Elemente unterstützt werden, die über Hash- oder Nonce-Scripts eingefügt werden. Regeln, die in der ursprünglichen HTML-Datei enthalten sind, werden nicht unterstützt. Daher müssen Regeln für Websites mit einer strengen CSP durch JavaScript eingefügt werden.

Prerendering erkennen und deaktivieren

Das Vorab-Rendering ist in der Regel für Nutzer positiv, da es ein schnelles Seiten-Rendering ermöglicht – oft sogar sofort. Davon profitieren sowohl der Nutzer als auch der Websiteinhaber, da vorab gerenderte Seiten eine bessere Nutzererfahrung ermöglichen, die ansonsten schwer zu erreichen wäre.

Es kann jedoch Fälle geben, in denen Sie das Vorab-Rendering von Seiten nicht möchten, z. B. wenn Seiten ihren Status ändern – entweder aufgrund der ursprünglichen Anfrage oder aufgrund von JavaScript, das auf der Seite ausgeführt wird.

Vorab-Rendering in Chrome aktivieren und deaktivieren

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

Serverseitiges Vorab-Rendering erkennen und deaktivieren

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

Sec-Purpose: prefetch;prerender

Bei Seiten, die mit der Speculation Rules API vorab abgerufen wurden, ist dieser Header nur auf prefetch festgelegt:

Sec-Purpose: prefetch

Server können anhand dieses Headers reagieren, um Spekulationsanfragen zu protokollieren, andere Inhalte zurückzugeben oder ein Pre-Rendering zu verhindern. Wenn ein abschließender Antwortcode zurückgegeben wird, der nicht erfolgreich ist, also nach Weiterleitungen nicht im Bereich von 200 bis 299 liegt, wird die Seite nicht vorab gerendert und alle Prefetch-Seiten verworfen. Außerdem sind Antworten vom Typ 204 und 205 nicht für das Prerendering gültig, aber für das Prefetching.

Wenn Sie nicht möchten, dass eine bestimmte Seite vorab gerendert wird, ist es am besten, einen anderen Antwortcode als 2XX (z. B. 503) zurückzugeben. Für eine optimale Darstellung wird jedoch empfohlen, stattdessen das Pre-Rendering zuzulassen und alle Aktionen mit JavaScript zu verzögern, die erst dann ausgeführt werden sollen, wenn die Seite tatsächlich angezeigt wird.

Pre-Rendering in JavaScript erkennen

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

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

Sie können eine Funktion verwenden, um nach Vorabrendering und vorab gerenderten Seiten zu suchen, 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 vorab gerendert wurde, indem Sie die Entwicklertools öffnen, nachdem die Seite aktiviert wurde, und performance.getEntriesByType('navigation')[0].activationStart in die Console eingeben. Wenn ein Wert ungleich Null zurückgegeben wird, wissen Sie, dass die Seite vorab gerendert wurde:

Wenn die Seite vom Nutzer aktiviert wird, wird das Ereignis prerenderingchange auf dem document gesendet. Damit können Aktivitäten aktiviert werden, die zuvor standardmäßig beim Seitenaufbau gestartet wurden, aber verzögert werden sollen, bis die Seite vom Nutzer tatsächlich aufgerufen wird.

Mithilfe dieser APIs kann frontend-JavaScript vorab gerenderte Seiten erkennen und entsprechend darauf reagieren.

Auswirkungen auf Analysen

Mithilfe von Analysen wird die Websitenutzung gemessen. Beispielsweise können Sie mit Google Analytics Seitenaufrufe und Ereignisse erfassen. Alternativ können Sie mit Real User Monitoring (RUM) die Leistungsmesswerte von Seiten erfassen.

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 Vorab-Rendering in der Chrome-Adressleiste nur dann verwendet, wenn die Wahrscheinlichkeit dafür sehr hoch ist (mehr als 80 % der Zeit).

Insbesondere bei Verwendung der Speculation Rules API können vorgerenderte Seiten jedoch Auswirkungen auf Analysen haben. Websiteinhaber müssen möglicherweise zusätzlichen Code einfügen, um Analysen bei der Aktivierung nur für vorgerenderte Seiten zu aktivieren, da dies nicht bei allen Analyseanbietern standardmäßig der Fall ist.

Das kann mithilfe eines Promise erreicht werden, das auf das Ereignis prerenderingchange wartet, wenn ein Dokument vorrendert wird, oder sofort löst, wenn es fertig 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();

Eine alternative Lösung besteht darin, Analyseaktivitäten so lange zu verzögern, bis die Seite sichtbar wird. Dies gilt sowohl für das Prerendering als auch für den Fall, dass Tabs im Hintergrund geöffnet werden (z. B. durch 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öchten Sie möglicherweise mehr Inhalte laden. Verwenden Sie dann document.prerendering und prerenderingchange, um das Prerendering speziell auf Seiten auszurichten.

Andere Inhalte beim Pre-Rendering zurückhalten

Mit denselben APIs, die bereits erwähnt wurden, können Sie andere Inhalte während der Pre-Render-Phase zurückhalten. Das können bestimmte Teile von JavaScript oder ganze Scriptelemente sein, die nicht in der Pre-Render-Phase ausgeführt werden sollen.

Hier ein Beispiel für dieses Skript:

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

Sie können dies in ein dynamisch eingefügtes Skriptelement ändern, das nur auf Grundlage 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 Scripts mit Analysefunktionen zurückzuhalten oder Inhalte basierend auf dem Status oder anderen Variablen zu rendern, die sich während eines Besuchs ändern können. Beispielsweise können Empfehlungen, Anmeldestatus oder Einkaufswagensymbole zurückgehalten werden, damit die Informationen immer auf dem neuesten Stand sind.

Das kommt beim Pre-Rendering wahrscheinlich häufiger vor. Diese Bedingungen gelten aber auch für Seiten, die auf bereits erwähnten Hintergrundtabs geladen werden. Daher könnte die Funktion whenFirstVisible anstelle von whenActivated verwendet werden.

In vielen Fällen sollte der Status idealerweise auch zu allgemeinen visibilitychange-Änderungen überprüft werden. Wenn beispielsweise eine Seite im Hintergrund aufgerufen wird, sollten die Warenkorbzähler mit der aktuellen Anzahl der Artikel im Einkaufswagen aktualisiert werden. Das ist also kein Pre-Render-spezifisches Problem, sondern Pre-Render macht ein vorhandenes Problem nur deutlicher.

In Chrome wird das manuelle Verpacken von Skripts oder Funktionen beispielsweise dadurch reduziert, dass bestimmte APIs wie bereits erwähnt zurückgehalten werden und auch iFrames von Drittanbietern nicht gerendert werden. Es sind nur noch zusätzliche Inhalte erforderlich, die manuell zurückgehalten werden müssen.

Leistung messen

Bei der Messung von Leistungsmesswerten sollte in Google Analytics vor allem die Aktivierungszeit und nicht die Seitenladezeit berücksichtigt werden, die von Browser-APIs gemeldet werden.

Bei den Core Web Vitals, die von Chrome über den Chrome User Experience Report gemessen werden, geht es darum, die Nutzerfreundlichkeit zu messen. Sie werden also anhand der Aktivierungszeit gemessen. Dies führt häufig zu einem LCP von 0 Sekunden und ist somit eine gute Möglichkeit, die Core Web Vitals zu verbessern.

Ab Version 3.1.0 wurde die web-vitals-Bibliothek aktualisiert, damit Pre-Renderings auf die gleiche Weise verarbeitet werden können, wie Chrome Core Web Vitals misst. Bei dieser Version werden auch vorgerenderte Navigationen für diese Messwerte im Attribut Metric.navigationType gekennzeichnet, wenn die Seite vollständig oder teilweise vorgerendert wurde.

Pre-Rendering messen

Ob eine Seite vorab gerendert wurde, erkennen Sie an einem nicht nullwertigen activationStart-Eintrag von PerformanceNavigationTiming. Dies kann dann bei der Protokollierung der Seitenaufrufe mithilfe einer benutzerdefinierten Dimension oder ähnlich protokolliert werden, z. B. mit der oben beschriebenen Funktion pagePrerendered:

// 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 Navigationselemente im Vergleich zu anderen Navigationstypen vorab gerendert werden. Außerdem können Sie Leistungsmesswerte oder Geschäftsmesswerte mit diesen verschiedenen Navigationstypen in Beziehung setzen. Schnellere Seiten bedeuten zufriedenere Nutzer, was sich oft auch auf die Geschäftskennzahlen auswirken kann, wie unsere Fallstudien zeigen.

Wenn Sie die Auswirkungen des Vorab-Renderings von Seiten auf den Geschäftserfolg messen, können Sie entscheiden, ob es sich lohnt, mehr Aufwand in die Verwendung dieser Technologie zu investieren, um mehr Navigationen vorab zu rendern, oder zu untersuchen, warum Seiten nicht vorab gerendert werden.

Trefferraten messen

Neben den Auswirkungen von Seiten, die nach einem Pre-Rendering besucht werden, ist es auch wichtig, Seiten zu messen, die vorzeitig gerendert und nicht anschließend besucht werden. Das könnte bedeuten, dass Sie zu viel vorrendern und wertvolle Ressourcen des Nutzers ohne großen Nutzen verbrauchen.

Dies lässt sich messen, indem beim Einfügen von Spekulationsregeln ein Analyseereignis ausgelöst wird, nachdem geprüft wurde, ob der Browser Pre-Rendering mit HTMLScriptElement.supports('speculationrules') unterstützt, um anzugeben, dass das Pre-Rendering angefordert wurde. Hinweis: Nur weil ein Pre-Render angefordert wurde, bedeutet das nicht, dass es gestartet oder abgeschlossen wurde. Wie bereits erwähnt, ist ein Pre-Render ein Hinweis für den Browser, der Seiten je nach Nutzereinstellungen, aktueller Arbeitsspeichernutzung oder anderen Heuristiken möglicherweise nicht im Voraus rendert.

Sie können dann die Anzahl dieser Ereignisse mit den tatsächlichen Seitenaufrufen vor dem Rendern vergleichen. Alternativ können Sie bei der Aktivierung ein anderes Ereignis auslösen, wenn das den Vergleich erleichtert.

Die „Trefferquote“ kann dann anhand der Differenz zwischen diesen beiden Werten geschätzt werden. Bei Seiten, für die Sie die Speculation Rules API zum Vorab-Rendern verwenden, können Sie die Regeln entsprechend anpassen, um eine hohe Trefferrate beizubehalten und ein Gleichgewicht zwischen der Nutzung der Ressourcen der Nutzer zur Unterstützung und der unnötigen Nutzung zu schaffen.

Beachten Sie, dass es möglicherweise nicht nur aufgrund Ihrer Spekulationsregeln, sondern auch aufgrund des Prerenderings in der Adressleiste zu Vorabrendering kommt. Sie können das Kästchen für document.referrer anklicken (es ist für die Navigation über die Adressleiste leer, einschließlich der vorab gerenderten Navigation über die Adressleiste), wenn Sie diese unterscheiden möchten.

Sehen Sie sich auch Seiten an, die nicht geprerendert werden. Das kann darauf hindeuten, dass diese Seiten nicht für das Prerendering infrage kommen, auch nicht über die Adressleiste. Das bedeutet möglicherweise, dass Sie von dieser Leistungssteigerung nicht profitieren. Das Chrome-Team möchte zusätzliche Tools hinzufügen, um die Eignung für Pre-Rendering zu testen, die vielleicht ähnlich dem bfcache-Testtool entspricht. Außerdem möchte es möglicherweise eine API hinzufügen, um herauszufinden, warum ein Pre-Rendering fehlgeschlagen ist.

Auswirkungen auf Erweiterungen

Im Artikel Chrome-Erweiterungen: API zur Unterstützung der sofortigen Navigation erweitern finden Sie weitere Informationen zu Aspekten, die Entwickler von Erweiterungen bei vorab gerenderten Seiten beachten sollten.

Feedback

Das Chrome-Team arbeitet aktiv an der Prerendering-Funktion 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. Wir freuen uns auch auf Fallstudien zu dieser spannenden neuen API.

Weitere Informationen

• Codelab zu Spekulationsregeln
• Spekulationsregeln debuggen
• NoState Prefetch
• Speculation Rules API-Spezifikation
• Das GitHub-Repository für Navigationsspekulationen
• Chrome-Erweiterungen: API zur Unterstützung der sofortigen Navigation erweitern

Danksagungen

Miniaturansicht von Marc-Olivier Jodoin auf Unsplash