Leitfaden zur Implementierung von Spekulationsregeln für komplexere Websites

Barry Pollard

Veröffentlicht: 7. März 2025

Mit der Speculation Rules API können Nutzer von einer Leistungssteigerung profitieren, indem sie entweder zukünftige Seitennavigationen im Voraus laden oder vorrendern, um eine schnellere oder sogar sofortige Seitennavigation zu ermöglichen.

Die API wurde speziell für eine einfache Implementierung entwickelt. Bei komplexen Websites müssen jedoch einige Aspekte berücksichtigt werden, bevor sie verwendet werden kann. In diesem Leitfaden erfahren Sie mehr über diese Aspekte.

Planung

Bevor Sie Spekulationsregeln implementieren, sollten Sie überlegen, wie Sie die API implementieren möchten (da es einige Möglichkeiten gibt), und auch die Kosten für Spekulationen berücksichtigen, die Ihnen bei der Entscheidung helfen sollten, für welche Seiten Sie spekulieren möchten.

Festlegen, wie Spekulationsregeln implementiert werden

Eine der ersten Entscheidungen, die Sie treffen müssen, ist, wie Sie Spekulationsregeln auf Ihrer Website implementieren. Es gibt verschiedene Methoden, die Sie verwenden können:

• Direkt im HTML-Code der Seite
• JavaScript verwenden
• HTTP-Header verwenden

Letztendlich hat jede Methode denselben Effekt, aber es kann Vorteile in Bezug auf die einfache Implementierung und Flexibilität geben.

Websites sollten die Option auswählen, die am besten zu ihnen passt. Bei Bedarf kann auch eine Kombination dieser Optionen verwendet werden. Alternativ können sie auch über ein Plug-in (z. B. das Plug-in für spekulatives Laden für WordPress) oder Bibliotheken oder Plattformen implementiert werden, die die Entscheidung für Sie treffen. Es ist jedoch trotzdem sinnvoll, sich mit den verfügbaren Optionen vertraut zu machen.

Spekulationsregeln direkt in den HTML-Code der Seite aufnehmen

Spekulationsregeln können direkt auf der Seite implementiert werden, indem das <script type="speculationrules">-Element in die HTML-Datei eingefügt wird. Dies kann entweder bei der Erstellung für statische Websites mithilfe von Vorlagen oder zur Laufzeit vom Server hinzugefügt werden, wenn die Seite angefordert wird. Sie können sogar von Edge-Workern in HTML-Code eingefügt werden. Die HTTP-Header-Methode, die später in diesem Leitfaden erläutert wird, ist dafür jedoch wahrscheinlich einfacher.

So können Sie statische Regeln für die gesamte Website einschließen. Dokumentregeln können aber trotzdem dynamisch sein, da Sie die URLs auswählen können, die von der Seite gerendert werden sollen, indem Sie Regeln verwenden, die von CSS-Klassen ausgelöst werden:

<script type="speculationrules">
  {
    "prerender": [{
      "where": { "selector_matches": ".prerender" }
    }],
    "prefetch": [{
      "where": { "selector_matches": ".prefetch" }
    }]
  }
</script>

Das vorherige Script rendert Links mit der Klasse prerender vorab und lädt sie vorab, wenn ein Link die Klasse prefetch hat. So können Entwickler diese Klassen in die HTML-Datei einfügen, um Spekulationen auszulösen.

Zusätzlich zu den Links zu diesen Klassen in der ursprünglichen HTML-Datei einer Seite werden auch Links geschätzt, wenn diese Klassen von Ihrer App dynamisch hinzugefügt werden. So kann Ihre App nach Bedarf Spekulationen auslösen (und entfernen). Das kann einfacher sein als das Erstellen oder Entfernen spezifischerer Spekulationsregeln. Sie können auch mehrere Spekulationsregeln pro Seite einschließen, wenn Sie eine Basisregel für die meisten Bereiche der Website und seitenspezifische Regeln benötigen.

Wenn Sie jedoch genauere Spekulationsregeln verwenden möchten, können Sie mit seiten- oder vorlagenspezifischen Regeln unterschiedliche Regeln für bestimmte Seiten oder Seitentypen festlegen.

