Für eine sofortige Seitennavigation in Chrome vorab rendern

Das Chrome-Team hat das vollständige Pre-Rendering zukünftiger Seiten, die Nutzer wahrscheinlich aufrufen werden, wieder aktiviert.

Kurzer Verlauf des Pre-Renderings

Früher hat Chrome den Ressourcenhinweis <link rel="prerender" href="/next-page"> unterstützt, dieser wurde jedoch nur in Chrome allgemein unterstützt und es handelte sich nicht um eine 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. Der NoState-Vorabruf verbessert zwar die Seitenleistung, weil dadurch das Laden der Ressourcen verbessert wird, es erfolgt jedoch kein soforter Seitenaufbau wie bei einem vollständigen Pre-Rendering.

Das Chrome-Team hat das vollständige Pre-Rendering nun 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 erhalten bleibt, um diese Funktion in Zukunft ausmustern zu können.

Wie wird eine Seite vorab gerendert?

Eine Seite kann auf eine von vier 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 mit hoher Wahrscheinlichkeit sicher ist, dass Sie diese Seite besuchen.
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 Adressleiste von Chrome eingeben, rendert Chrome die Suchergebnisseite möglicherweise automatisch, wenn Sie von der Suchmaschine dazu aufgefordert werden.
4. Websites können die Speculation Rules API verwenden, um Chrome programmatisch mitzuteilen, welche Seiten vorab gerendert werden sollen. Das ersetzt die bisherige Funktion von <link rel="prerender"...> und ermöglicht Websites, eine Seite basierend auf den Spekulationsregeln auf der Seite proaktiv vorab zu rendern. Diese können statisch auf den Seiten vorhanden sein oder dynamisch von JavaScript eingeschleust werden, wenn es der Seitenbetreiber für angebracht hält.

In jedem dieser Fälle verhält sich ein Pre-Rendering so, als wäre die Seite in einem unsichtbaren Hintergrund-Tab geöffnet worden. Es wird dann „aktiviert“, indem der Vordergrund-Tab durch die vorab gerenderte Seite ersetzt wird. Wenn eine Seite aktiviert wird, bevor sie vollständig vorab gerendert wurde, ist ihr aktueller Status „vorgestellt“ und wird weiter geladen. Sie haben also immer noch einen guten Vorsprung.

Wenn die vorab gerenderte Seite im verborgenen Zustand geöffnet wird, werden einige APIs, die aufdringliches Verhalten verursachen (z. B. Aufforderungen), in diesem Zustand nicht aktiviert. Stattdessen werden sie erst dann aktiviert, wenn die Seite wieder aktiviert wird. Sollte dies in einigen wenigen Fällen noch nicht möglich sein, wird das Pre-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 Pre-Renderings

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

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: LCP fast null, reduzierter CLS (da der CLS-Wert vor dem ersten Aufruf erfolgt) und ein verbesserter INP, da der Ladevorgang abgeschlossen sein sollte, bevor der Nutzer interagiert.

Auch wenn eine Seite aktiviert wird, bevor sie vollständig geladen wurde, sollte die Nutzerfreundlichkeit beim Seitenaufbau mit einem möglichst schnellen Start verbessert werden. 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.

Das Pre-Rendering beansprucht jedoch mehr Arbeitsspeicher und Netzwerkbandbreite. Achten Sie darauf, nicht zu viel vorab zu rendern, da dies zu Kosten für Nutzerressourcen führt. Vorab rendern, wenn die Wahrscheinlichkeit hoch ist, dass die Seite aufgerufen wird

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

Vervollständigungen in der Adressleiste von Chrome ansehen

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

Die grünen Linien weisen auf eine ausreichende Zuverlässigkeit hin, um das Pre-Rendering auszulösen. In diesem Beispiel gibt die Eingabe von „s“ eine angemessene Zuverlässigkeit (gelb) aus, aber sobald Sie „sh“ eingeben, hat Chrome genügend Zuverlässigkeit, dass Sie fast immer zu https://sheets.google.com wechseln.

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.

Diese Prädiktoren steuern auch die vorgeschlagenen Optionen in der Adressleiste, die Sie vielleicht bemerkt haben:

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

• 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 Konfidenzniveau von mehr als 80 % (grün dargestellt) rendert Chrome die URL vorab.

Die Speculation Rules API

