Das Chrome-Team hat an einigen spannenden Updates für die Speculation Rules API gearbeitet, mit denen zukünftige Navigationen vorab abgerufen oder sogar vorab gerendert werden können, um die Navigationsleistung zu verbessern. Diese zusätzlichen Verbesserungen sind jetzt alle in Chrome 122 verfügbar. Einige Funktionen früherer Versionen sind ebenfalls verfügbar.
Durch diese Änderungen wird das Vorabrufen und Pre-Rendering von Seiten erheblich einfacher und weniger Verschwendung. Wir hoffen, dass dies zu einer weiteren Akzeptanz führen wird.
Zusätzliche Funktionen
Zunächst erklären wir die Neuerungen, die wir der Speculation Rules API hinzugefügt haben, und ihre Verwendung. Anschließend zeigen wir dir eine Demo, um sie in Aktion zu sehen.
Dokumentregeln
Früher gab die Speculation Rules API eine Liste von URLs zum Vorabruf oder Pre-Rendering an:
<script type="speculationrules">
{
"prerender": [
{
"source": "list",
"urls": ["next.html", "next2.html"]
}
]
}
</script>
Die Spekulationsregeln waren semidynamisch, da neue Skripts für Spekulationsregeln hinzugefügt und alte Skripts entfernt werden konnten, um diese Spekulationen zu verwerfen. Beachten Sie, dass das Aktualisieren der urls
-Liste eines vorhandenen Spekulationsregeln keine Änderung der Spekulationen auslöst. Die Auswahl der URLs blieb jedoch der Website überlassen, entweder indem sie zum Zeitpunkt der Seitenanforderung vom Server gesendet wurden oder indem diese Liste dynamisch über clientseitiges JavaScript erstellt wurde.
Listenregeln sind weiterhin eine Option für einfachere Anwendungsfälle, bei denen die nächste Navigation aus einer kleinen Gruppe offensichtlicher erfolgt, oder für komplexere Anwendungsfälle, bei denen die Liste der URLs auf der Grundlage der Heuristik, die der Websiteinhaber verwenden möchte, dynamisch berechnet und dann in die Seite eingefügt wird.
Als Alternative freuen wir uns, Ihnen eine neue Option für die automatische Linksuche mit Dokumentregeln anbieten zu können. Dabei werden URLs aus dem Dokument selbst anhand einer where
-Bedingung abgerufen. Dies kann auf den Links selbst basieren:
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout/*"}}
]
},
"eagerness": "moderate"
}]
}
</script>
CSS-Selektoren können auch als Alternative oder in Verbindung mit href-Übereinstimmungen verwendet werden, um Links auf der aktuellen Seite zu finden:
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": {
"and": [
{ "selector_matches": ".prerender" },
{ "not": {"selector_matches": ".do-not-prerender"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Auf diese Weise kann für die gesamte Website ein einziger Spekulationsregelsatz verwendet werden, anstatt einen bestimmten für jede Seite zu verwenden. Dadurch ist es für Websites viel einfacher, Spekulationsregeln anzuwenden.
Das Pre-Rendering aller Links auf einer Seite wäre natürlich Verschwendung. Mit dieser neuen Funktion haben wir deshalb eine eagerness
-Einstellung eingeführt.
Eifer
Bei jeder Art von Spekulation gibt es einen Kompromiss zwischen Precision und Recall sowie der Vorlaufzeit. Wenn Sie alle Links beim Seitenaufbau vorab rendern, wird ein Link, auf den ein Nutzer klickt (vorausgesetzt, er klickt auf einen Link zur selben Website), höchstwahrscheinlich vorab gerendert, und zwar mit so viel Vorlaufzeit wie möglich, aber mit einer potenziell großen Bandbreitenverschwendung.
Das Pre-Rendering hingegen nur, wenn ein Nutzer auf einen Link geklickt hat, verhindert Verschwendung, allerdings auf Kosten einer deutlich kürzeren Vorlaufzeit. Daher ist es unwahrscheinlich, dass das Pre-Rendering abgeschlossen ist, bevor der Browser zu dieser Seite wechselt.
Mit der Einstellung eagerness
können Sie festlegen, wann Spekulationen ausgeführt werden sollen. Dabei wird der Zeitpunkt getrennt, von denen spekuliert werden soll, für welche URLs Spekulationen durchgeführt werden sollen. Die Einstellung eagerness
ist sowohl für die Quellregeln list
als auch für document
verfügbar und hat vier Einstellungen, für die Chrome folgende Heuristiken verwendet:
immediate
:Wird verwendet, um so schnell wie möglich zu spekulieren, d. h. sobald die Spekulationsregeln eingehalten werden.eager
:Derzeit entspricht dies derimmediate
-Einstellung, wir planen jedoch, sie in Zukunft irgendwo zwischenimmediate
undmoderate
zu platzieren.moderate
:Diese Funktion führt zu Spekulationen, wenn du den Mauszeiger 200 Millisekunden lang auf einen Link bewegst (oder auf das Ereignispointerdown
, wenn das früher schon einmal war, und auf Mobilgeräten, wo keinhover
-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 sehr einfachen 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 einfachen Spekulationsregel profitieren, bei der alle Links vorab gerendert werden, wenn der Mauszeiger darauf bewegt wird, und dass sie eine einfache und dennoch leistungsstarke Implementierung von Spekulationsregeln darstellt:
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": {
"href_matches": "/*"
},
"eagerness": "moderate"
}]
}
</script>
Chrome-Limits
Auch wenn du eagerness
auswählst, gibt es in Chrome Einschränkungen, um eine übermäßige Nutzung dieser API zu verhindern:
eagerness |
Vorabruf | Vorab rendern |
---|---|---|
immediate /eager |
50 | 10 |
moderate /conservative |
2 (FIFO) | 2 (FIFO) |
Die Einstellungen moderate
und conservative
, die von der Nutzerinteraktion abhängen, entsprechen dem FIFO-Prinzip (First In, First Out). Nachdem das Limit erreicht ist, führt eine neue Spekulation dazu, dass die älteste Spekulation abgebrochen und durch die neue ersetzt wird, um Arbeitsspeicher zu sparen.
Die Tatsache, dass die moderate
- und conservative
-Spekulationen von Nutzern ausgelöst werden, ermöglicht es uns, einen niedrigeren Schwellenwert von 2 zu verwenden, um Arbeitsspeicher zu sparen. Die Einstellungen für immediate
und eager
werden nicht durch eine Nutzeraktion ausgelöst und haben daher ein höheres Limit, da der Browser nicht wissen kann, welche und wann sie benötigt werden.
Eine Spekulation, die dadurch abgebrochen wird, dass sie aus der FIFO-Warteschlange geschoben wird, kann erneut ausgelöst werden, z. B. durch erneutes Bewegen des Mauszeigers über diesen Link. Dies führt dazu, dass die URL neu spekuliert wird. In diesem Fall hat die vorherige Spekulation wahrscheinlich dazu geführt, dass der Browser einige Ressourcen im HTTP-Cache für diese URL zwischengespeichert hat. Eine Wiederholung der Spekulation sollte daher das Netzwerk und den Zeitaufwand erheblich reduzieren.
Die Limits für immediate
und eager
sind ebenfalls dynamisch. Wenn Sie ein Skriptelement für Spekulationsregeln mit diesen Präferenzen entfernen, werden die entfernten Spekulationen abgebrochen, um Kapazität zu schaffen. Diese URLs können auch neu spekuliert werden, wenn sie in ein neues URL-Skript aufgenommen werden und das Limit noch nicht erreicht wurde.
Chrome verhindert außerdem, dass Spekulationen unter bestimmten Bedingungen verwendet werden:
- Daten speichern.
- Energiesparmodus.
- Arbeitsspeichereinschränkungen.
- Wenn der Bereich „Seiten vorab laden“ deaktiviert ist (wird auch durch Chrome-Erweiterungen wie uBlock Origin explizit deaktiviert).
- In Tabs im Hintergrund geöffnete Seiten.
All diese Bedingungen zielen darauf ab, die Auswirkungen übermäßiger Spekulationen zu reduzieren, wenn diese für Nutzer schädlich sein könnten.
Optional: source
In Chrome 122 ist der Schlüssel source
optional, da dieser aus dem Vorhandensein der Schlüssel url
oder where
abgeleitet werden kann. Diese beiden Spekulationsregeln sind daher identisch:
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": { "href_matches": "/*" },
"eagerness": "moderate"
}]
}
</script>
<script type="speculationrules">
{
"prerender": [{
"where": { "href_matches": "/*" },
"eagerness": "moderate"
}]
}
</script>
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 mit den Spekulationsregeln. Dies ist besonders nützlich, wenn Sie einige oder alle Links mit demselben Ursprung auswählen müssen.
Bessere Cache-Wiederverwendung
Wir haben eine Reihe von Verbesserungen am Caching in Chrome vorgenommen, sodass beim Vorabrufen (oder sogar beim Pre-Rendering) eines Dokuments Ressourcen im HTTP-Cache gespeichert und wiederverwendet werden können. Das bedeutet, dass Spekulationen auch in Zukunft Vorteile haben können, wenn sie nicht verwendet werden.
Dies macht auch eine erneute Spekulation (z. B. bei Dokumentregeln mit der Eagerität-Einstellung moderate
) erheblich günstiger, da Chrome den HTTP-Cache für im Cache speicherbare Ressourcen verwendet.
Wir unterstützen auch das neue No-Vary-Search
-Angebot, um die Wiederverwendung von Cache weiter zu verbessern.
No-Vary-Search
-Support
Beim Vorabruf oder Pre-Rendering einer Seite sind bestimmte URL-Parameter (auch Suchparameter genannt) möglicherweise unwichtig für die Seite, die tatsächlich vom Server bereitgestellt wird. Sie werden nur von clientseitigem JavaScript verwendet.
UTM-Parameter werden in Google Analytics beispielsweise zur Kampagnenanalyse verwendet, führen aber normalerweise nicht dazu, dass verschiedene Seiten vom Server ausgeliefert werden. Das bedeutet, dass page1.html?utm_content=123
und page1.html?utm_content=456
dieselbe Seite vom Server bereitstellen, sodass dieselbe Seite aus dem Cache wiederverwendet werden kann.
Ebenso können Anwendungen andere URL-Parameter verwenden, die nur clientseitig verarbeitet werden.
Mit dem Vorschlag No-Vary-Search 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. Hinweis: Dies wird derzeit nur in Chrome (und Chromium-basierten Browsern) für Spekulationen zur Prefetch-Navigation unterstützt.
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.
Demo
Wir haben unter https://speculative-rules.glitch.me/common-fruits.html eine Demo erstellt, in der Sie Dokumentregeln mit der Einstellung moderate
„Eagerness“ in Aktion sehen können:
![Screenshot einer Demowebsite, die in einem Glitch erstellt wurde und eine Reihe von Links mit Früchten enthält Die Entwicklertools sind geöffnet und es wird angezeigt, dass zwei der Links (apple.html und orange.html) bereits vorab gerendert wurden.](https://developer.chrome.google.cn/static/blog/speculation-rules-improvements/images/speculation-rules-demo.png?authuser=0000&hl=de)
Öffnen Sie die Entwicklertools und klicken Sie auf das Steuerfeld Anwendung. Klicken Sie dann im Abschnitt Hintergrunddienste auf Spekulative Ladevorgänge und dann auf den Bereich Spekulationen. Sortieren Sie dann nach der Spalte Status.
Wenn Sie den Mauszeiger über die Früchte bewegen, sehen Sie, wie die Seiten vorab gerendert werden. Wenn Sie darauf klicken, wird eine viel schnellere LCP-Zeit angezeigt als eines der Schemas, die nicht vorab gerendert wurden. Diese Demo wird auch im folgenden Video erläutert:
Weitere Informationen zur Verwendung der Entwicklertools zur Fehlerbehebung bei Spekulationsregeln finden Sie im vorherigen Blogpost zum Debuggen von Spekulationsregeln.
Plattformunterstützung für Spekulationsregeln
Spekulationsregeln lassen sich durch Einschleusen in ein <script type="speculationrules">
-Element relativ einfach implementieren. Dank der Plattformunterstützung ist das aber mit nur einem Klick ein Kinderspiel. Wir haben mit verschiedenen Plattformen und Partnern zusammengearbeitet, um die Einführung von Spekulationsregeln zu vereinfachen.
Wir arbeiten außerdem intensiv an einer Standardisierung der API über die Web Incubator Community Group (WICG), damit auch andere Browser die API implementieren können.
WordPress
Das WordPress Core Performance-Team (einschließlich der Entwickler von Google) hat ein Plug-in für Spekulationsregeln erstellt. Mit diesem Plug-in können Sie jeder WordPress-Website mit nur einem Klick die Unterstützung von Dokumentregeln hinzufügen. Dieses Plug-in kann auch über das WordPress Performance Lab-Plug-in installiert werden, das Sie auch installieren sollten, da es Sie über verwandte Leistungs-Plug-ins des Teams auf dem Laufenden hält.
Es sind zwei Gruppen von Einstellungen verfügbar: der Spekulationsmodus und die Einstellung Eagerness:
<ph type="x-smartling-placeholder">![Screenshot eines Lesebereichs für WordPress-Einstellungen mit Einstellungen für Spekulationsregeln Es gibt zwei Optionen: den Spekulationsmodus mit der Option „Vorabruf“ oder „Pre-Rendering“ und die Einstellung „Eagerness“ mit den Einstellungen „Konservativ“, „Moderat“ oder „Eager“.](https://developer.chrome.google.cn/static/blog/speculation-rules-improvements/images/wordpress-speculation-rules.png?authuser=0000&hl=de)
Informationen zu komplizierteren Einrichtungen, z. B. wenn Sie bestimmte URLs vom Prefetch oder dem Pre-Rendering ausschließen möchten, finden Sie in der Dokumentation.
Akamai
Akamai ist einer der weltweit führenden CDN-Provider und testet die Speculation Rules API bereits seit einiger Zeit aktiv. Akamai hat eine Dokumentation veröffentlicht, in der erklärt wird, wie Kunden diese API in ihren CDN-Einstellungen aktivieren können. Auch die beeindruckenden Ergebnisse, die mit dieser neuen API möglich sind, wurden bereits bekannt gegeben.
NitroPack
NitroPack ist eine Lösung zur Leistungsoptimierung, die mithilfe der benutzerdefinierten Navigation AI prognostiziert, welche Seiten den Spekulationsregeln hinzugefügt werden sollen. Dadurch wird eine längere Vorlaufzeit erreicht, als wenn der Mauszeiger auf einen Link bewegt wird, ohne unnötige Spekulationen über alle beobachteten Links zu verschwenden. Weitere Informationen finden Sie in der Dokumentation zur Nitropack Speculation Rules API. Diese innovative Lösung zeigt, dass die älteren Listenregeln in Kombination mit websitespezifischen Statistiken noch ausreichend sind.
Das Chrome-Team hat außerdem zusammen mit NitroPack an einem Webinar für die Speculation Rules API gearbeitet. Dieses Webinar richtet sich an alle, die sich näher informieren möchten. Dazu gehört auch eine gute Diskussion über die Überlegungen zwischen früh und häufig sowie spät und weniger häufig.
Astro
Astro hat in Version 4.2 auf experimenteller Basis Pre-Rendering-Seiten mit der Speculation Rules API hinzugefügt. Entwickler, die Astro verwenden, können diese Funktion jetzt ganz einfach aktivieren. Für Browser, die die Speculation Rules API nicht unterstützen, wird ein Standard-Prefetch verwendet. Weitere Informationen finden Sie in der Dokumentation zum Pre-Rendering für Clients.
Fazit
Diese Ergänzungen des Speculation Rules API ermöglichen eine viel einfachere Verwendung dieser spannenden neuen Leistungsfunktion für Websites mit einem geringeren Risiko, Ressourcen durch ungenutzte Spekulationen zu verschwenden. Es ist toll, dass Plattformen diese API bereits nutzen. Wir hoffen, dass wir diese API 2024 allgemein einsetzen und dadurch letztendlich die Leistung für Endnutzer verbessern können.
Zusätzlich zu den Leistungsverbesserungen, die die Speculation Rules API bietet, sind wir gespannt, welche neuen Möglichkeiten sich dadurch eröffnen. Übergänge ansehen ist eine neue API, mit der Entwickler Übergänge zwischen Navigationen einfacher festlegen können. Diese Funktion ist derzeit für Single-Page-Anwendungen (SPAs) verfügbar. Die mehrseitige Version befindet sich in der Entwicklung und ist in Chrome über eine entsprechende Kennzeichnung verfügbar. Pre-Rendering ist eine natürliche Ergänzung dieser Funktion, um sicherzustellen, dass es nicht zu Verzögerungen kommt, die sonst die Nutzerfreundlichkeit verhindern würden, die durch den Übergang ermöglicht werden soll. Wir haben bereits Websites gesehen, auf denen diese Kombination getestet wird.
Wir freuen uns auf die weitere Einführung der Speculation Rules API im Laufe des Jahres 2024 und halten Sie über weitere Verbesserungen auf dem Laufenden.
Danksagungen
Thumbnail von Robbie Down auf Unsplash