Außerdem können serverseitig gerenderte Seiten auch dynamischere Regeln haben, die auf den Informationen basieren, die dem Server zur Verfügung stehen, z. B. Analysedaten für diese Seite oder häufige Nutzerpfade für bestimmte Seiten.

Spekulationsregeln mit JavaScript hinzufügen

Anstatt die Regeln in ein On-Page-Script einzufügen, können Sie sie auch mit JavaScript einschleusen. Dadurch sind möglicherweise weniger Aktualisierungen der Seitenvorlagen erforderlich. So können Sie beispielsweise über ein Tag-Management-System Regeln einschleusen, um Spekulationsregeln schnell einzuführen und bei Bedarf auch schnell wieder zu deaktivieren.

Mit dieser Option sind auch dynamische, clientseitige Regeln möglich, die darauf basieren, wie der Nutzer mit der Seite interagiert. Wenn der Nutzer beispielsweise einen Artikel in den Einkaufswagen legt, können Sie die Zahlungsseite vorab rendern. Alternativ können Sie damit Spekulationen basierend auf bestimmten Bedingungen auslösen. Die API enthält eine Einstellung für die Voraktivierung, die grundlegende interaktionsbasierte Regeln ermöglicht. Mit JavaScript können Entwickler jedoch ihre eigene Logik verwenden, um zu entscheiden, wann und auf welchen Seiten eine Spekulation erfolgen soll.

Wie bereits erwähnt, besteht eine alternative Möglichkeit zum Einfügen neuer Regeln darin, eine Basisdokumentregel auf der Seite zu haben und JavaScript-Triggerdokumentregeln zu verwenden, indem Links entsprechende Klassen hinzugefügt werden, sodass sie mit der Regel übereinstimmen.

Spekulationsregeln über einen HTTP-Header hinzufügen

Die letzte Option für Entwickler besteht darin, die Regeln über einen HTTP-Header einzufügen:

Speculation-Rules: "/speculationrules.json"

Für die Bereitstellung und Verwendung der Regeln-Ressource (/speculationrules.json in diesem Beispiel) gelten einige zusätzliche Anforderungen.

Diese Option ermöglicht eine einfachere Bereitstellung durch CDNs, ohne dass der Dokumentinhalt geändert werden muss. Das bedeutet, dass die Spekulationsregeln nicht dynamisch mit JavaScript geändert werden können. Dokumentregeln mit CSS-Selektorauslösern können jedoch weiterhin dynamische Änderungen zulassen, z. B. durch Entfernen der Klasse prerender von einem Link.

Ähnlich wie bei der JavaScript-Option können Spekulationsregeln mit einem HTTP-Header unabhängig vom Inhalt der Website implementiert werden. Das erleichtert das Hinzufügen und Entfernen der Regeln, ohne die Website vollständig neu erstellen zu müssen.

Kosten berücksichtigen

Bevor Sie Spekulationsregeln implementieren, sollten Sie sich die Zeit nehmen, die Kostenfolgen für Ihre Nutzer und Ihre Website mit dieser API zu berücksichtigen. Dazu gehören Bandbreitenkosten (die sowohl Nutzern als auch Websites Geld kosten) und Verarbeitungskosten (sowohl auf der Client- als auch auf der Serverseite).

Kosten für Nutzer berücksichtigen

Spekulatives Laden bedeutet, eine fundierte Vermutung darüber anzustellen, wohin ein Nutzer als Nächstes wechseln könnte. Wenn dies jedoch nicht der Fall ist, haben Sie möglicherweise Ressourcen verschwendet. Daher sollten Sie sich der Auswirkungen auf die Nutzer bewusst sein, insbesondere:

• Zusätzliche Bandbreite, die zum Herunterladen dieser zukünftigen Navigationselemente verwendet wird – insbesondere auf Mobilgeräten, wo die Bandbreite möglicherweise eingeschränkt ist.
• Zusätzliche Verarbeitungskosten für das Rendern dieser Seiten bei der Verwendung von Prerendering.