Bei der dritten Pre-Rendering-Option können Webentwickler JSON-Anweisungen in ihre Seiten einfügen, um den Browser darüber zu informieren, welche URLs vorab gerendert werden sollen:

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

Oder mithilfe von Dokumentregeln (verfügbar in Chrome 121), die im Dokument gefundene Links basierend auf href-Selektoren (basierend auf der URL Pattern API) oder CSS-Selektoren vorab rendern:

<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. Darin wird Schritt für Schritt erklärt, wie Sie einer Website Spekulationsregeln hinzufügen.

Eifer

Mit der Einstellung eagerness wird angegeben, wann Spekulationen ausgelöst werden sollen. Dies ist besonders bei Dokumentregeln hilfreich:

• immediate:Wird verwendet, um so schnell wie möglich zu spekulieren, d. h. sobald die Spekulationsregeln eingehalten werden.
• eager:Das funktioniert genauso wie die Einstellung immediate, aber wir planen, sie in Zukunft irgendwo zwischen immediate und moderate zu platzieren.
• moderate:Damit werden Spekulationen durchgeführt, wenn du den Mauszeiger 200 Millisekunden über einen Link hältst (oder auf das pointerdown-Ereignis, wenn das früher schon eintrat, und auf einem Mobilgerät, wo kein hover-Ereignis vorhanden ist).
• conservative:Hier wird auf einen Zeiger oder Touchdown 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, auf eine bestimmte Liste. In vielen Fällen sind document-Regeln mit einer geeigneten where-Bedingung jedoch möglicherweise besser.

Die Standardeinstellung 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 angewendet werden (siehe auch den Abschnitt Chrome-Limits).

Welche eagerness-Einstellung Sie verwenden sollten, hängt von Ihrer Website ab. Bei einer schlanken, statischen Website kann die ehrgeizigere Spekulation wenig Kosten verursachen und für die 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 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>

Vorabruf

Spekulationsregeln können auch verwendet werden, um Seiten vorab abzurufen, ohne dass ein vollständiges Pre-Rendering erforderlich ist. Dies kann oft ein guter erster Schritt zum Pre-Rendering sein:

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

Chrome-Limits

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

Eifer	Vorabruf	Vorab rendern
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, 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 gemäß der vorherigen Spekulation alle im Cache speicherbaren Ressourcen für diese URL im HTTP-Cache zwischengespeichert, sodass die Spekulation einer weiteren Zeit zu geringeren Kosten führen sollte. Aus diesem Grund ist der Grenzwert auf den moderaten Grenzwert von 2 festgelegt. Statische Listenregeln werden nicht durch eine Nutzeraktion ausgelöst und haben daher ein höheres Limit, da der Browser nicht erkennen kann, welche Elemente wann erforderlich sind.

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

Chrome verhindert außerdem, dass Spekulationen unter bestimmten Bedingungen verwendet werden:

• Daten speichern:
• Energiesparmodus bei aktiviertem Akku und niedrigem Akkustand.
• Arbeitsspeichereinschränkungen.
• Die Einstellung „Seiten vorab laden“ ist deaktiviert, was auch explizit durch Chrome-Erweiterungen wie uBlock Origin deaktiviert wird.
• In Tabs im Hintergrund geöffnete Seiten.

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

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 hinzufü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 viele Nutzer häufig die nächste Navigation ist. Alternativ können Dokumentregeln mit moderate oder conservative verwendet werden, um zu spekulieren, während Nutzer mit Links interagieren.
• Dynamisch eingefügte Spekulationsregeln: Diese können auf der Anwendungslogik, auf den Nutzer personalisiert oder auf anderen Heuristiken basieren.

Denjenigen, die das dynamische Einfügen basierend auf Aktionen wie dem Bewegen des Mauszeigers oder Klicken auf einen Link bevorzugen – wie es viele Bibliotheken in der Vergangenheit mit <link rel=prefetch> getan haben – wird empfohlen, sich die Dokumentregeln anzusehen, da diese dem Browser viele Anwendungsfälle abwickeln können.

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 die Dokumentinhalte selbst ändern zu müssen.

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

Speculation-Rules: "/speculationrules.json"

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, können Sie den "relative_to": "document"-Schlüssel in Ihre Spekulationsregeln einbeziehen. Andernfalls sind relative URLs relativ zur URL der JSON-Datei der Spekulationsregeln. Dies ist besonders nützlich, wenn Sie einige oder alle Links mit demselben Ursprung auswählen müssen.

