Veröffentlicht: 7. März 2025
Mit der Speculation Rules API können Nutzer von einer Leistungssteigerung profitieren, indem sie zukünftige Seitennavigationen vorabrufen oder vorab rendern, um schnellere oder sogar sofortige Seitennavigationen zu ermöglichen.
Die API wurde speziell für eine einfache Implementierung entwickelt. Es gibt jedoch einige Aspekte, die insbesondere bei komplexen Websites vor der Verwendung berücksichtigt werden müssen. In diesem Leitfaden erfahren Websiteinhaber mehr dazu.
Planung
Bevor Sie Spekulationsregeln implementieren, sollten Sie überlegen, wie Sie die API implementieren möchten (es gibt mehrere Möglichkeiten) und welche Kosten mit Spekulationen verbunden sind. Diese Kosten sollten Ihnen als Orientierungshilfe dienen, für welche Seiten Sie Spekulationen durchführen.
Entscheiden, wie Spekulationsregeln implementiert werden sollen
Eine der ersten Entscheidungen, die Sie treffen müssen, ist, wie Sie Spekulationsregeln auf Ihrer Website implementieren. Dazu gibt es verschiedene Methoden:
- Direkt im HTML-Code der Seite
- JavaScript verwenden
- HTTP-Header verwenden
Letztendlich hat jede Methode denselben Effekt, aber es kann Vorteile hinsichtlich der einfachen Implementierung und Flexibilität geben.
Websites sollten die Option auswählen, die am besten zu ihnen passt. Bei Bedarf können sie auch eine Kombination dieser Optionen verwenden. Alternativ können sie auch über ein Plug-in (z. B. das Speculative Loading-Plug-in für WordPress) oder Bibliotheken oder Plattformen implementiert werden, die die Auswahl für Sie treffen. Es ist jedoch trotzdem sinnvoll, sich über die verfügbaren Optionen im Klaren zu sein.
Spekulationsregeln direkt in den HTML-Code der Seite einfügen
Spekulationsregeln können direkt auf der Seite implementiert werden, indem das <script type="speculationrules">-Element in den HTML-Code eingefügt wird. Sie kann entweder zur Build-Zeit 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 eingefügt werden. Die HTTP-Header-Methode, die später in diesem Leitfaden beschrieben wird, ist dafür jedoch wahrscheinlich einfacher.
So können Sie statische Regeln für die gesamte Website einfügen. Dokumentregeln können jedoch weiterhin dynamisch sein, da Sie die URLs auswählen können, die auf der Seite gerendert werden sollen. Dazu verwenden Sie Regeln, die durch CSS-Klassen ausgelöst werden:
<script type="speculationrules">
{
"prerender": [{
"where": { "selector_matches": ".prerender" }
}],
"prefetch": [{
"where": { "selector_matches": ".prefetch" }
}]
}
</script>
Das vorherige Skript rendert Links mit der Klasse prerender vor und ruft Links mit der Klasse prefetch vorab ab. So können Entwickler diese Klassen in den HTML-Code einfügen, um Spekulationen auszulösen.
Diese Klassen werden nicht nur in das ursprüngliche HTML einer Seite eingefügt, sondern auch dann, wenn sie von Ihrer App dynamisch hinzugefügt werden. So kann Ihre App Spekulationen nach Bedarf auslösen und entfernen. Das kann einfacher sein, als spezifischere Spekulationsregeln zu erstellen oder zu entfernen. Es ist auch möglich, mehrere Spekulationsregeln pro Seite einzufügen, wenn Sie eine Basisregel für den Großteil der Website und seitenbezogene Regeln verwenden möchten.
Wenn Sie spezifischere Spekulationsregeln verwenden müssen, können Sie mit seiten- oder vorlagenspezifischen Regeln unterschiedliche Regeln für bestimmte Seiten oder Seitentypen festlegen.
Außerdem können serverseitig gerenderte Seiten dynamischere Regeln haben, die auf den Informationen basieren, die dem Server zur Verfügung stehen, z. B. Analyseinformationen für die Seite oder häufige Nutzerpfade für bestimmte Seiten.
Spekulationsregeln mit JavaScript hinzufügen
Alternativ dazu, die Regeln in ein On-Page-Script einzufügen, können Sie sie mit JavaScript einfügen. Das kann dazu führen, dass weniger Aktualisierungen an Seitenvorlagen erforderlich sind. Wenn die Regeln beispielsweise von einem Tag-Management-System eingefügt werden, können Spekulationsregeln schnell eingeführt und bei Bedarf auch schnell deaktiviert werden.
Diese Option ermöglicht auch dynamische, clientseitige Regeln, die darauf basieren, wie der Nutzer mit der Seite interagiert. Wenn der Nutzer beispielsweise einen Artikel in den Warenkorb legt, können Sie die Checkout-Seite vorrendern. Alternativ kann dies verwendet werden, um Spekulationen auf der Grundlage bestimmter Bedingungen auszulösen. Die API enthält zwar eine Einstellung für die Eifrigkeit, die grundlegende interaktionsbasierte Regeln ermöglicht. Mit JavaScript können Entwickler jedoch ihre eigene Logik verwenden, um zu entscheiden, wann und auf welchen Seiten spekuliert werden soll.
Wie bereits erwähnt, können Sie neue Regeln auch einfügen, indem Sie eine Basisdokumentregel auf der Seite haben und JavaScript Dokumentregeln auslösen lassen, indem Sie Links entsprechende Klassen hinzufügen, sodass sie der Regel entsprechen.
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"
Es gibt einige zusätzliche Anforderungen hinsichtlich der Bereitstellung und Verwendung der Regelnressource (/speculationrules.json in diesem Beispiel).
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-Selektortriggern können jedoch weiterhin dynamische Änderungen zulassen, z. B. durch Entfernen der Klasse prerender aus einem Link.
Ähnlich wie bei der JavaScript-Option können Spekulationsregeln mit einem HTTP-Header unabhängig vom Inhalt der Website implementiert werden. Das kann das Hinzufügen und Entfernen der Regeln ohne vollständigen Website-Neubau erleichtern.
Kosten berücksichtigen
Bevor Sie Spekulationsregeln implementieren, sollten Sie sich etwas Zeit nehmen, um die Kosten für Ihre Nutzer und Ihre Website zu berücksichtigen, die mit dieser API verbunden sind. Die Kosten umfassen Bandbreite (die sowohl Nutzer als auch Websites Geld kostet) und Verarbeitungskosten (sowohl auf Client- als auch auf Serverseite).
Kosten für Nutzer berücksichtigen
Beim spekulativen Laden wird eine fundierte Vermutung darüber angestellt, wohin ein Nutzer als Nächstes navigieren könnte. Wenn diese Navigation jedoch nicht erfolgt, haben Sie möglicherweise Ressourcen verschwendet. Deshalb sollten Sie sich der Auswirkungen auf die Nutzer bewusst sein, insbesondere:
- Zusätzliche Bandbreite, die zum Herunterladen dieser zukünftigen Navigation verwendet wird, insbesondere auf Mobilgeräten, wo die Bandbreite möglicherweise eingeschränkter ist.
- Zusätzliche Verarbeitungskosten für das Rendern dieser Seiten bei Verwendung von Prerendering.
Bei absolut genauen Vorhersagen fallen keine zusätzlichen Kosten an, da Besucher diese Seiten ohnehin als Nächstes aufrufen. Der einzige Unterschied besteht darin, dass die Kosten im Voraus anfallen. Es ist jedoch unmöglich, die Zukunft mit vollständiger Genauigkeit vorherzusagen. Je aggressiver die Spekulationsstrategie, desto höher das Risiko von Verschwendung.
Chrome hat dieses Problem sorgfältig geprüft und die API enthält eine Reihe von Funktionen, die die Kosten viel niedriger machen, als Sie vielleicht denken. Insbesondere durch die Wiederverwendung des HTTP-Cache und das Nichtladen von ursprungsübergreifenden iFrames sind die Kosten für das Vorrendern einer Navigation auf derselben Website oft erheblich geringer als für eine vollständige Seite ohne im Cache gespeicherte Ressourcen. Spekulative Ladevorgänge sind also weniger kostspielig als angenommen.
Trotz dieser Schutzmaßnahmen sollten Websites sorgfältig abwägen, auf welchen Seiten sie spekulieren, und die Kosten für die Nutzer berücksichtigen. Gute Kandidaten für das spekulative Laden sind Seiten, die mit hoher Wahrscheinlichkeit vorhergesagt werden können (z. B. basierend auf Analysen oder gängigen Nutzerpfaden) 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, bis sie benötigt werden, kann dies die Vorabrenderung günstiger machen und gleichzeitig die Nutzerfreundlichkeit deutlich verbessern. Bei günstigeren Spekulationen fühlen Sie sich möglicherweise wohler, wenn Sie häufiger oder eifriger spekulieren.
Ist dies nicht möglich, empfiehlt sich eine weniger aggressive Strategie mit moderaten oder konservativen Regeln für die Eifrigkeit. Alternativ können Sie Prefetch verwenden, das bei geringer Wahrscheinlichkeit deutlich weniger kostet als Prerendering. Wenn die Wahrscheinlichkeit steigt, können Sie dann auf ein vollständiges Prerendering umstellen, z. B. wenn ein Link mit dem Mauszeiger berührt oder tatsächlich angeklickt wird.
Zusätzliche Back-End-Last berücksichtigen
Neben den zusätzlichen Kosten für den Nutzer sollten Websiteinhaber auch ihre eigenen Infrastrukturkosten berücksichtigen. Wenn jede Seite zwei, drei oder noch mehr Seitenaufrufe zur Folge hat, können die Backend-Kosten durch die Verwendung dieser API steigen.
Wenn Sie dafür sorgen, dass Ihre Seiten und Ressourcen im Cache gespeichert werden können, wird die Last auf den Ursprungsserver deutlich reduziert und damit auch das Gesamtrisiko. In Verbindung mit einem CDN sollte die zusätzliche Last auf Ihren Ursprungsservern minimal sein. Berücksichtigen Sie jedoch mögliche CDN-Kostensteigerungen.
Ein Server oder CDN kann auch verwendet werden, um die Spekulationsergebnisse zu steuern, die durch den HTTP-Header „sec-purpose“ identifiziert werden. Mit Cloudflares Speed Brain-Produkt sind beispielsweise nur Spekulationen möglich, die bereits auf einem CDN-Edge-Server im Cache gespeichert sind. Anfragen werden nicht an den Ursprung zurückgesendet.
Da spekulative Ladevorgänge jedoch in der Regel für Seitenladevorgänge mit demselben Ursprung verwendet werden, haben Nutzer bereits freigegebene Ressourcen im Cache ihres Browsers – vorausgesetzt, sie sind überhaupt cachefähig. Daher ist eine Spekulation in der Regel nicht so kostspielig wie ein vollständiger Seitenladevorgang.
Das richtige Maß an Spekulation finden
Der Schlüssel zur optimalen Nutzung der Speculation Rules API liegt darin, das richtige Gleichgewicht zwischen zu viel und zu wenig Spekulieren zu finden. Bei zu viel Spekulieren werden die Kosten unnötig bezahlt und die Spekulation wird nicht genutzt. Bei zu wenig Spekulieren wird entweder zu wenig oder zu spät spekuliert, sodass nur ein geringer Nutzen erzielt wird.
Wenn die Kosten niedrig sind (z. B. bei kleinen, statisch generierten Seiten, die auf CDN-Edge-Knoten im Cache gespeichert werden), können Sie aggressiver spekulieren.
Bei größeren, komplexeren Seiten, die möglicherweise nicht am CDN-Edge-Standort im Cache gespeichert werden können, ist jedoch mehr Vorsicht geboten. Ebenso können ressourcenintensive Seiten Netzwerkbandbreite oder Rechenleistung beanspruchen, was sich negativ auf die aktuelle Seite auswirken kann. Ziel der API ist es, die Leistung zu verbessern. Leistungsbeeinträchtigungen sind daher unerwünscht. Dies ist ein weiterer Grund, die Anzahl der Vorrenderings auf maximal ein oder zwei Seiten zu beschränken. Chrome begrenzt die Anzahl der Vorrenderings je nach Eagerness auf zwei oder zehn.
So implementieren Sie Spekulationsregeln
Nachdem Sie entschieden haben, wie Sie Spekulationsregeln implementieren möchten, müssen Sie planen, was Sie spekulieren und wie Sie dies umsetzen. Bei einfacheren Websites wie statischen persönlichen Blogs kann möglicherweise direkt mit dem vollständigen Prerendering bestimmter Seiten begonnen werden. Bei komplexeren Websites sind jedoch zusätzliche Aspekte zu berücksichtigen.
Mit Prefetch beginnen
Prefetch ist in der Regel relativ sicher für die meisten Websites und ist der erste Ansatz, der von vielen verwendet wird, einschließlich groß angelegter Rollouts wie Cloudflare und WordPress.
Die wichtigsten Probleme, die Sie beachten sollten, sind, ob das Prefetching einer URL zu Zustandsänderungen und serverseitigen Kosten führt, insbesondere bei nicht cachefähigen Seiten. Idealerweise sollten Zustandsänderungen, z. B. das Vorabrufen einer /logout-Seite, nicht als GET-Links implementiert werden. Das ist im Web aber leider nicht unüblich.
Solche URLs können explizit von den Regeln ausgeschlossen werden:
<script type="speculationrules">
{
"prefetch": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Prefetches können auf allgemeine Navigationsvorgänge von einer Seite zur anderen oder für alle Links mit derselben Herkunft beim Hovern oder Klicken mit der Einstellung moderate oder conservative eagerness beschränkt werden. Die Einstellung conservative birgt das geringste Risiko, aber auch das geringste potenzielle Ergebnis. Wenn Sie damit beginnen, sollten Sie mindestens auf moderate umstellen. Noch besser ist es, wenn Sie auf eager umstellen, da dies zu einer höheren Leistung führt. Wenn es sinnvoll ist, können Sie dann auf prerender umstellen.
Vorrenderings mit geringem Risiko
Prefetch-Spekulationen lassen sich einfacher bereitstellen, aber die ultimative Leistungssteigerung der API wird durch Prerender erzielt. Das kann einige zusätzliche Überlegungen erfordern, wenn die Seite nicht kurz nach der Spekulation aufgerufen wird (was wir im nächsten Abschnitt behandeln). Bei einem moderate- oder conservative-Prerender, bei dem die Navigation wahrscheinlich kurz danach erfolgt, ist dies jedoch ein relativ risikoarmer nächster Schritt.
<script type="speculationrules">
{
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Häufig verwendete Seiten vorab abrufen, um nicht verzögerte Vorabrenderings zu verbessern
Eine gängige Taktik besteht darin, beim Laden mit der Einstellung eager eine kleinere Anzahl häufig besuchter nächster Seiten vorab abzurufen (entweder durch Angabe in einer URL-Liste oder mit selector_matches) und dann mit der Einstellung moderate vorab zu rendern. Da das HTML-Prefetching wahrscheinlich abgeschlossen ist, wenn der Mauszeiger auf den Link bewegt wird, ist das ein Vorteil gegenüber dem reinen Vorrendern bei Hovering 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 Vorrenderings
Die Regeln für das moderate-Dokument ermöglichen zwar eine relativ risikoarme Verwendung der API und eine einfache Implementierung, aber oft reicht die Zeit nicht für ein vollständiges Prerendering. Um die sofortigen Navigationsvorgänge zu ermöglichen, die diese API bietet, müssen Sie wahrscheinlich mehr Seiten vorrendern.
Dies wird entweder mit einer statischen Liste von URLs (wie im vorherigen Beispiel für das Prefetching) oder mit selector_matches erreicht, um eine kleine Anzahl von URLs (idealerweise ein 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 Verkehrsanalyse erforderlich, um die nächste Navigation möglichst genau vorherzusagen. Wenn Sie die typischen Kaufprozesse auf Ihrer Website kennen, können Sie auch gute Kandidaten für das spekulative Laden identifizieren.
Die Umstellung auf ein aggressiveres Vorrendering kann auch zu weiteren Überlegungen zu Analytics, Anzeigen und JavaScript führen. Außerdem muss eine vorgerenderte Seite auf dem neuesten Stand gehalten werden. Bei Zustandsänderungen müssen möglicherweise sogar Spekulationen abgebrochen oder aktualisiert werden.
Analytics, Werbung und JavaScript
Bei komplexeren Websites muss bei der Verwendung von Prerendering auch die Auswirkung auf die Analyse berücksichtigt werden. Normalerweise sollten Sie einen Seiten- oder Anzeigenaufruf nicht protokollieren, wenn die Seite nur spekulativ aufgerufen wird, sondern erst, wenn die Spekulation aktiviert wird.
Einige Analyseanbieter (z. B. Google Analytics) und Anzeigenanbieter (z. B. Google Publisher Tag) unterstützen bereits Spekulationsregeln und protokollieren Aufrufe erst, wenn die Seite aktiviert wird. Bei anderen Anbietern oder benutzerdefinierten Analysen, die Sie implementiert haben, sind jedoch möglicherweise zusätzliche Maßnahmen erforderlich.
Sie können JavaScript-Prüfungen hinzufügen, um die Ausführung bestimmter Codeabschnitte zu verhindern, bis Seiten aktiviert oder sichtbar gemacht werden. Sie können sogar ganze <script>-Elemente in solche Prüfungen einbetten. Wenn auf Seiten Tag-Manager verwendet werden, um solche Skripts einzufügen, können Sie das Problem möglicherweise auf einmal beheben, indem Sie das Tag-Manager-Skript selbst verzögern.
Einwilligungsmanager bieten eine ähnliche Möglichkeit, Drittanbieter-Scripts bis zur Aktivierung zu verzögern. Google hat mit verschiedenen Plattformen für Einwilligungsmanager zusammengearbeitet, um sie für das Vorrendern zu optimieren. Wir helfen auch anderen gern dabei, das Gleiche zu tun. PubTech ist ein solches Unternehmen, das Entwicklern die Möglichkeit bietet, sein 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 von Code bis zur Aktivierung zu verzögern, insbesondere wenn die Seite den JavaScript-Code nicht zum Rendern benötigt. Das ist eine schnellere und sicherere Option, aber der gesamte Code wird bei der Aktivierung gleichzeitig ausgeführt. Das kann bei der Aktivierung zu viel Arbeit führen, was sich auf INP auswirken kann, insbesondere da die Seite möglicherweise vollständig geladen und bereit für die Interaktion aussieht.
Wenn Inhalte von JavaScript abhängen (z. B. clientseitig gerenderte Inhalte), wird durch das Verzögern die positive Auswirkung des Prerenderings auf LCP und CLS verringert. Ein gezielterer Ansatz, bei dem mehr JavaScript während der Vorrenderungsphase ausgeführt wird, führt zu einer besseren Nutzererfahrung, ist aber möglicherweise schwieriger zu implementieren.
Bei komplexeren Websites kann es sinnvoll sein, viele Script-Tags erst einmal zu verzögern. Um die API jedoch optimal zu nutzen, sollte so viel JavaScript wie möglich während des Prerenderings ausgeführt werden.
Bei Websites mit Analyse- oder Anzeigenproblemen kann es sinnvoll sein, mit dem Prefetching zu beginnen, da diese Probleme hier weniger relevant sind. In der Zwischenzeit kann überlegt werden, was für die Unterstützung des Prerenderings erforderlich ist.
Vorrenderungsspekulationen aktualisieren
Wenn Seiten vorab gerendert werden, besteht das Risiko, dass die vorab gerenderte Seite veraltet ist. Auf einer vorgerenderten Seite einer E-Commerce-Website kann beispielsweise ein Einkaufswagen angezeigt werden – entweder mit allen Artikeln oder nur mit einem Zähler, der die Anzahl der Artikel im Einkaufswagen auf anderen Seiten angibt. Wenn einem Warenkorb weitere Artikel hinzugefügt werden und dann eine vorgerenderte Seite aufgerufen wird, wäre es für den Nutzer verwirrend, den alten Checkout-Status zu sehen.
Das ist kein neues Problem. Nutzer, die mehrere Tabs im Browser geöffnet haben, haben dasselbe Problem. Bei vorgerenderten Seiten ist dies jedoch wahrscheinlicher und unerwarteter, da der Nutzer das Vorrendern nicht bewusst initiiert hat.
Die Broadcast Channel API ist eine Möglichkeit, einer Seite im Browser zu erlauben, solche Updates an andere Seiten zu senden. Dadurch würde auch das Problem mit mehreren Tabs behoben. Auf vorgerenderte Seiten kann auf Broadcast-Nachrichten gewartet werden. Eigene Broadcast-Nachrichten können jedoch erst gesendet werden, wenn die Seite aktiviert ist.
Alternativ können vorgerenderte Seiten über den Server aktualisiert werden (mit einem regelmäßigen fetch() oder einer WebSocket-Verbindung), aber mit potenziellen Verzögerungen bei den Aktualisierungen.
Vorabrendern abbrechen oder aktualisieren
Das Aktualisieren vorab gerenderter Seiten ist die empfohlene Vorgehensweise, um weiterhin vorab gerenderte Seiten zu verwenden und gleichzeitig Verwirrung bei den Nutzern zu vermeiden. Wenn dies nicht möglich ist, können Sie Spekulationen stornieren.
So können auch die Grenzwerte von Chrome eingehalten werden, wenn Websites andere Seiten vorrendern möchten, die mit höherer Wahrscheinlichkeit besucht werden.
Wenn Sie Spekulationen abbrechen möchten, müssen Sie die Spekulationsregeln von der Seite entfernen oder Klassen oder andere übereinstimmende Kriterien entfernen, wenn Sie diesen Ansatz verwenden. Alternativ kann die spekulierte Seite window.close() aufrufen, wenn sie feststellt, dass sie nicht mehr aktuell ist. Wenn die Seite dies jedoch erkennen kann, wäre es besser, ihren Status zu aktualisieren, um sie wieder auf den neuesten Stand zu bringen.
Es ist auch möglich, diese Regeln (oder Abgleichskriterien) wieder einzufügen, damit Seiten noch einmal vorgerendert werden können. Allerdings ist es in der Regel besser, eine vorhandene Seite auf dem neuesten Stand zu halten, da dies weniger Ressourcen verbraucht. Nachdem die Spekulationsregeln entfernt wurden, muss das erneute Einfügen in einer neuen Mikroaufgabe oder später erfolgen, damit der Browser die Entfernungen bemerkt und die Spekulationen abbrechen kann. Im folgenden Beispiel wird gezeigt, wie Sie alle Spekulationsregelskripts löschen und entfernen:
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 Pretender (oder Prefetchs) abgebrochen. Wenn Sie die Regeln wieder einfügen, werden nur sofortige oder eifrige Regeln spekuliert, einschließlich URL-Listenregeln mit dem Standardwert „immediate“. Moderate oder konservative Spekulationen werden jedoch entfernt, aber erst dann wieder automatisch ausgelöst, wenn der Nutzer noch einmal mit dem Link interagiert.
Diese Aktualisierungsoption ist nicht auf Regeln beschränkt, die über JavaScript eingefügt werden. Statische Regeln im HTML-Code können auf dieselbe Weise entfernt oder geändert werden, da es sich um eine Standard-DOM-Änderung handelt. HTTP-Spekulationsregeln können nicht entfernt werden, aber übereinstimmende Kriterien (z. B. prerender-Klassen) können entfernt und mit JavaScript wieder hinzugefügt werden.
Chrome prüft auch, ob Clear-Site-Header hinzugefügt werden sollen, damit Serverantworten Vorabrenderings abbrechen können (z. B. wenn eine Anfrage zum Aktualisieren des Warenkorbs gestellt wird).
Wirkung messen
Nach der Implementierung von Spekulationsregeln sollten Sie den Erfolg messen und nicht einfach davon ausgehen, dass die Website automatisch schneller ist. Wie bereits erwähnt, kann eine zu starke Spekulation zu Leistungseinbußen führen, wenn der Client oder Server überlastet ist.
Wenn Sie die Implementierung in mehreren Schritten vornehmen (Prefetch, Prerender mit geringem Risiko und dann Early Prerender), sollten Sie jeden Schritt messen.
Erfolg messen
Spekulationsregeln sollten sich positiv auf wichtige Leistungsmesswerte wie LCP (und möglicherweise auch auf CLS und INP) auswirken. Dies ist jedoch möglicherweise nicht in den Messwerten auf Websiteebene zu sehen. Das liegt daran, dass Websites möglicherweise hauptsächlich aus anderen Navigationstypen (z. B. Landingpages) bestehen oder Navigationen mit demselben Ursprung bereits schnell genug sind, sodass selbst eine drastische Verbesserung sich nicht auf die Messwerte des 75. Perzentils auswirkt, die im Bericht zur Nutzererfahrung in Chrome (Chrome User Experience, CrUX) angegeben sind.
Mit den Seitennavigationstypen in CrUX können Sie prüfen, welcher Prozentsatz der Navigationen navigate_cache oder prerender ist und ob dieser Prozentsatz im Laufe der Zeit zunimmt. Für eine detaillierte Analyse müssen Sie jedoch möglicherweise Real User Monitoring verwenden, um Ihre Daten in mutmaßliche Navigationsvorgänge zu segmentieren und zu sehen, wie viel schneller sie als andere Navigationsvorgänge sind.
Nutzung und Verschwendung messen
Ein weiterer wichtiger Aspekt ist, zu prüfen, ob Sie auf den richtigen Seiten spekulieren. So vermeiden Sie Verschwendung und können die besten Seiten für diese API auswählen.
Leider kann die Seite, auf der die Spekulationen initiiert werden, den Status der Spekulationsversuche nicht direkt sehen. Außerdem kann nicht davon ausgegangen werden, dass Versuche ausgelöst wurden, da der Browser Spekulationen unter bestimmten Umständen zurückhalten kann. Sie müssen daher auf der Seite selbst gemessen werden. Dazu müssen auch 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");
}
Auf dieser Seite kann der Spekulationsversuch dann auf Backend-Servern protokolliert werden.
Ein Problem bei der Analyse ist, dass Anbieter wie Google Analytics das Vorrendern berücksichtigen und Analyseaufrufe erst dann ausführen, wenn die Seite aktiviert wird – auch separate Ereignisaufrufe. Google Analytics-Nutzer müssen daher eine andere serverseitige Logging-Option verwenden.
Das ist auch clientseitig möglich. Dabei wird der Prerender für jede prerenderte Seite im freigegebenen Speicher protokolliert und die aufrufende Seite liest diese Daten. localStorage funktioniert am besten, da es beim Verlassen einer Seite gelesen werden kann. sessionStorage kann nicht verwendet werden, da es eine spezielle Verarbeitung für vorgerenderte Seiten hat. Beachten Sie jedoch, dass localStorage nicht transaktionssicher ist und andere Seiten den Wert gleichzeitig aktualisieren können, wenn mehrere Seiten vorgerendert werden. In dieser Demo werden ein eindeutiger Hash und einzelne Einträge verwendet, um Probleme zu vermeiden.
Fazit
Mit Spekulationsregeln lässt sich die Leistung Ihrer Seite erheblich steigern. In diesem Leitfaden finden Sie Hinweise zur Implementierung dieser API, um potenzielle Probleme zu vermeiden und die API optimal zu nutzen.
Wenn Sie die Implementierung im Voraus planen, können Sie Nacharbeiten vermeiden. Insbesondere bei komplexeren Websites sollte ein mehrstufiger Roll-out erfolgen, der mit Prefetch beginnt, bevor zu Prerender mit geringem Risiko und dann zu Early Prerender übergegangen wird. Schließlich ist es wichtig, die Verbesserungen sowie die Nutzung und den Ressourcenverbrauch zu messen, um die Verwendung dieser API zu optimieren.