Bei vollständig korrekten Vorhersagen fallen keine zusätzlichen Kosten an, da Besucher diese Seiten als Nächstes aufrufen. Der einzige Unterschied besteht darin, dass diese Kosten vorab anfallen. Es ist jedoch unmöglich, die Zukunft mit absoluter Genauigkeit vorherzusagen. Je aggressiver die Spekulationsstrategie ist, desto höher ist das Risiko von Verschwendung.

Chrome hat dieses Problem sorgfältig bedacht und die API enthält eine Reihe von Funktionen, die dazu führen, dass die Kosten viel niedriger sind als Sie vielleicht denken. Insbesondere durch die Wiederverwendung des HTTP-Caches und das Nichtladen von iframes mit unterschiedlichen Ursprüngen sind die Kosten für das Vorab-Rendering einer Navigation auf derselben Website oft erheblich geringer als für eine vollständige Seite ohne im Cache gespeicherte Ressourcen. Dadurch sind spekulative Ladevorgänge kostengünstiger als angenommen.

Auch mit diesen Sicherheitsvorkehrungen sollten Websites sorgfältig überlegen, welche Seiten sie spekulieren möchten, und die Kosten für die Nutzer solcher Spekulationen berücksichtigen. Gute Kandidaten für das spekulative Laden sind solche, die mit hoher Wahrscheinlichkeit vorhergesagt werden können (z. B. anhand von Analysen oder gängigen Nutzerinteraktionen) und bei denen die Kosten niedrig sind (z. B. weniger umfangreiche Seiten).

Sie sollten auch überlegen, welches JavaScript bis zur Aktivierung verzögert werden soll. Ähnlich wie beim Lazy Loading von Inhalten, die erst geladen werden, wenn sie benötigt werden, können Pre-Render-Inhalte kostengünstiger sein, aber eine wesentlich bessere Nutzererfahrung bieten. Bei günstigeren Spekulationen fühlen Sie sich möglicherweise wohler, häufiger oder freudiger zu spekulieren.

Ist dies nicht möglich, wird eine weniger aggressive Strategie mit moderaten oder konservativen Regeln für die Eagerness empfohlen. Alternativ können Sie das Prefetching verwenden, das bei geringer Wahrscheinlichkeit deutlich weniger kostet als das Prerendering. Wenn die Wahrscheinlichkeit steigt, können Sie dann zu einem vollständigen Prerendering wechseln, z. B. wenn der Mauszeiger auf einen Link bewegt oder darauf geklickt wird.

Zusätzliche Back-End-Last berücksichtigen

Websiteinhaber sollten nicht nur die zusätzlichen Kosten für die Nutzer, sondern auch ihre eigenen Infrastrukturkosten berücksichtigen. Wenn jede Seite zwei, drei oder sogar mehr Seitenladevorgänge auslöst, können die Backend-Kosten durch die Verwendung dieser API steigen.

Hinweis:Die Backend-Auslastung kann besonders zu Spitzenzeiten relevant sein, z. B. bei Veranstaltungen mit hoher Besucherzahl, wenn Angebote laufen. Sie sollten in diesen Zeiten die Spekulationsregeln deaktivieren und die Möglichkeit haben, dies kurzfristig zu tun. Je nach Ihrer eigenen Websiteinfrastruktur und Ihrem Release-Prozess kann dies mit verschiedenen Strategien zur Bereitstellung von Spekulationsregeln einfacher oder schwieriger sein.

Wenn Sie dafür sorgen, dass Ihre Seiten und Ressourcen im Cache gespeichert werden können, wird die Auslastung des Ursprungs erheblich reduziert und damit auch das Gesamtrisiko. In Verbindung mit einem CDN sollten Ihre Ursprungsserver nur eine minimale zusätzliche Auslastung erfahren. Berücksichtigen Sie jedoch mögliche CDN-Kostensteigerungen.

