Verbesserungen an der Speculation Rules API

Barry Pollard

Das Chrome-Team hat an einigen spannenden Updates für die Speculation Rules API gearbeitet, mit denen die Navigationsleistung durch Vorab-Caching oder sogar Vorab-Rendering zukünftiger Navigationen verbessert wird. Diese zusätzlichen Verbesserungen sind ab Chrome 122 verfügbar (einige Funktionen sind bereits in früheren Versionen verfügbar).

Durch diese Änderungen wird das Vorabladen und Vorrendern von Seiten erheblich einfacher und weniger ineffizient. Wir hoffen, dass diese Änderungen die Akzeptanz weiter steigern werden.

Zusätzliche Funktionen

Zuerst werden die neuen Funktionen der Speculation Rules API und ihre Verwendung erläutert. Anschließend sehen Sie sich eine Demo an, in der die Funktionen in Aktion zu sehen sind.

Dokumentregeln

Bisher wurde für die Speculation Rules API eine Liste von URLs angegeben, die vorab abgerufen oder gerendert werden sollten:

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

Die Spekulationsregeln waren halbdynamisch, da neue Spekulationsregelscripts hinzugefügt und alte Scripts entfernt werden konnten, um diese Spekulationen zu verwerfen. Hinweis: Das Aktualisieren der urls-Liste eines vorhandenen Spekulationsregelscripts führt nicht zu einer Änderung der Spekulationen. Die Auswahl der URLs blieb jedoch der Website überlassen, entweder durch Senden der URLs vom Server zum Zeitpunkt der Seitenanfrage 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 Gruppe offensichtlicher Navigationspunkte besteht) oder für komplexere Anwendungsfälle (bei denen die Liste der URLs dynamisch anhand der Heuristiken berechnet wird, die der Websiteinhaber verwenden möchte, und dann in die Seite eingefügt wird).

Als Alternative bieten wir Ihnen eine neue Option für die automatische Linkerkennung mithilfe von Dokumentregeln. Dazu werden URLs basierend auf einer where-Bedingung aus dem Dokument selbst abgerufen. Das 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 Kombination 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 eine einzige Spekulationsregel für die gesamte Website verwendet werden, anstatt spezifische Regeln pro Seite zu haben. Das erleichtert die Implementierung von Spekulationsregeln für Websites erheblich.

Natürlich wäre es verschwenderisch, alle Links auf einer Seite vorab zu rendern. Deshalb haben wir mit dieser neuen Funktion eine eagerness-Einstellung eingeführt.

Begeisterung

Bei jeder Art von Spekulation gibt es einen Kompromiss zwischen Precision und Recall und der Vorlaufzeit. Wenn Sie beim Laden der Seite alle Links vorrendern, wird fast mit Sicherheit auch der Link vor dem Klick des Nutzers gerendert (vorausgesetzt, er klickt auf einen Link auf der Seite). Das geschieht mit möglichst viel Vorlaufzeit, führt aber zu einer potenziell enormen Bandbreitenverschwendung.

Wenn Sie das Pre-Rendering jedoch erst starten, wenn ein Nutzer auf einen Link geklickt hat, wird Verschwendung verhindert. Allerdings ist die Vorlaufzeit dann deutlich kürzer. Das bedeutet, dass das Prerendering 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 unterschieden, wann Spekulationen ausgeführt werden sollen und auf welchen URLs. Die Einstellung eagerness ist sowohl für list- als auch für document-Quellregeln verfügbar. Sie 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 Einstellung immediate. Künftig soll sie jedoch zwischen immediate und moderate liegen.
• moderate:Es werden Spekulationen durchgeführt, wenn Sie 200 Millisekunden lang den Mauszeiger auf einen Link bewegen (oder beim Ereignis pointerdown, wenn dies früher eintritt, und auf Mobilgeräten, wo es kein hover-Ereignis gibt).
• conservative:Hier wird auf den Zeiger oder das Touchdown spekuliert.

