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 wechseln wird.

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, 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 gepre-rendert 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 per JavaScript eingefügt werden, je nach Wunsch des Seiteninhabers.

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 vorgerendert wurde, ist ihr aktueller Status „Im Vordergrund“ und sie wird weiter geladen. Das bedeutet, dass Sie immer noch 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 die Abbruch des Prerenderings als API bereitzustellen und die Funktionen der Entwicklertools zu verbessern, um solche Grenzfälle leichter zu identifizieren.

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 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 Vorab-Rendering noch läuft, wird die Seite mit dem Vorab-Rendering in den Hauptframe verschoben und das Laden fortgesetzt.

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.

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

Vervollständigungen in der Adressleiste von Chrome ansehen

Im ersten Fall können Sie die Chrome-Vorschläge 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 „https://sheets.google.com“ eingeben, nach dem Tippen von „s“ (beige) bereits relativ hoch. Wenn Sie jedoch „sh“ eingeben, ist Chrome 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 seine Vorhersagen kontinuierlich anhand Ihrer Eingaben und Auswahlen.

• 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 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 (ab Chrome 121 verfügbar), 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 Touchdown 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, 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 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 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

Mit Spekulationsregeln können auch Seiten ohne vollständiges Vorab-Rendering vorab abgerufen werden. 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 dem FIFO-Prinzip (First In, First Out): Wenn das Limit erreicht ist, wird durch eine neue Spekulation die älteste Spekulation abgebrochen und durch die neuere ersetzt, um Speicher 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-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, 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).
• 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 einfügen

Spekulationsregeln können statisch in die HTML-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"

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 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 „sanften 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 ansehen 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 Kampagnenanalyse verwendet, führen aber in der Regel nicht dazu, dass unterschiedliche Seiten vom Server 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. 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 zurückgegeben werden soll. 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. 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. Die Einstellung expects_no_vary_search gibt dem Browser an, dass die Seitenantwort voraussichtlich einen No-Vary-Search-HTTP-Header enthält, 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, aber unterschiedlichen Ursprüngen (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), aktiviert werden, indem ein Supports-Loading-Mode: credentialed-prerender-HTTP-Header eingefügt wird. 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, ursprungsü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 externe Links verbessern, indem Sie URLs mit demselben Ursprung vorab rendern und versuchen, ursprungsübergreifende URLs vorab zu laden:

<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. Das Vorab-Rendering wird für Seiten unterstützt, die von Service Workern gesteuert werden.

Unterstützung der Speculation Rules API erkennen

Sie können die Unterstützung der Speculation Rules API mit standardmäßigen 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-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 direkt im Bereich Elemente in den Chrome-Entwicklertools hinzufügen, werden die Spekulationsregeln ebenfalls 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-Richtlinie per 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. Das ist sowohl für Nutzer als auch für Websiteinhaber von Vorteil, da vorgerenderte Seiten eine bessere Nutzerfreundlichkeit ermöglichen, die sonst nur schwer zu erreichen ist.

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 Einschränkungen für Chrome.

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 endgültiger Antwortcode zurückgegeben wird, der nicht im Bereich 200–299 liegt, 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.

Prerendering 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 größer als null gesetzt. Dieser Wert entspricht der Zeitspanne zwischen dem Start des Vorab-Renderings und der tatsächlichen Aktivierung des Dokuments.activationStart

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

Vorab gerenderte Seiten können sich jedoch – insbesondere bei Verwendung der Speculation Rules API – auf Analysen auswirken. Websiteinhaber müssen möglicherweise zusätzlichen Code hinzufügen, um Analysen bei der Aktivierung nur für vorab gerenderte 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 und können dann document.prerendering und prerenderingchange verwenden, um das Prerendering speziell auf Seiten auszurichten.

Andere Inhalte während des Pre-Renderings 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 JavaScript-Abschnitte oder ganze Scriptelemente sein, die nicht in der Pre-Render-Phase 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.

Dies ist zwar bei der Verwendung des Prerenderings wahrscheinlicher, aber auch für Seiten, die in den oben genannten Hintergrund-Tabs geladen werden. Die Funktion whenFirstVisible kann also 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 müssen Scripts oder Funktionen nicht immer manuell gekapselt werden, da bestimmte APIs wie bereits erwähnt blockiert werden und auch Iframes von Drittanbietern nicht gerendert werden. Es müssen also nur Inhalte darüber manuell blockiert werden.

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. 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 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-Rendering 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 vorrendern und wertvolle Ressourcen des Nutzers ohne großen Nutzen verbrauchen.

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 angezeigt, dass das Prerendering 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.

Anschließend können Sie 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 Vorab-Renderings in der Adressleiste zu Vorab-Renderings 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 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

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