Mit einem Server oder CDN können auch die Spekulationsergebnisse gesteuert werden, die durch den HTTP-Header „sec-purpose“ angegeben werden. Das Speed Brain-Produkt von Cloudflare erlaubt beispielsweise nur Spekulationen, die bereits im Edge-Server eines CDN im Cache gespeichert sind, und sendet keine Anfragen an den Ursprung zurück.

Da spekulative Ladevorgänge jedoch in der Regel für Seitenladevorgänge mit demselben Ursprung verwendet werden, haben Nutzer bereits gemeinsame Ressourcen im Cache ihres Browsers, vorausgesetzt, sie sind überhaupt im Cache ablegbar. Daher ist eine Spekulation in der Regel nicht so kostspielig wie das vollständige Laden einer Seite.

Die richtige Balance zwischen zu viel und zu wenig Spekulation finden

Der Schlüssel zur optimalen Nutzung der Spekulationsregeln-API besteht darin, das richtige Gleichgewicht zwischen zu viel Spekulation (d. h., wenn die Kosten unnötig bezahlt werden und die Spekulation nicht genutzt wird) und zu konservativ (entweder zu wenig oder zu spät, wo nur wenig Nutzen erzielt wird) zu finden.

Wenn die Kosten niedrig sind (z. B. bei kleinen, statisch generierten Seiten, die in CDN-Edge-Knoten im Cache gespeichert sind), können Sie bei der Spekulation aggressiver vorgehen.

Bei größeren, umfangreicheren Seiten, die möglicherweise nicht am CDN-Edge-Cache gespeichert werden können, ist jedoch Vorsicht geboten. Ebenso können ressourcenintensive Seiten die Netzwerkbandbreite oder Rechenleistung beanspruchen, was sich negativ auf die aktuelle Seite auswirken kann. Das Ziel der API ist es, die Leistung zu verbessern. Leistungseinbußen sind also definitiv nicht erwünscht. Dies ist ein weiterer Grund dafür, die Anzahl der vorab gerenderten Seiten auf maximal eine oder zwei zu beschränken. Beachten Sie außerdem, dass Chrome je nach Eagerness-Einstellung zwei oder zehn vorab gerenderte Seiten gleichzeitig zulässt.

Schritte zur Implementierung von Spekulationsregeln

Nachdem Sie entschieden haben, wie Sie Spekulationsregeln implementieren möchten, müssen Sie als Nächstes planen, was Sie spekulieren und wie Sie dies einführen möchten. Bei einfacheren Websites wie statischen privaten Blogs kann es sein, dass bestimmte Seiten direkt vollständig vorgerendert werden. Bei komplexeren Websites sind jedoch zusätzliche Komplexitäten zu berücksichtigen.

Mit Prefetch beginnen

Die Vorab-Ladefunktion kann für die meisten Websites relativ sicher implementiert werden. Dies ist der erste Ansatz, den viele verfolgen, einschließlich groß angelegter Einführungen wie Cloudflare und WordPress.

Die wichtigsten Probleme, die Sie beachten sollten, sind Statusänderungen und serverseitige Kosten, die durch das Vorabladen einer URL verursacht werden, insbesondere bei Seiten, die nicht im Cache gespeichert werden können. Idealerweise sollten Zustandsänderungen – z. B. das Vorabladen einer /logout-Seite – nicht als GET-Links implementiert werden. Leider ist dies im Web aber keine Seltenheit.

Solche URLs können ausdrücklich von den Regeln ausgeschlossen werden:

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

Mit der Einstellung moderate oder conservative eagerness können Sie die Vorab-Ladefunktion auf häufige Navigationen von einer Seite zur anderen oder auf alle Links mit demselben Ursprung beschränken, die beim Bewegen des Mauszeigers oder Klicken aufgerufen werden. Die Einstellung conservative hat das geringste Risiko, aber auch den geringsten potenziellen Gewinn. Wenn Sie hier beginnen, sollten Sie mindestens moderate anstreben, aber idealerweise eager, da dies weitere Leistungsvorteile bietet. Wenn sinnvoll, können Sie dann auf prerender umstellen.

Prerender mit geringem Risiko