Der Standardwert für 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. 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, sollten immediate oder eager für document-Regeln mit Vorsicht verwendet werden. Weitere Informationen finden Sie im nächsten Abschnitt Chrome-Limits.

Welche eagerness-Einstellung Sie verwenden, hängt von Ihrer Website ab. Bei einer sehr einfachen statischen Website kann eine größere Spekulation mit wenig Kosten verbunden sein und für Nutzer von Vorteil sein. Bei Websites mit komplexeren Architekturen und größeren Seitennutzlasten sollten Sie die Auslieferung von Anzeigen mit weniger Spekulationen reduzieren, bis Sie mehr positive Signale von Nutzern erhalten, um die Auslieferung von Anzeigen zu begrenzen.

Die Option moderate ist ein Mittelweg. Viele Websites könnten von der folgenden einfachen Spekulationsregel profitieren, die alle Links beim Bewegen des Mauszeigers oder beim Klicken vorrendert. Das ist eine einfache, aber leistungsstarke Implementierung von Spekulationsregeln:

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

Chrome-Einschränkungen

Auch wenn Sie eagerness auswählen, gibt es in Chrome Limits, um eine übermäßige Nutzung dieser API zu verhindern:

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 neue ersetzt, um Speicher zu sparen.

Da moderate- und conservative-Spekulationen von Nutzern ausgelöst werden, können wir einen niedrigeren Grenzwert von 2 verwenden, um den Arbeitsspeicher zu schonen. Die Einstellungen immediate und eager werden nicht durch eine Nutzeraktion ausgelöst und haben daher ein höheres Limit, da der Browser nicht weiß, welche und wann sie benötigt werden.

Eine Spekulation, die durch das Ausschieben aus der FIFO-Warteschlange abgebrochen wird, kann noch einmal ausgelöst werden, z. B. durch erneutes Bewegen des Mauszeigers auf den Link. Dies führt dazu, dass die URL noch einmal geschätzt wird. In diesem Fall hat die vorherige Spekulation wahrscheinlich dazu geführt, dass der Browser einige Ressourcen für diese URL im HTTP-Cache gespeichert hat. Die Wiederholung der Spekulation sollte daher deutlich weniger Netzwerk- und Zeitkosten verursachen.

Die Limits für immediate und eager sind ebenfalls dynamisch. Wenn Sie ein Scriptelement für Spekulationsregeln mit diesen Eiligkeitsstufen entfernen, wird Kapazität freigesetzt, da 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.

Außerdem verhindert Chrome, dass in bestimmten Fällen Spekulationen verwendet werden, z. B.:

• Save-Data
• Energiesparmodus
• Arbeitsspeichereinschränkungen
• Wenn die Einstellung „Seiten vorab laden“ deaktiviert ist (was auch von Chrome-Erweiterungen wie uBlock Origin ausdrücklich deaktiviert wird).
• Seiten, die in Hintergrund-Tabs geöffnet wurden.

Mit all diesen Bedingungen soll die Auswirkung von übertriebenen Spekulationen reduziert werden, wenn diese für Nutzer schädlich sind.

Optional source

In Chrome 122 ist der Schlüssel source optional, da er sich aus der Anwesenheit der Tasten url oder where ableiten lässt. 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 gesendet 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 Speculation-Rules-HTTP-Header 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 plattformü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 Spekulationsregeln. Das ist besonders nützlich, wenn Sie einige oder alle Links mit demselben Ursprung auswählen möchten.

Bessere Cache-Wiederverwendung

Wir haben das Caching in Chrome verbessert, damit beim Vorabladen (oder sogar Vorabrendering) eines Dokuments Ressourcen im HTTP-Cache gespeichert und wiederverwendet werden. Das bedeutet, dass Spekulationen auch dann in Zukunft Vorteile haben können, wenn sie nicht genutzt werden.

Außerdem wird die Neuberechnung (z. B. für Dokumentregeln mit einer moderate-Eagerness-Einstellung) erheblich günstiger, da Chrome den HTTP-Cache für cachebare Ressourcen verwendet.