Spekulationsregeln und SPAs

Spekulationsregeln werden nur für Vollbildnavigationen unterstützt, die vom Browser verwaltet werden, und nicht für Single-Page-Apps (SPA) oder App-Shell-Seiten. 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“ benötigten Daten können von der App außerhalb der Spekulationsregeln vorab abgerufen werden, aber nicht vorab gerendert.

Mit Spekulationsregeln kann die Anwendung selbst von einer vorherigen Seite vorab gerendert werden. So lassen sich die zusätzlichen Kosten für den anfänglichen Ladevorgang bei einigen SPAs ausgleichen. Routenänderungen innerhalb der App können jedoch nicht vorab gerendert werden.

Spekulationsregeln debuggen

Im speziellen Beitrag zum Debuggen von Spekulationsregeln werden neue Funktionen der Chrome-Entwicklertools beschrieben, die Sie beim Aufrufen und Debuggen dieser neuen API unterstützen.

Mehrere Spekulationsregeln

Einer Seite können auch mehrere Spekulationsregeln hinzugefügt werden, die dann an die vorhandenen Regeln angehängt werden. Daher führen die folgenden unterschiedlichen Arten sowohl zum Pre-Rendering mit one.html als auch zum two.html:

Liste der URLs:

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

Mehrere speculationrules-Skripts:

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

Mehrere Listen innerhalb 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 (sogenannte Suchparameter) 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 andere 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 No-Vary-Search-Angebot kann ein Server Parameter angeben, die nicht zu einem Unterschied zur gelieferten Ressource führen. So kann ein Browser zuvor im Cache gespeicherte Versionen eines Dokuments wiederverwenden, die sich nur durch diese Parameter unterscheiden. Dies wird in Chrome und Chromium-basierten Browsern für 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 zurückgegeben werden soll. 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 ersten Seite /products für die Produkt-IDs 123 und 124 identisch. Die Seiteninhalte können sich jedoch aufgrund des clientseitigen Renderings mit JavaScript unterscheiden, 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.