Prefetch-Spekulationen sind einfacher bereitzustellen, aber der ultimative Leistungsvorteil der API liegt beim Pre-Rendering. Dies kann einige zusätzliche Überlegungen erfordern, wenn die Seite nicht kurz nach der Spekulation besucht wird (wird im nächsten Abschnitt behandelt). Bei einem moderate- oder conservative-Prerender, bei dem die Navigation wahrscheinlich kurz danach erfolgt, ist der nächste Schritt jedoch mit relativ geringem Risiko verbunden.

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

Häufig besuchte Seiten vorab abrufen, um nicht sofortige Vorab-Renderings zu verbessern

Eine gängige Taktik besteht darin, beim Laden eine kleinere Anzahl häufig besuchter nächster Seiten mit einer eager-Einstellung vorab zu laden (entweder durch Angabe in einer URL-Liste oder mit selector_matches) und dann mit einer moderate-Einstellung vorzurendern. Da das HTML-Prefetching wahrscheinlich abgeschlossen ist, wenn der Mauszeiger auf den Link bewegt wird, ist dies eine Verbesserung gegenüber dem Prerendering beim Bewegen des Mauszeigers ohne Prefetching.

<script type="speculationrules">
  {
    "prefetch": [{
      "urls": ["next.html", "next2.html"],
      "eagerness": "eager"
    }],
    "prerender": [{
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": {"href_matches": "/logout"}}
        ]
      },
      "eagerness": "moderate"
    }]
  }
</script>

Frühere Pre-Renderings

moderate-Dokumentregeln ermöglichen eine relativ risikoarme Verwendung der API mit einer einfachen Implementierung. Oft ist dies jedoch nicht genug Zeit für ein vollständiges Pre-Rendering. Um die von dieser API ermöglichte sofortige Navigation zu erreichen, müssen Sie wahrscheinlich noch mehr tun und Seiten schneller vorrendern.

Dies geschieht mit einer statischen Liste von URLs (wie im vorherigen Beispiel für das Prefetching) oder mit selector_matches, um eine kleine Anzahl von URLs (idealerweise eine oder zwei Seiten) zu identifizieren, wobei die anderen URLs durch Dokumentregeln abgedeckt werden:

<script type="speculationrules">
  {
    "prerender": [
      {
        "where": {
          "selector_matches": : ".prerender"
        },
        "eagerness": "eager",
      },
      {
        "where": {
          "and": [
            { "href_matches": "/*" },
            { "not": {"href_matches": "/logout"}}
          ]
        },
        "eagerness": "moderate"
      }
    ]
  }
</script>

Dazu ist möglicherweise eine Besucheranalyse erforderlich, um die nächste Navigation möglichst genau vorhersagen zu können. Wenn Sie die typischen Kaufprozesse auf Ihrer Website kennen, können Sie auch leichter geeignete Kandidaten für das spekulative Laden identifizieren.

Wenn Sie ein aggressiveres Prerendering verwenden, müssen Sie möglicherweise auch mehr über Analysen, Anzeigen und JavaScript nachdenken und die vorab gerenderte Seite auf dem neuesten Stand halten oder sogar Vorhersagen zu Statusänderungen abbrechen oder aktualisieren.

Analytics, Anzeigen und JavaScript

Bei komplexeren Websites müssen Sie bei der Verwendung von Prerendering auch die Auswirkungen auf die Analysen berücksichtigen. Normalerweise sollten Sie eine Seiten- oder Anzeigenaufruf nicht erfassen, wenn die Seite geschätzt wird, sondern nur, wenn die Schätzung aktiviert ist.

Einige Analyseanbieter (z. B. Google Analytics) und Anzeigenanbieter (z. B. Google Publisher Tag) unterstützen bereits Spekulationsregeln und erfassen keine Aufrufe, bis die Seite aktiviert ist. Andere Anbieter oder von Ihnen implementierte benutzerdefinierte Analysen müssen jedoch möglicherweise gesondert berücksichtigt werden.