Wir unterstützen auch den neuen No-Vary-Search-Vorschlag zur weiteren Verbesserung der Cache-Wiederverwendung.

No-Vary-Search-Support

Beim Vorabladen oder Vorabrendering einer Seite sind bestimmte URL-Parameter (technisch Suchparameter genannt) möglicherweise für die vom Server tatsächlich bereitgestellte Seite nicht wichtig und werden nur von clientseitigem JavaScript verwendet.

UTM-Parameter werden beispielsweise in Google Analytics für die 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 ausliefern, 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 können Server Parameter angeben, die keine Auswirkungen auf die bereitgestellte Ressource haben. So 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-Navigationsvorhersagen unterstützt.

Spekulationsregeln unterstützen die Verwendung von expects_no_vary_search, um anzugeben, wo ein No-Vary-Search-HTTP-Header voraussichtlich zurückgegeben wird. So können Sie 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 Startseite /products für die beiden Produkt-IDs 123 und 124 identisch. Der Seiteninhalt unterscheidet sich jedoch je nach clientseitigem Rendering mit JavaScript, um Produktdaten mit dem Suchparameter id abzurufen. Daher wird diese URL vorab abgerufen und es sollte ein No-Vary-Search-HTTP-Header zurückgegeben werden, der angibt, dass die Seite für jeden id-Suchparameter verwendet werden kann.

Klickt der Nutzer jedoch auf einen der Links, bevor der Prefetch abgeschlossen ist, hat der Browser möglicherweise die Seite /products nicht erhalten. In diesem Fall weiß der Browser nicht, ob er den HTTP-Header No-Vary-Search enthält. Der Browser kann dann wählen, ob er den Link noch einmal abrufen oder warten möchte, bis der Prefetch abgeschlossen ist, um zu sehen, ob er einen No-Vary-Search-HTTP-Header enthält. Die Einstellung expects_no_vary_search gibt dem Browser an, dass die Seitenantwort voraussichtlich einen No-Vary-Search-HTTP-Header enthalten wird, und wartet, bis dieser Prefetch abgeschlossen ist.

Demo

Unter https://speculative-rules.glitch.me/common-fruits.html haben wir eine Demo erstellt, in der Dokumentregeln mit einer moderate-Eagerness-Einstellung in Aktion zu sehen sind:

Öffnen Sie die Entwicklertools und klicken Sie auf den Bereich Anwendung. Klicken Sie dann im Bereich Hintergrunddienste auf Spekulative Ladevorgänge und dann auf den Bereich Spekulationen. Sortieren Sie die Ergebnisse nach der Spalte Status.

Wenn Sie den Mauszeiger auf die Früchte bewegen, sehen Sie das Pre-Rendering der Seiten. Wenn Sie darauf klicken, wird eine viel kürzere LCP-Zeit angezeigt als bei einem der Rezepte, die nicht vorab gerendert werden. Diese Demo wird auch in diesem Video erläutert:

Weitere Informationen zur Fehlerbehebung bei Spekulationsregeln mithilfe von DevTools finden Sie im vorherigen Blogpost.

Plattformunterstützung für Spekulationsregeln

Spekulationsregeln lassen sich relativ einfach implementieren, indem sie in ein <script type="speculationrules">-Element eingefügt werden. Mit der Plattformunterstützung ist das aber nur noch ein Klick. Wir arbeiten mit verschiedenen Plattformen und Partnern zusammen, um die Einführung von Regeln zu Spekulationen zu vereinfachen.

Außerdem arbeiten wir intensiv daran, die API über die Web Incubator Community Group (WICG) zu standardisieren, damit auch andere Browser diese spannende API implementieren können.

WordPress

Das WordPress Core Performance Team (einschließlich Entwicklern von Google) hat das Plug-in für Spekulationsregeln entwickelt. Mit diesem Plug-in können Sie jeder WordPress-Website mit nur einem Klick die Unterstützung für Dokumentenregeln hinzufügen. Dieses Plug-in kann auch über das WordPress Performance Lab installiert werden. Wir empfehlen Ihnen, dieses Plug-in zu installieren, da Sie damit über ähnliche Leistungs-Plug-ins des Teams auf dem Laufenden bleiben.