Wenn der Nutzer jedoch vor Abschluss des Prefetches auf einen der Links klickt, hat der Browser die /products-Seite möglicherweise nicht empfangen. In diesem Fall weiß der Browser nicht, ob er den HTTP-Header No-Vary-Search enthält. Der Browser kann dann entscheiden, ob er den Link noch einmal abrufen oder auf den Abschluss des Prefetches warten soll, 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 für 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 mit demselben Ursprung beschränkt. Spekulationsübergreifende ursprungsübergreifende Seiten derselben Website (z. B. könnte https://a.example.com eine Seite auf https://b.example.com vorab rendern). Um dies zu verwenden, muss die spekulierte Seite (in diesem Beispiel https://b.example.com) durch Einfügen eines Supports-Loading-Mode: credentialed-prerender-HTTP-Headers zustimmen. Andernfalls bricht Chrome die Spekulation ab.

Bei zukünftigen Versionen ist unter Umständen auch das Pre-Rendering für ursprungsübergreifende Seiten ohne dieselbe Website zulässig, 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 ursprungsübergreifende Prefetches, aber auch hier nur dann, wenn keine Cookies für die ursprungsübergreifende Domain vorhanden sind. Wenn Cookies von dem Nutzer vorhanden sind, der diese Website schon einmal besucht hat, wird die Spekulation nicht ausgelöst und es wird ein Fehler in den Entwicklertools 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. Dies stellt eine Verbesserung gegenüber <link rel="prefetch"> bei ursprungsübergreifenden Zielen dar, bei denen zwar auch keine Cookies gesendet, aber dennoch ein Prefetch versucht wird. Dies führt entweder zu einem verschwendeten Prefetch, der noch einmal gesendet werden muss, oder, noch schlimmer, dann, dass die falsche Seite geladen wird.

Spekulationsregeln werden für den Prefetch für Seiten nicht unterstützt, die von Service Workern kontrolliert werden. Wir arbeiten daran, diese Funktion hinzuzufügen. Folgen Sie dieser Anleitung zum Support-Service-Worker-Problem, um Updates zu erhalten. Pre-Rendering wird für Seiten unterstützt, die von Service Workern verwaltet werden.

Unterstützung für die 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 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 Pre-Rendering können Sie sich eine Demo des Pre-Renderings der Speculation Rules API mit JavaScript-Einfügung ansehen.

Wenn Sie ein <script type = "speculationrules">-Element direkt in das DOM einfügen, werden die Spekulationsregeln nicht registriert, da dies wie oben gezeigt hinzugefügt werden muss. Wenn Sie beispielsweise den Bereich Elemente in den Chrome-Entwicklertools direkt bearbeiten, um das Element <script type = "speculationrules"> hinzuzufügen, werden die Spekulationsregeln nicht registriert. Stattdessen muss das Skript zum dynamischen Hinzufügen zum DOM ü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 über JavaScript eingefügt werden. Das <script type = "speculationrules">-Element muss aus den bereits erwähnten Gründen nicht direkt über GTM hinzugefügt werden:

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

Spekulationsregeln abbrechen

Das Entfernen der Spekulationsregeln führt dazu, dass das Pre-Rendering abgebrochen wird. Zu diesem Zeitpunkt wurden jedoch wahrscheinlich bereits Ressourcen für die Initiierung des Pre-Renderings aufgebraucht. Daher wird empfohlen, Pre-Rendering nicht durchzuführen, wenn die Wahrscheinlichkeit besteht, dass Sie das Pre-Rendering abbrechen müssen.

Spekulationsregeln und Content Security Policy

Da Spekulationsregeln ein <script>-Element verwenden, müssen sie, auch wenn sie nur JSON enthalten, in die Content-Security-Policy von script-src aufgenommen werden, wenn die Website dieses Element verwendet – entweder mithilfe eines Hashs oder einer 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 im ursprünglichen HTML-Code enthalten sind, werden nicht unterstützt. Bei Websites mit strikter CSP müssen die Regeln also von JavaScript eingeschleust werden.

Pre-Rendering erkennen und deaktivieren

Das Pre-Rendering ist in der Regel von Vorteil, da die Seiten schnell gerendert werden können – oft 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 das Pre-Rendering von Seiten nicht erfolgen soll, z. B. wenn Seiten den Status ändern – entweder basierend auf der ursprünglichen Anfrage oder darauf, dass JavaScript 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. Das Pre-Rendering ist außerdem auf Geräten mit wenig Arbeitsspeicher oder im Modus „Datensparmodus“ oder „Energiesparmodus“ deaktiviert. Weitere Informationen finden Sie im Abschnitt Chrome-Limits.

Pre-Rendering serverseitig erkennen und deaktivieren

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

Sec-Purpose: prefetch;prerender

Bei vorab über die Speculation Rules API vorabgerufenen Seiten wird dieser Header nur auf prefetch festgelegt:

Sec-Purpose: prefetch

Server können auf Grundlage dieses Headers antworten, Spekulationsanfragen protokollieren, andere Inhalte zurückgeben oder ein Pre-Rendering verhindern. Wenn ein nicht erfolgreicher Antwortcode zurückgegeben wird (d. h. kein 200 oder 304), wird die Seite nicht vorab gerendert und alle Prefetch-Seiten verworfen.

Wenn Sie nicht möchten, dass eine bestimmte Seite vorab gerendert wird, ist dies die beste Methode, um dies zu verhindern. 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 vorab gerendert wird. Damit lassen sich bestimmte Aktivitäten während des Pre-Renderings verhindern oder verzögern, bis die Seite tatsächlich aktiviert wird.

Sobald ein vorab gerendertes Dokument aktiviert wurde, wird der activationStart von PerformanceNavigationTiming auf eine Zeit ungleich null gesetzt, die den Zeitraum zwischen dem Start des Pre-Renderings und der tatsächlichen Aktivierung des Dokuments darstellt.

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
  );
}

Wenn Sie prüfen möchten, ob eine Seite vollständig oder teilweise vorab gerendert wurde, können Sie am einfachsten die Entwicklertools öffnen, nachdem die Seite aktiviert wurde, und performance.getEntriesByType('navigation')[0].activationStart in die Konsole 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

Mit Analytics lassen sich z. B. Seitenaufrufe und Ereignisse erfassen. Alternativ können Sie mit dem Real User Monitoring (RUM) die Leistungsmesswerte von Seiten erfassen.