Sie können JavaScript-Prüfungen hinzufügen, um die Ausführung bestimmter Codeteile zu verhindern, bis Seiten aktiviert oder sichtbar gemacht werden. Sie können sogar ganze <script>-Elemente in solche Prüfungen einschließen. Wenn auf Seiten Tag Manager verwendet wird, um solche Scripts einzuschleusen, können Sie sie möglicherweise alle auf einmal beheben, indem Sie das Tag Manager-Script selbst verzögern.

Einwilligungsmanager bieten außerdem die Möglichkeit, Drittanbieter-Scripts bis zur Aktivierung zu verzögern. Google arbeitet mit verschiedenen Plattformen für Einwilligungsmanager zusammen, um sie für das Pre-Rendering zu optimieren. Wir helfen Ihnen gern, wenn Sie das auch tun möchten. PubTech ist eines dieser Unternehmen, das Entwicklern die Möglichkeit bietet, JavaScript während des Prerenderings auszuführen oder zu blockieren.

Für Anwendungscode können Sie ebenfalls eine Änderung hinzufügen, um die Ausführung des Codes bis zur Aktivierung zu verzögern, insbesondere wenn die Seite nicht für das Rendern des JavaScript-Codes benötigt wird. Das ist eine schnellere und sicherere Option, bedeutet aber, dass der gesamte Code bei der Aktivierung gleichzeitig ausgeführt wird. Das kann bei der Aktivierung viel Arbeit bedeuten und sich auf die INP auswirken, insbesondere wenn die Seite vollständig geladen und bereit zur Interaktion aussieht.

Wenn Inhalte von JavaScript abhängen (z. B. clientseitig gerenderte Inhalte), verringert sich durch die Verzögerung der positive Effekt, den das Prerendering auf LCP und CLS haben kann. Ein gezielterer Ansatz, der es ermöglicht, mehr JavaScript während der Prerendering-Phase auszuführen, führt zu einer besseren Nutzererfahrung, ist aber möglicherweise nicht ganz so einfach zu implementieren.

Bei komplexeren Websites kann es sinnvoll sein, viele Script-Tags zu Beginn vollständig zu verzögern. Um jedoch die Vorteile der API optimal zu nutzen, sollte beim Prerendering so viel JavaScript wie möglich ausgeführt werden.

Bei Websites mit Problemen mit Analysen oder Anzeigen kann es auch sinnvoll sein, mit dem Prefetching zu beginnen, da diese Probleme dort weniger relevant sind. Gleichzeitig können Sie überlegen, was für das Prerendering erforderlich ist.

Spekulationen für das Vorab-Rendering aktualisieren

Wenn Seiten vor der Navigation gerendert werden, besteht das Risiko, dass die vorab gerenderte Seite veraltet ist. Auf einer E-Commerce-Website kann eine vorab gerenderte Seite beispielsweise einen Einkaufswagen enthalten – entweder einen gefüllten Einkaufswagen mit Artikeln oder auch nur einen Zähler, der die Anzahl der Artikel im Einkaufswagen auf anderen Seiten anzeigt. Wenn dem Einkaufswagen weitere Artikel hinzugefügt werden und dann eine vorab gerenderte Seite aufgerufen wird, wäre es für den Nutzer verwirrend, den alten Bezahlvorgang zu sehen.

Das ist kein neues Problem. Wenn Nutzer mehrere Tabs im Browser geöffnet haben, tritt dasselbe Problem auf. Bei vorab gerenderten Seiten ist dies jedoch sowohl wahrscheinlicher als auch unerwarteter, da der Nutzer das Vorab-Rendering nicht wissentlich initiiert hat.

Mit der Broadcast Channel API können Sie beispielsweise Updates von einer Seite im Browser an andere Seiten übertragen. Damit würde auch das Problem mit mehreren Tabs behoben. Auf vorab gerenderten Seiten können Broadcast-Nachrichten empfangen werden. Sie können jedoch erst nach der Aktivierung eigene Broadcast-Nachrichten senden.

Alternativ können vorab gerenderte Seiten über den Server aktualisiert werden (mit einer regelmäßigen fetch()- oder WebSocket-Verbindung), aber mit möglichen Verzögerungen bei den Aktualisierungen.

Spekulationen für das Vorab-Rendering abbrechen oder aktualisieren