Es gibt zwei Gruppen von Einstellungen: den Spekulationsmodus und die Einstellung Eagerness:

Weitere Informationen zu komplexeren Konfigurationen, z. B. zum Ausschließen bestimmter URLs vom Prefetching oder Prerendering, finden Sie in der Dokumentation.

Akamai

Akamai ist einer der weltweit führenden CDN-Anbieter und führt seit einiger Zeit aktiv Tests mit der Speculation Rules API durch. Akamai hat eine Dokumentation veröffentlicht, in der erläutert wird, wie Kunden diese API in ihren CDN-Einstellungen aktivieren können. Außerdem hat das Unternehmen bereits die beeindruckenden Ergebnisse vorgestellt, die mit dieser neuen API möglich sind.

NitroPack

NitroPack ist eine Lösung zur Leistungsoptimierung, die mithilfe der benutzerdefinierten Navigations-KI vorhersagt, welche Seiten den Spekulationsregeln hinzugefügt werden sollen. Dadurch soll eine längere Vorlaufzeit als beim Bewegen des Mauszeigers auf einen Link erreicht werden, ohne dass unnötigerweise Spekulationen zu allen beobachteten Links angestellt werden. Weitere Informationen finden Sie in der API-Dokumentation zu den Spekulationsregeln von Nitropack. Diese innovative Lösung zeigt, dass die älteren Listenregeln in Kombination mit websitespezifischen Statistiken noch viel zu bieten haben.

Das Chrome-Team hat außerdem mit NitroPack an einem Webinar zur Speculation Rules API gearbeitet. Darin werden unter anderem die Vor- und Nachteile von frühen und häufigen sowie späten und weniger häufigen Spekulationen besprochen.

Astro

In Astro wurde in Version 4.2 das Vorab-Rendering von Seiten mithilfe der Speculation Rules API auf experimenteller Basis hinzugefügt. Entwickler, die Astro verwenden, können diese Funktion ganz einfach aktivieren und bei Browsern, die die Speculation Rules API nicht unterstützen, auf ein standardmäßiges Vorab-Rendering zurückgreifen. Weitere Informationen finden Sie in der Dokumentation zum Client-Pre-Rendering.

Fazit

Diese Ergänzungen der Speculation Rules API ermöglichen eine wesentlich einfachere Nutzung dieser spannenden neuen Leistungsfunktion für Websites, mit weniger Risiko, Ressourcen durch nicht verwendete Spekulationen zu verschwenden. Es ist spannend zu sehen, dass Plattformen diese API bereits nutzen. Wir hoffen, dass diese API im Jahr 2024 weiter verbreitet wird und dass Endnutzer dadurch eine bessere Leistung erhalten.

Neben den Leistungssteigerungen, die die Speculation Rules API bietet, sind wir auch gespannt, welche neuen Möglichkeiten sich dadurch eröffnen. View Transitions ist eine neue API, mit der Entwickler Übergänge zwischen Navigationen einfacher angeben können. Diese Funktion ist derzeit für Single-Page-Anwendungen (SPAs) verfügbar. Die Version für mehrere Seiten ist in Arbeit und kann in Chrome über ein Flag aktiviert werden. Das Vorab-Rendering ist ein natürliches Add-on zu dieser Funktion, um Verzögerungen zu vermeiden, die andernfalls die Nutzerfreundlichkeit beeinträchtigen würden, die mit der Umstellung beabsichtigt ist. Wir haben bereits Websites gesehen, auf denen diese Kombination getestet wird.

Wir freuen uns auf die weitere Einführung der API für Spekulationsregeln im Laufe des Jahres 2024 und halten Sie über alle weiteren Verbesserungen der API auf dem Laufenden.

Danksagungen

Thumbnail von Robbie Down auf Unsplash