Für eine sofortige Seitennavigation in Chrome vorab rendern

Barry Pollard

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

Kurzer Verlauf des Pre-Renderings

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 Pre-Rendering mit dem Link rel=prerender-Hinweis wurde durch den NoState-Prefetch ersetzt, bei dem stattdessen die von der zukünftigen Seite benötigten Ressourcen abgerufen wurden, die Seite jedoch weder vollständig gerendert noch JavaScript ausgeführt wurde. 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 Pre-Rendering jetzt wieder in Chrome eingeführt. Um Komplikationen bei der bestehenden Nutzung zu vermeiden und eine zukünftige Erweiterung des Pre-Renderings zu ermöglichen, verwendet dieser neue Pre-Rendering-Mechanismus nicht die <link rel="prerender"...>-Syntax, die für den NoState-Prefetch beibehalten wird, um diese Funktion in Zukunft ausmustern zu können.

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, rendert Chrome die Seite möglicherweise automatisch für Sie, wenn es auf der Grundlage Ihres bisherigen Browserverlaufs mit hoher Wahrscheinlichkeit sicher ist, dass Sie diese Seite besuchen.
2. Wenn Sie die Lesezeichenleiste verwenden, wird die Seite in Chrome möglicherweise automatisch vorab gerendert, wenn Sie den Mauszeiger auf eine der Lesezeichenschaltflächen bewegen.
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.

Wenn die vorab gerenderte Seite im verborgenen Zustand geöffnet wird, werden einige APIs, die störendes Verhalten verursachen, in diesem Zustand nicht aktiviert. Stattdessen werden sie erst dann aktiviert, wenn die Seite wieder 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 die Abbruch des Prerenderings als API bereitzustellen und die Funktionen der Entwicklertools zu verbessern, um solche Grenzfälle leichter zu identifizieren.

Auswirkungen des Prerenderings

Das Pre-Rendering ermöglicht einen nahezu sofortigen Seitenaufbau, wie im folgenden Video gezeigt:

Die Beispielwebsite ist bereits schnell, aber selbst hier sehen Sie, wie sich die Nutzerfreundlichkeit durch das Pre-Rendering 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 vorab zu rendern, da dies zu Kosten für Nutzerressourcen 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 Eingabe von „s“ eine angemessene Zuverlässigkeit (gelb). Wenn Sie jedoch „sh“ eingeben, hat Chrome genügend Sicherheit, dass Sie fast immer zu https://sheets.google.com gehen.

Dieser Screenshot wurde in einer relativ neuen Chrome-Installation erstellt und filtert Zero-Trust-Vorhersagen heraus. Wenn Sie sich jedoch Ihre eigenen Prädiktoren ansehen, sehen Sie wahrscheinlich deutlich mehr Einträge und möglicherweise auch mehr Zeichen, 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 seine Vorhersagen kontinuierlich anhand Ihrer Eingaben und Auswahlen.

• Bei einer Zuverlässigkeit von mehr als 50 % (gelb dargestellt) stellt Chrome proaktiv eine Verbindung zur Domain her, rendert die Seite jedoch nicht vorab.
• Bei einem Konfidenzgrad von über 80 % (grün) wird die URL in Chrome vorab gerendert.

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.

Die Standardeinstellung 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, sollten immediate oder eager für document-Regeln mit Vorsicht verwendet werden. Weitere Informationen finden Sie im nächsten Abschnitt Chrome-Limits.

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 umfangreicheren Seitennutzlasten ziehen es vielleicht vor, die Verschwendung durch weniger häufige Spekulationen zu reduzieren, bis Sie ein positiveres Signal der Nutzerabsicht zur Reduzierung der Verschwendung erhalten.

Die Option moderate ist ein Mittelweg. Viele Websites könnten von der folgenden Spekulationsregel profitieren, die einen Link vorrendert, wenn der Mauszeiger 200 Millisekunden lang auf dem Link gehalten wird oder beim Ereignis „Pointerdown“ als 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 vorab abzurufen, ohne dass ein vollständiges Pre-Rendering erforderlich ist. Das kann oft ein guter erster Schritt auf dem Weg zum Pre-Rendering sein:

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

Chrome-Einschränkungen

In Chrome gibt es Limits, um eine übermäßige Nutzung der Speculation Rules API zu verhindern:

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, z. B. durch erneutes Bewegen des Mauszeigers auf diesen Link. Dies führt dazu, dass diese URL neu spekuliert wird und die älteste Spekulation ausgegeben wird. 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-Scriptelement entfernen, wird Kapazität freigesetzt, da die entfernten Spekulationen abgebrochen werden.

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

• Save-Data
• Energiesparmodus bei aktiviertem Akku und niedrigem Akkustand.
• Arbeitsspeichereinschränkungen
• Wenn die Einstellung „Seiten vorab laden“ deaktiviert ist (was auch von Chrome-Erweiterungen wie uBlock Origin ausdrücklich deaktiviert wird).
• Seiten, die in Hintergrund-Tabs geöffnet wurden.

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