Das Aktualisieren vorab gerenderter Seiten wird empfohlen, um diese weiterhin zu verwenden und Verwirrung bei den Nutzern zu vermeiden. Falls dies nicht möglich ist, können Sie Spekulationen stornieren.

So können Websites auch die Chrome-Limits einhalten, wenn sie andere Seiten vorab rendern möchten, die mit höherer Wahrscheinlichkeit besucht werden.

Wenn Sie Spekulationen aufheben möchten, müssen Sie die Spekulationsregeln von der Seite entfernen oder Klassen oder andere Abgleichskriterien entfernen, wenn Sie diesen Ansatz verwenden. Alternativ kann die geschätzte Seite window.close() aufrufen, wenn sie erkennt, dass sie nicht mehr aktuell ist. Wenn die Seite dies jedoch erkennen kann, ist es besser, den Status zu aktualisieren, um ihn auf den neuesten Stand zu bringen.

Es ist auch möglich, diese Regeln (oder Abgleichskriterien) wieder einzufügen, damit Seiten noch einmal vorab gerendert werden können. Es ist jedoch in der Regel besser, eine vorhandene Seite auf dem neuesten Stand zu halten, da dies weniger Ressourcen verbraucht. Nachdem Spekulationsregeln entfernt wurden, muss die Wiedereinfügung in einem neuen Mikrotask oder später abgeschlossen werden, damit der Browser die Entfernungen bemerken und die Spekulationen abbrechen kann. Im folgenden Beispiel wird eine Möglichkeit zum Löschen und Entfernen aller Scripts für Spekulationsregeln gezeigt:

async function refreshSpeculations() {
  const speculationScripts = document.querySelectorAll('script[type="speculationrules"]');

  for (const speculationScript of speculationScripts) {
    // Get the current rules as JSON text
    const ruleSet = speculationScript.textContent;

    // Remove the existing script to reset prerendering
    speculationScript.remove();
    
    // Await for a microtask before re-inserting.
    await Promise.resolve();

    // Reinsert rule in a new speculation rules script
    const newScript = document.createElement('script');
    newScript.type = 'speculationrules';
    newScript.textContent = ruleSet;
    console.log(newScript);

    // Append the new script back to the document
    document.body.appendChild(newScript);
  }
}

Wenn Sie Regeln entfernen, werden vorhandene Prätendenten (oder Vorabrufe) abgebrochen. Wenn Sie die Regeln wieder einfügen, werden nur sofortige oder vorzeitige Regeln (einschließlich URL-Listenregeln mit der Standardeinstellung „sofort“) spekuliert. Moderate oder konservative Spekulationen werden jedoch entfernt, aber nicht automatisch wieder ausgelöst, bis wieder mit dem Link interagiert wird.

Diese Aktualisierungsoption ist nicht auf JavaScript-eingebettete Regeln beschränkt. Statische Regeln im HTML-Code können auf die gleiche Weise entfernt oder geändert werden, da es sich um eine Standard-DOM-Änderung handelt. HTTP-Spekulationsregeln können nicht entfernt werden, aber Abgleichskriterien (z. B. prerender-Klassen) können entfernt und per JavaScript wieder hinzugefügt werden.

Außerdem wird in Chrome die Unterstützung für Clear-Site-Header geprüft, damit Serverantworten Pre-Renderings abbrechen können, z. B. wenn eine Aktualisierungsanfrage für den Einkaufswagen gestellt wird.

Wirkung messen

Nach der Implementierung von Spekulationsregeln sollten Sie den Erfolg messen und nicht einfach davon ausgehen, dass die Abläufe automatisch schneller sind. Wie bereits erwähnt, kann eine zu hohe Auslastung zu Leistungseinbußen führen, wenn der Client oder Server überlastet ist.

Wenn Sie die Implementierung in mehreren Schritten vornehmen (Prefetch, Prerendering mit geringem Risiko und dann frühes Prerendering), sollten Sie die Leistung bei jedem Schritt messen.

Erfolg messen