Seiten sollten nur dann vorab gerendert werden, wenn die Wahrscheinlichkeit hoch ist, dass sie vom Nutzer geladen werden. Aus diesem Grund werden Pre-Rendering-Optionen in der Adressleiste von Chrome nur dann angezeigt, wenn die Wahrscheinlichkeit sehr hoch ist (in mehr als 80% der Fälle).

Besonders bei der Verwendung der Speculation Rules API können sich vorab gerenderte Seiten jedoch auf Analysen 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();

Ein alternativer Ansatz besteht darin, Aktivitäten zu verzögern, bis die Seite zum ersten Mal sichtbar wird. Dies würde sowohl den Pre-Rendering-Fall als auch das Öffnen von Tabs im Hintergrund (z. B. mit einem Rechtsklick und „In neuem Tab öffnen“) abdecken:

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

async function initAnalytics() {
  await whenActivated;
  // 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.

Leistungsmessung

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.

Core Web Vitals, die von Chrome im Bericht zur Nutzererfahrung in Chrome erfasst werden, dient dazu, die Nutzerfreundlichkeit zu ermitteln. Sie werden also basierend auf 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 Pre-Renderings auf die gleiche Weise verarbeitet werden können, wie Chrome Core Web Vitals misst. In dieser Version werden außerdem vorab gerenderte Aufrufe dieser Messwerte im Attribut Metric.navigationType gekennzeichnet, wenn die Seite vollständig oder teilweise vorab gerendert wurde.

Pre-Renderings messen

Ob eine Seite vorab gerendert wurde, ist mit einem activationStart-Eintrag ungleich null von PerformanceNavigationTiming sichtbar. 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 Navigationen im Vergleich zu anderen Navigationstypen vorab gerendert wurden. Außerdem können Sie Leistungsmesswerte oder Geschäftsmesswerte mit diesen verschiedenen Navigationstypen korrelieren. Je schneller die Seiten geladen werden, desto zufriedener sind die Nutzer. Wie unsere Fallstudien zeigen, kann sich das wiederum positiv auf die Geschäftsleistung auswirken.

Wenn Sie die geschäftlichen Auswirkungen des Pre-Renderings für eine sofortige Navigation messen, können Sie entscheiden, ob es sich lohnt, mehr Aufwand in den Einsatz dieser Technologie zu investieren, damit mehr Aufrufe vorab gerendert werden können, oder untersuchen, warum Seiten nicht vorab gerendert werden.

Trefferquoten messen

Neben der Messung der Auswirkungen von Seiten, die nach einem Pre-Rendering aufgerufen werden, ist es wichtig, auch die Seiten zu analysieren, die vorab gerendert und nicht danach aufgerufen wurden. 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.

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

Anschließend können Sie die Anzahl dieser Ereignisse mit den tatsächlichen Pre-Rendering-Seitenaufrufen vergleichen. Alternativ können Sie bei der Aktivierung ein anderes Ereignis auslösen, wenn dies einen einfacheren Vergleich ermöglicht.

Die „Erfolgsquote der erfolgreichen Treffer“ kann dann durch Betrachtung der Differenz zwischen diesen beiden Zahlen geschätzt werden. Für Seiten, auf denen Sie die Speculation Rules API zum Vorabrendern der Seiten verwenden, können Sie die Regeln entsprechend anpassen, um eine hohe Trefferrate aufrechtzuerhalten, um ein Gleichgewicht zwischen der Nutzung der Nutzerressourcen zur Unterstützung und einer unnötigen Verwendung aufrechtzuerhalten.

Beachte, dass einige Pre-Renderings möglicherweise aufgrund des Pre-Renderings in der Adressleiste und nicht nur aufgrund deiner Spekulationsregeln erfolgen. Zur Unterscheidung können Sie sich das document.referrer ansehen (das bei der Adressleistennavigation leer ist, einschließlich vorab gerenderter Adressleistennavigationen).

Sie sollten sich auch Seiten ohne Pre-Renderings ansehen. Das könnte darauf hindeuten, 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 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

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

Pre-Rendering wird vom Chrome-Team aktiv weiterentwickelt und es gibt viele Pläne, den Umfang der in Chrome 108 bereitgestellten 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
• Fehler bei Spekulationsregeln beheben
• Jetzt neu: 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