Mit all diesen Bedingungen soll die Auswirkung von übertriebenen Spekulationen reduziert werden, wenn diese für Nutzer schädlich sind.

Spekulationsregeln auf einer Seite hinzufügen

Spekulationsregeln können statisch in den HTML-Code der Seite eingefügt oder dynamisch per JavaScript 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> des Hauptframes hinzugefügt werden. Spekulationsregeln in Subframes werden nicht berücksichtigt. Spekulationsregeln auf vorab gerenderten Seiten werden erst dann berücksichtigt, wenn die Seite aktiviert wird.

Der Speculation-Rules-HTTP-Header

Spekulationsregeln können auch über einen Speculation-Rules-HTTP-Header gesendet 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"

Für diese Ressource muss der richtige MIME-Typ verwendet werden. Wenn es sich um eine ursprungsübergreifende Ressource handelt, muss sie 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 Dokumentabrufe verwendet, sondern API- oder teilweise Abrufe von Daten oder Seiten, die dann verarbeitet und auf der aktuellen Seite präsentiert werden. 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.

Mit Spekulationsregeln kann die Anwendung selbst von einer vorherigen Seite aus vorrendert werden. 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 Vorabruf oder Pre-Rendering einer Seite sind bestimmte URL-Parameter (auch Suchparameter genannt) möglicherweise unwichtig für die Seite, die tatsächlich vom Server bereitgestellt wird. Sie werden nur von clientseitigem JavaScript verwendet.

UTM-Parameter werden in Google Analytics beispielsweise zur Kampagnenanalyse verwendet, führen aber normalerweise nicht dazu, dass verschiedene Seiten vom Server ausgeliefert werden. Das bedeutet, dass page1.html?utm_content=123 und page1.html?utm_content=456 dieselbe Seite vom Server bereitstellen, 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. Diese Funktion wird in Chrome (und Chromium-basierten Browsern) für die Navigationsvorhersage unterstützt. Wir arbeiten jedoch daran, dies auch für das Vorab-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. So können Sie 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. Also rufen wir diese URL vorab ab. Sie sollte einen No-Vary-Search-HTTP-Header zurückgeben, der anzeigt, 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. Die Einstellung expects_no_vary_search gibt dem Browser an, dass die Seitenantwort voraussichtlich einen No-Vary-Search-HTTP-Header enthalten wird, und wartet, bis dieser Prefetch abgeschlossen ist.

Einschränkungen der Spekulationsregeln und zukünftige Verbesserungen

Spekulationsregeln gelten derzeit nur für Seiten, die im selben Tab geöffnet werden. Wir arbeiten daran, diese Einschränkung zu verringern.

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 Einschränkung, mit der ursprungsübergreifende Spekulationen für ursprungsübergreifende Links standardmäßig verhindert werden sollen, 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 Funktion hinzuzufügen. Folgen Sie dieser Anleitung zum Support-Service-Worker-Problem, um Updates zu erhalten. Das Vorab-Rendering wird für von Service Workern gesteuerte Seiten unterstützt.

Unterstützung für die Speculation Rules API erkennen

Sie können die Unterstützung der Speculation Rules API mithilfe standardmäßiger 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 ist 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 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 einen Tag Manager 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.

Ein neues inline-speculation-rules-Element kann script-src hinzugefügt werden, damit <script type="speculationrules">-Elemente unterstützt werden, die aus Hash- oder nicht erzwungenen Skripts eingeschleust 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.

Pre-Rendering 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.

Pre-Rendering in Chrome aktivieren und deaktivieren

Pre-Rendering ist nur für Chrome-Nutzer mit der Einstellung „Seiten vorab laden“ in chrome://settings/performance/ aktiviert. 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.

Pre-Rendering serverseitig 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 endgültiger Antwortcode zurückgegeben wird, der nicht erfolgreich war, d. h. nicht im Bereich 200–299 nach Weiterleitungen, wird die Seite nicht vorab gerendert und alle vorab gerenderten Seiten werden 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 Nutzerfreundlichkeit wird jedoch empfohlen, das Prerendering zuzulassen, aber alle Aktionen, die erst ausgeführt werden sollen, wenn die Seite tatsächlich aufgerufen wird, mit JavaScript zu verzögern.

Pre-Rendering in JavaScript erkennen

Die document.prerendering API gibt true zurück, während die Seite vorab gerendert 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 wie die folgende verwenden, um nach Pre-Rendering- und Pre-Rendering-Seiten zu suchen:

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 durch den Nutzer aktiviert wird, der die Seite aufruft, wird das prerenderingchange-Ereignis am document ausgelöst. Damit können Aktivitäten aktiviert werden, die zuvor standardmäßig beim Seitenaufbau gestartet wurden und die erst verzögert werden sollen, wenn der Nutzer die Seite sieht.

Mithilfe dieser APIs kann Front-End-JavaScript vorab gerenderte Seiten erkennen und entsprechend reagieren.

Auswirkungen auf Analysen