Spekulationsregeln sollten sich positiv auf wichtige Leistungsmesswerte wie LCP (und möglicherweise auch auf CLS und INP) auswirken. Diese Auswirkungen sind jedoch bei den allgemeinen Messwerten auf Websiteebene möglicherweise nicht offensichtlich. Das liegt daran, dass Websites hauptsächlich aus anderen Navigationstypen bestehen (z. B. Landingpages) oder dass Navigationen mit demselben Ursprung bereits so schnell sind, dass selbst eine drastische Verbesserung keinen Einfluss auf die Messwerte des 75. Percentils hat, die im Bericht zur Nutzererfahrung in Chrome (Chrome User Experience, CrUX) aufgeführt sind.

Anhand der Arten der Seitennavigation in CrUX können Sie prüfen, welcher Prozentsatz der Navigationen navigate_cache oder prerender ist und ob sich dieser Wert im Laufe der Zeit erhöht. Für eine detaillierte Analyse müssen Sie jedoch möglicherweise Real User Monitoring verwenden, um Ihre Daten in Navigationen mit vermuteten Navigationen zu segmentieren und so zu sehen, wie viel schneller sie als andere Navigationen sind.

Nutzung und Verschwendung messen

Ein weiterer wichtiger Aspekt ist, zu messen, ob Sie auf den richtigen Seiten spekulieren. So vermeiden Sie unnötige Ausgaben und können Ihre Anzeigen auf die Seiten ausrichten, die sich am besten für diese API eignen.

Leider kann der Status der Spekulationsversuche nicht direkt auf der Seite eingesehen werden, auf der die Spekulationen initiiert werden. Außerdem kann nicht davon ausgegangen werden, dass Versuche ausgelöst wurden, da der Browser unter bestimmten Umständen Spekulationen zurückhalten kann. Sie müssen daher auf der Seite selbst gemessen werden. Außerdem müssen zwei APIs geprüft werden, um festzustellen, ob auf der Seite spekuliert wird oder wurde:

if (document.prerendering) {
  console.log("Page is prerendering");
} else if (performance.getEntriesByType("navigation")[0]?.activationStart > 0) {
  console.log("Page has already prerendered");
} else {
  console.log("This page load was not using prerendering");
}

Diese Seite kann den Spekulationsversuch dann auf den Backend-Servern protokollieren.

Eine Komplikation bei Analysen sind Anbieter wie Google Analytics, die Prerendering unterstützen und Analyseaufrufe ignorieren, bis die Seite aktiviert wird – auch separate Ereignisaufrufe. Daher müssen Google Analytics-Nutzer eine andere Option für die serverseitige Protokollierung verwenden.

Es ist auch möglich, dies clientseitig zu tun, wobei jede vorgerenderte Seite das Pre-Rendering im freigegebenen Speicher protokolliert und die aufrufende Seite dies liest. localStorage funktioniert am besten, da es gelesen werden kann, wenn Sie von einer Seite wegnavigieren. sessionStorage kann nicht verwendet werden, da es eine spezielle Verarbeitung für vorrenderte Seiten gibt. Beachten Sie jedoch, dass localStorage nicht transaktionssicher ist und andere Seiten diesen Wert möglicherweise gleichzeitig aktualisieren, wenn mehrere Seiten vorab gerendert werden. In dieser Demo werden ein eindeutiger Hash und einzelne Einträge verwendet, um Probleme zu vermeiden.

Fazit

Mit Spekulationsregeln lässt sich die Seitenleistung deutlich steigern. In diesem Leitfaden finden Sie Informationen zu den wichtigsten Aspekten bei der Implementierung dieser API, damit Sie potenzielle Probleme vermeiden und die API optimal nutzen können.

Eine frühzeitige Planung der Implementierung vermeidet Nacharbeit. Insbesondere bei komplexeren Websites sollte ein mehrstufiges Roll-out folgen, beginnend mit dem Prefetching, gefolgt vom Prerendering mit geringem Risiko und dann dem frühen Prerendering. Schließlich ist es wichtig, die Verbesserungen sowie die Nutzung und Verschwendung zu messen, damit Sie die API optimal nutzen können.