Das Chrome-Team hat an einigen spannenden Updates für die Speculation Rules API gearbeitet, mit der die Navigationsleistung durch das Vorabrufen oder sogar Vorabrendern zukünftiger Navigationen verbessert werden soll. Diese zusätzlichen Verbesserungen sind jetzt alle ab Chrome 122 verfügbar (einige Funktionen sind ab früheren Versionen verfügbar).
Diese Änderungen machen das Prefetching und Prerendering von Seiten deutlich einfacher zu implementieren und weniger ressourcenintensiv. Wir hoffen, dass dies die Akzeptanz weiter steigern wird.
Zusätzliche Funktionen
Zuerst werden die neuen Ergänzungen der Speculation Rules API und ihre Verwendung erläutert. Danach zeigen wir Ihnen eine Demo, damit Sie sehen können, wie sie in der Praxis funktionieren.
Dokumentregeln
Bisher wurde die Speculation Rules API verwendet, indem eine Liste von URLs zum Prefetching oder Pre-Rendering angegeben wurde:
<script type="speculationrules">
{
"prerender": [
{
"source": "list",
"urls": ["next.html", "next2.html"]
}
]
}
</script>
Die Spekulationsregeln waren halbdynamisch, da neue Spekulationsregel-Scripts hinzugefügt und alte Scripts entfernt werden konnten, um diese Spekulationen zu verwerfen. Wenn die urls-Liste eines vorhandenen Spekulationsregel-Scripts aktualisiert wird, ändert sich die Spekulation jedoch nicht. Die Auswahl der URLs blieb jedoch weiterhin der Website überlassen, entweder durch Senden vom Server bei der Seitenanforderung oder durch dynamisches Erstellen dieser Liste über clientseitiges JavaScript.
Listenregeln bleiben eine Option für einfachere Anwendungsfälle (bei denen die nächste Navigation aus einer kleinen Menge offensichtlicher Optionen erfolgt) oder komplexere Anwendungsfälle (bei denen die Liste der URLs dynamisch auf Grundlage der Heuristiken berechnet wird, die der Websiteinhaber verwenden möchte, und dann in die Seite eingefügt wird).
Alternativ bieten wir jetzt eine neue Option zum automatischen Suchen von Links mithilfe von Dokumentregeln an. Dazu werden URLs aus dem Dokument selbst auf Grundlage einer where-Bedingung abgerufen. Das kann auf Grundlage der Links selbst erfolgen:
<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>
So kann ein einzelnes Spekulationsregelset für die gesamte Website verwendet werden, anstatt für jede Seite spezifische Regeln zu haben. Das macht es für Websites viel einfacher, Spekulationsregeln zu implementieren.
Natürlich wäre es ineffizient, alle Links auf einer Seite vorzurendern. Deshalb haben wir mit dieser neuen Funktion eine eagerness-Einstellung eingeführt.
Eifrigkeit
Bei jeder Art von Spekulation gibt es einen Kompromiss zwischen Precision und Recall sowie der Vorlaufzeit. Wenn Sie alle Links beim Laden der Seite vorrendern, wird mit hoher Wahrscheinlichkeit auch der Link vorgerendert, auf den ein Nutzer klickt (vorausgesetzt, er klickt auf einen Link auf derselben Website). Das Vorrendern erfolgt mit möglichst viel Vorlaufzeit, kann aber zu einer enormen Bandbreitenverschwendung führen.
Andererseits wird durch das Vorrendern erst nach dem Klicken auf einen Link Verschwendung vermieden, allerdings auf Kosten einer deutlich verkürzten Vorlaufzeit. Das bedeutet, dass das Vorrendern wahrscheinlich nicht 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 wann spekuliert werden soll von den URLs getrennt, für die Spekulationen ausgeführt werden sollen. Die Einstellung eagerness ist sowohl für list- als auch für document-Quellregeln verfügbar und hat vier Einstellungen, für die Chrome die folgenden Heuristiken verwendet:
immediate:Damit wird so schnell wie möglich spekuliert, d. h., sobald die Spekulationsregeln eingehalten werden.eager:Diese Einstellung verhält sich derzeit identisch mit der Einstellungimmediate. In Zukunft soll sie jedoch zwischenimmediateundmoderateliegen.moderate:Spekulationen werden ausgeführt, wenn Sie den Mauszeiger 200 Millisekunden lang auf einen Link bewegen (oder beimpointerdown-Ereignis, falls es früher eintritt, und auf Mobilgeräten, auf denen es keinhover-Ereignis gibt).conservative:Hier wird über das Herunterdrücken des Zeigers oder des Touch-Geräts spekuliert.
Der Standardwert für eagerness für list-Regeln ist immediate. Mit den Optionen moderate und conservative können Sie list-Regeln auf eine bestimmte Liste von URLs beschränken, mit denen ein Nutzer interagiert. In vielen Fällen sind jedoch document-Regeln mit einer geeigneten where-Bedingung besser geeignet.
Der Standardwert für eagerness für document-Regeln ist conservative. Da ein Dokument aus vielen URLs bestehen kann, sollte die Verwendung von immediate oder eager für document-Regeln mit Vorsicht erfolgen (siehe auch den nächsten Abschnitt Chrome-Limits).
Welche eagerness-Einstellung Sie verwenden sollten, hängt von Ihrer Website ab. Bei einer sehr einfachen statischen Website sind die Kosten für das Spekulieren möglicherweise gering und es kann für Nutzer von Vorteil sein. Bei Websites mit komplexeren Architekturen und größeren Seiten-Payloads ist es möglicherweise besser, weniger oft zu spekulieren, bis Sie mehr positive Intentionen von Nutzern erhalten, um Verschwendung zu begrenzen.
Die Option moderate ist ein Mittelweg. Viele Websites könnten von der folgenden einfachen Spekulationsregel profitieren, mit der alle Links bei Mouseover oder Pointerdown vorgerendert werden. Das ist eine einfache, aber leistungsstarke Implementierung von Spekulationsregeln:
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": {
"href_matches": "/*"
},
"eagerness": "moderate"
}]
}
</script>
Chrome-Beschränkungen
Auch wenn Sie eagerness auswählen, gelten in Chrome Limits, um eine übermäßige Nutzung dieser API zu verhindern:
eagerness |
Prefetch | Prerender |
|---|---|---|
immediate/eager |
50 | 10 |
moderate/conservative |
2 (FIFO) | 2 (FIFO) |
Die Einstellungen moderate und conservative, die von der Nutzerinteraktion abhängen, funktionieren nach dem FIFO-Prinzip (First In, First Out). Wenn das Limit erreicht ist, wird durch eine neue Spekulation die älteste Spekulation abgebrochen und durch die neuere ersetzt, um Speicherplatz zu sparen.
Da moderate- und conservative-Spekulationen von Nutzern ausgelöst werden, können wir einen niedrigeren Schwellenwert von 2 verwenden, um Arbeitsspeicher zu sparen. Die Einstellungen immediate und eager werden nicht durch eine Nutzeraktion ausgelöst und haben daher ein höheres Limit, da der Browser nicht wissen kann, welche wann benötigt werden.
Eine Spekulation, die durch das Verdrängen aus der FIFO-Warteschlange abgebrochen wird, kann noch einmal ausgelöst werden, z. B. durch erneutes Bewegen des Mauszeigers auf den Link. In diesem Fall wird die URL noch einmal spekuliert. In diesem Fall hat der Browser wahrscheinlich einige Ressourcen im HTTP-Cache für diese URL zwischengespeichert. Wenn Sie die Spekulation wiederholen, sollten die Netzwerk- und Zeitkosten also deutlich geringer sein.
Die Limits für immediate und eager sind ebenfalls dynamisch. Wenn Sie ein Spekulationsregelskript-Element mit diesen Eagerness-Stufen entfernen, wird Kapazität geschaffen, indem die entfernten Spekulationen abgebrochen werden. Diese URLs können auch neu geschätzt werden, wenn sie in einem neuen URL-Script enthalten sind und das Limit noch nicht erreicht wurde.
Chrome verhindert auch, dass Spekulationen unter bestimmten Bedingungen verwendet werden, z. B.
- Save-Data.
- Energiesparmodus
- Arbeitsspeicherbeschränkungen
- Wenn die Einstellung „Seiten vorab laden“ deaktiviert ist (was auch explizit durch Chrome-Erweiterungen wie uBlock Origin deaktiviert wird).
- Seiten, die auf Tabs im Hintergrund geöffnet wurden.
Alle diese Bedingungen zielen darauf ab, die Auswirkungen von Überlegungen zu verringern, wenn sie für Nutzer schädlich wären.
Optional source
In Chrome 122 ist der source-Schlüssel optional, da er 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 bereitgestellt werden, anstatt sie direkt in den HTML-Code des Dokuments einzufügen. Dies ermöglicht eine einfachere Bereitstellung durch CDNs, ohne dass der Dokumentinhalt selbst geändert werden muss.
Der HTTP-Header Speculation-Rules wird mit dem Dokument zurückgegeben und verweist auf den Speicherort einer JSON-Datei mit den Spekulationsregeln:
Speculation-Rules: "/speculationrules.json"
Diese Ressource muss den richtigen MIME-Typ verwenden und, falls es sich um eine ursprungsübergreifende Ressource handelt, eine CORS-Prüfung bestehen.
Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *
Wenn Sie relative URLs verwenden möchten, sollten Sie den Schlüssel "relative_to": "document" in Ihre Spekulationsregeln aufnehmen. Andernfalls sind relative URLs relativ zur URL der JSON-Datei mit den Spekulationsregeln. Das kann besonders nützlich sein, wenn Sie einige oder alle Links mit demselben Ursprung auswählen müssen.
Bessere Cache-Wiederverwendung
Wir haben das Caching in Chrome verbessert, sodass beim Prefetching oder sogar Prerendering eines Dokuments Ressourcen im HTTP-Cache gespeichert und wiederverwendet werden. Das bedeutet, dass Spekulationen auch dann zukünftige Vorteile haben können, wenn sie nicht verwendet werden.
Dadurch wird auch das erneute Spekulieren (z. B. für Dokumentregeln mit der Eigenschaft moderate) erheblich günstiger, da Chrome den HTTP-Cache für cachefähige Ressourcen verwendet.
Wir unterstützen auch den neuen No-Vary-Search-Vorschlag, um die Cache-Wiederverwendung weiter zu verbessern.
No-Vary-Search-Support
Beim Prefetching oder Prerendering einer Seite sind bestimmte URL-Parameter (technisch als Suchparameter bezeichnet) möglicherweise für die tatsächlich vom Server bereitgestellte Seite unwichtig und werden nur von clientseitigem JavaScript verwendet.
UTM-Parameter werden beispielsweise von Google Analytics zur Kampagnenanalyse verwendet, führen aber in der Regel nicht dazu, dass vom Server unterschiedliche Seiten ausgeliefert werden. Das bedeutet, dass page1.html?utm_content=123 und page1.html?utm_content=456 dieselbe Seite vom Server bereitstellen. Dieselbe Seite kann also aus dem Cache wiederverwendet werden.
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 keinen Unterschied zur bereitgestellten Ressource zur Folge haben. Dadurch kann ein Browser zuvor im Cache gespeicherte Versionen eines Dokuments wiederverwenden, die sich nur durch diese Parameter unterscheiden. Hinweis: Derzeit wird dies nur in Chrome (und Chromium-basierten Browsern) für Prefetch-Navigationsspekulationen 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. So können Sie unnötige Downloads vermeiden.
<script type="speculationrules">
{
"prefetch": [{
"urls": ["/products"],
"expects_no_vary_search": "params=(\"id\")"
}]
}
</script>
<a href="/https/developer.chrome.com/products?id=123">Product 123</a>
<a href="/https/developer.chrome.com/products?id=124">Product 124</a>
In diesem Beispiel ist der HTML-Code der Startseite /products für die beiden Produkt-IDs 123 und 124 identisch. Die Seiteninhalte unterscheiden sich jedoch letztendlich aufgrund des clientseitigen Renderings, bei dem mit JavaScript Produktdaten über den Suchparameter id abgerufen werden. Wir rufen diese URL also im Voraus ab. Sie sollte einen No-Vary-Search-HTTP-Header zurückgeben, der angibt, dass die Seite für jeden id-Suchparameter verwendet werden kann.
Wenn der Nutzer jedoch auf einen der Links klickt, bevor das Prefetching abgeschlossen ist, hat der Browser die Seite /products möglicherweise noch nicht empfangen. In diesem Fall weiß der Browser nicht, ob er den HTTP-Header No-Vary-Search enthält. Der Browser hat dann die Wahl, ob er den Link noch einmal abrufen oder warten soll, bis der Prefetch abgeschlossen ist, um zu sehen, ob er einen No-Vary-Search-HTTP-Header enthält. Mit der Einstellung expects_no_vary_search wird dem Browser mitgeteilt, dass die Seitenantwort voraussichtlich einen No-Vary-Search-HTTP-Header enthält und dass er warten soll, bis der Prefetch abgeschlossen ist.
Demo
Wir haben unter https://chrome.dev/speculative-loading/common-fruits.html eine Demo erstellt, mit der Sie Dokumentregeln mit der Eigenschaft moderate in Aktion sehen können:
Öffnen Sie die Entwicklertools und klicken Sie auf das Steuerfeld Anwendung. Klicken Sie dann im Bereich Hintergrunddienste auf Spekulative Ladevorgänge, dann auf den Bereich Spekulationen und sortieren Sie nach der Spalte Status.
Wenn Sie den Mauszeiger auf die Früchte bewegen, sehen Sie, wie die Seiten vorgerendert werden. Wenn Sie darauf klicken, wird eine viel kürzere LCP-Zeit angezeigt als bei einem der Rezepte, die nicht vorgerendert werden. Diese Demo wird auch im folgenden Video erläutert:
Weitere Informationen zur Verwendung von DevTools zum Debuggen von Spekulationsregeln finden Sie im vorherigen Blogpost zum Debuggen von Spekulationsregeln.
Plattformunterstützung für Spekulationsregeln
Spekulationsregeln lassen sich relativ einfach implementieren, indem die Regeln in ein <script type="speculationrules">-Element eingefügt werden. Die Plattformunterstützung kann dies jedoch zu einem Ein-Klick-Vorgang machen. Wir haben mit verschiedenen Plattformen und Partnern zusammengearbeitet, um die Einführung von Spekulationsregeln zu vereinfachen.
Wir arbeiten außerdem intensiv daran, die API über die Web Incubator Community Group (WICG) zu standardisieren, damit auch andere Browser diese interessante API implementieren können.
WordPress
Das WordPress Core Performance-Team (einschließlich Entwicklern von Google) hat ein Speculation Rules-Plug-in erstellt. Mit diesem Plug-in können Sie jeder WordPress-Website mit nur einem Klick Unterstützung für Dokumentregeln hinzufügen. Dieses Plug‑in kann auch über das WordPress Performance Lab-Plug‑in installiert werden. Sie sollten es ebenfalls installieren, da Sie so über zugehörige Leistungs-Plug‑ins des Teams auf dem Laufenden bleiben.
Es gibt zwei Gruppen von Einstellungen: den Spekulationsmodus und die Einstellung Eagerness (Einsatzbereitschaft):
Weitere Informationen zu komplexeren Setups, z. B. zum Ausschließen bestimmter URLs vom Vorabruf oder Vorabrendern, finden Sie in der Dokumentation.
Akamai
Akamai ist einer der weltweit führenden CDN-Anbieter und testet die Speculation Rules API schon seit einiger Zeit. Akamai hat Dokumentation dazu veröffentlicht, wie Kunden diese API in ihren CDN-Einstellungen aktivieren können. Sie haben auch schon die beeindruckenden Ergebnisse geteilt, die mit dieser neuen API möglich sind.
Uxify
Uxify (früher Teil von NitroPack) ist eine Lösung zur Leistungsoptimierung, die die benutzerdefinierte Navigation AI verwendet, um vorherzusagen, welche Seiten zu Spekulationsregeln hinzugefügt werden sollen. So soll eine längere Vorlaufzeit als beim Hovern über einen Link erreicht werden, ohne dass unnötig auf alle beobachteten Links spekuliert wird. Weitere Informationen finden Sie in der Dokumentation zur Uxify Speculation Rules API. Diese innovative Lösung zeigt, dass die älteren Listenregeln in Kombination mit websitespezifischen Statistiken immer noch viel zu bieten haben.
Das Chrome-Team hat außerdem mit dem Team an einem Webinar zur Speculation Rules API für alle zusammengearbeitet, die weitere Informationen benötigen. Dabei wurde auch ausführlich erörtert, welche Überlegungen bei der Spekulation früh und oft sowie spät und seltener zu berücksichtigen sind.
Astro
Astro hat in Version 4.2 experimentell das Vorrendern von Seiten mit der Speculation Rules API hinzugefügt. So können Entwickler, die Astro verwenden, dieses Feature ganz einfach aktivieren und für Browser, die die Speculation Rules API nicht unterstützen, auf ein Standard-Prefetch zurückgreifen. Weitere Informationen finden Sie in der Dokumentation zum clientseitigen Prerendering.
Fazit
Durch diese Ergänzungen der Speculation Rules API lässt sich diese neue Leistungsfunktion für Websites viel einfacher nutzen. Außerdem wird das Risiko verringert, dass Ressourcen durch ungenutzte Spekulationen verschwendet werden. Es ist spannend zu sehen, dass Plattformen diese API bereits nutzen. Wir hoffen, dass diese API 2024 häufiger eingesetzt wird und Endnutzer dadurch letztendlich eine bessere Leistung erhalten.
Neben den Leistungssteigerungen, die die Speculation Rules API bietet, freuen wir uns auch auf die neuen Möglichkeiten, die sich dadurch ergeben. View Transitions ist eine neue API, mit der Entwickler Übergänge zwischen Navigationsvorgängen einfacher festlegen können. Diese Funktion ist derzeit für Single-Page-Anwendungen (SPAs) verfügbar. Die Version für mehrere Seiten ist in Arbeit und in Chrome hinter einem Flag verfügbar. Das Vorrendern ist eine natürliche Ergänzung dieser Funktion, um Verzögerungen zu vermeiden, die ansonsten die Verbesserung der Nutzerfreundlichkeit verhindern würden, die durch den Übergang erreicht werden soll. Wir haben bereits Websites gesehen, die diese Kombination testen.
Wir freuen uns auf eine weitere Nutzung der Speculation Rules API im Jahr 2024 und werden Sie über alle weiteren Verbesserungen der API auf dem Laufenden halten.
Danksagungen
Thumbnail von Robbie Down auf Unsplash