Mithilfe von Analysen wird die Websitenutzung gemessen. Beispielsweise können Sie mit Google Analytics Seitenaufrufe und Ereignisse erfassen. Sie können auch Leistungsmesswerte von Seiten mithilfe der Echtzeitüberwachung von Nutzern (Real User Monitoring, RUM) messen.

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

Vor allem bei Verwendung der Speculation Rules API können sich vorab gerenderte Seiten jedoch auf die Analyse auswirken und Websiteinhaber müssen möglicherweise zusätzlichen Code hinzufügen, um Analysen nur für vorab gerenderte Seiten bei der Aktivierung zu ermöglichen, da dies nicht bei allen Analyseanbietern standardmäßig möglich ist.

Dazu kann ein Promise verwendet werden, der auf das prerenderingchange-Ereignis wartet, wenn ein Dokument vorab gerendert wird, oder sofort aufgelöst wird, wenn es jetzt 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();

Dies kann für Analysen und ähnliche Anwendungsfälle sinnvoll sein. In anderen Fällen kann es jedoch sinnvoll sein, mehr Inhalte für diese Fälle zu laden und deshalb document.prerendering und prerenderingchange für eine spezielle Ausrichtung auf Pre-Rendering-Seiten zu verwenden.

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. Dabei kann es sich um bestimmte Teile von JavaScript oder ganze Skriptelemente handeln, die während der Pre-Rendering-Phase nicht ausgeführt werden sollen.

Ein Beispiel ist dieses Script:

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

Sie können dies in ein dynamisch eingefügtes Scriptelement ä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 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. So können beispielsweise Empfehlungen, der Anmeldestatus oder Einkaufswagensymbole zurückgehalten werden, damit immer die aktuellsten Informationen angezeigt werden.

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 bei allgemeinen visibilitychange-Änderungen geprüft werden. Wenn Sie beispielsweise zu einer Seite zurückkehren, die sich im Hintergrund befand, sollten alle Einkaufswagenzä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 Analyse von Leistungsmesswerten sollte geprüft werden, ob diese besser anhand der Aktivierungszeit als anhand der Seitenladezeit gemessen werden sollten, die von Browser-APIs erfasst wird.

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. Das führt häufig zu einem LCP von 0 Sekunden, was zeigt, dass dies eine großartige Möglichkeit zur Verbesserung deiner Core Web Vitals ist.

Ab Version 3.1.0 wurde die web-vitals-Bibliothek aktualisiert, damit vorab gerenderte Navigationen auf die gleiche Weise wie in Chrome für Core Web Vitals gemessen werden. 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-Renderings messen

Ob eine Seite vorab gerendert wurde, erkennen Sie an einem nicht nullwertigen activationStart-Eintrag von PerformanceNavigationTiming. Dieser Wert kann dann mit einer benutzerdefinierten Dimension oder ähnlich beim Protokollieren der Seitenaufrufe 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 Pre-Rendering ausführen und wertvolle Ressourcen der Nutzer nutzen, ohne dass sich daraus ein Vorteil ergibt.

Das lässt sich messen, indem ein Analyseereignis ausgelöst wird, wenn Spekulationsregeln eingefügt werden, nachdem geprüft wurde, ob der Browser das Prerendering mit HTMLScriptElement.supports('speculationrules') unterstützt. So wird angegeben, dass das Prerendering angefordert wurde. Nur weil ein Pre-Rendering angefordert wurde, bedeutet dies nicht, dass ein Pre-Rendering gestartet oder abgeschlossen wurde. Wie bereits erwähnt, ist ein Pre-Rendering ein Hinweis für den Browser und es kann sein, dass Seiten nicht basierend auf den Nutzereinstellungen, der aktuellen Arbeitsspeichernutzung oder anderen Heuristiken vorab gerendert werden.

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 dies einen einfacheren Vergleich ermöglicht.

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.

Achten Sie auch auf Seiten ohne Pre-Renderings, da dies ein Hinweis darauf sein kann, dass diese Seiten nicht für das Pre-Rendering geeignet sind, auch nicht über die Adressleiste. Das kann bedeuten, dass Sie von dieser Leistungssteigerung nicht profitieren. Das Chrome-Team plant, zusätzliche Tools hinzuzufügen, um die Eignung für das Prerendering zu testen, ähnlich wie beim BFCache-Testtool. Außerdem wird möglicherweise eine API hinzugefügt, um zu sehen, warum ein Prerendering fehlgeschlagen ist.

Auswirkungen auf Erweiterungen

Weitere Informationen finden Sie im Beitrag Chrome Extensions: Extending API to support Instant Navigation. Dort werden weitere Aspekte erläutert, die Autoren für vorab gerenderte 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. Außerdem freuen wir uns darauf, Fallstudien zu dieser spannenden neuen API zu hören und zu teilen.

Weitere Informationen

• Codelab zu Spekulationsregeln
• Spekulationsregeln debuggen
• NoState Prefetch
• Speculation Rules API-Spezifikation
• GitHub-Repository zur Navigationsspekulation
• Chrome-Erweiterungen: Erweiterung der API zur Unterstützung der Sofortnavigation

Danksagungen

Miniaturansicht von Marc-Olivier Jodoin auf Unsplash