Verbesserungen an der Speculation Rules API

Barry Pollard

Das Chrome-Team hat an einigen spannenden Updates für die Speculation Rules API gearbeitet. Mit ihr soll die Navigationsleistung durch Vorabruf oder sogar Pre-Rendering zukünftiger Navigationen verbessert werden. Diese zusätzlichen Verbesserungen sind jetzt ab Chrome 122 verfügbar (mit einigen Funktionen aus früheren Versionen).

Diese Änderungen machen das Vorabrufen und Pre-Rendering von Seiten erheblich einfacher und kosteneffizienter und wir hoffen, dass wir eine weitere Einführung dieser Seiten fördern werden.

Zusätzliche Funktionen

Zuerst erläutern wir die neuen Ergänzungen des Speculation Rules API und ihre Verwendung. Anschließend zeigen wir dir ein Demo, mit dem du die Funktionen in Aktion sehen kannst.

Dokumentregeln

Bisher wurde in der Speculation Rules API eine Liste von URLs für Prefetch oder Pre-Rendering angegeben:

<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 wurden, um diese Spekulationen zu verwerfen. Beachte, dass das Aktualisieren der urls-Liste eines bestehenden Skripts für Spekulationen keine Änderung an Spekulationen auslöst. Die Auswahl der URLs wurde jedoch weiterhin der Website überlassen, entweder indem sie zum Zeitpunkt der Seite vom Server gesendet wurden oder indem diese Liste dynamisch mit clientseitigem JavaScript erstellt wurde.

Listenregeln sind weiterhin eine Option für einfachere Anwendungsfälle, bei denen die nächste Navigation von einer kleinen Reihe offensichtlicher Anwendungsfälle stammt, oder für komplexere Anwendungsfälle, bei denen die Liste der URLs basierend auf der vom Websiteinhaber gewünschten Heuristik dynamisch berechnet und dann in die Seite eingefügt wird.

Als Alternative bieten wir eine neue Option für die automatische Linksuche mithilfe von Dokumentregeln an. Dazu werden URLs aus dem Dokument selbst basierend auf 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>

Hinweis :Eine frühere Version der Dokumentregeln, die während des Ursprungstests verfügbar war, enthielt einen komplexeren href_matches, für den eine zusätzliche Syntax zum Abgleichen von URL-Parametern und Fragmenten erforderlich war ({"href_matches": "/*\\?*#*"}). Dies wurde in der Release-Version vereinfacht.

CSS-Selektoren können auch alternativ 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>

Dadurch kann ein einziger Spekulationsregelsatz für die gesamte Website verwendet werden, anstatt einen pro Seite zu haben, was die Implementierung von Spekulationsregeln für Websites erheblich erleichtert.

Das Pre-Rendering aller Links auf einer Seite wäre definitiv Verschwendung. Mit dieser neuen Funktion haben wir eine eagerness-Einstellung eingeführt.

Eifr

Bei jeder Art von Spekulation müssen Sie einen Kompromiss zwischen Precision und Recall und der Vorlaufzeit treffen. Das Pre-Rendering aller Links beim Seitenaufbau bedeutet, dass Sie einen Link, auf den ein Nutzer klickt (vorausgesetzt, dass er auf einen Link derselben Website auf der Seite klickt) mit so viel Vorlaufzeit wie möglich, jedoch mit einer potenziell enormen Bandbreitenverschwendung.

Andererseits wird das Pre-Rendering nur dann verhindert, wenn ein Nutzer auf einen Link geklickt hat, um Verschwendung zu vermeiden, allerdings auf Kosten einer deutlich kürzeren Vorlaufzeit. Das Pre-Rendering ist also unwahrscheinlich, bevor der Browser zu dieser Seite wechselt.

Mit der Einstellung „eagerness“ kannst du festlegen, wann Spekulationen ausgeführt werden sollen, und trennst damit, wann du spekulieren möchtest, von welchen URLs Spekulationen durchgeführt werden sollen. Die Einstellung „eagerness“ ist für die Quellregeln „list“ und „document“ verfügbar und enthält vier Einstellungen, für die Chrome die folgende Heuristik verwendet:

• immediate:Wird verwendet, um so schnell wie möglich zu spekulieren, d. h. sobald die Spekulationsregeln befolgt werden.
• eager:Das Verhalten entspricht derzeit der Einstellung immediate. Zukünftig möchten wir sie aber irgendwo zwischen immediate und moderate platzieren.
• moderate:Es werden Spekulationen angewendet, wenn Sie den Mauszeiger 200 Millisekunden lang auf einen Link bewegen (bzw. auf das pointerdown-Ereignis, wenn dieses früher erfolgt, und auf Mobilgeräten, wenn es kein hover-Ereignis gibt).
• conservative:spekuliert auf einen Zeiger oder Touchdown.

Die Standardeinstellung „eagerness“ für list-Regeln ist immediate. Die Optionen moderate und conservative können verwendet werden, um list-Regeln auf URLs zu beschränken, mit denen ein Nutzer interagiert, auf eine bestimmte Liste. In vielen Fällen sind document-Regeln mit einer entsprechenden where-Bedingung jedoch möglicherweise geeigneter.

Die Standardeinstellung „eagerness“ für document-Regeln ist conservative. Da ein Dokument viele URLs enthalten kann, sollten Sie immediate oder eager für document-Regeln mit Vorsicht verwenden (siehe auch den Abschnitt Beschränkungen für Chrome).

Welche eagerness-Einstellung Sie verwenden sollten, hängt von Ihrer Website ab. Bei einer sehr einfachen statischen Website kann es wenig kosten, mehr zu spekulieren, und bringt Nutzern Vorteile. Websites mit komplexeren Architekturen und schwereren Seitennutzlasten können Verschwendung reduzieren, indem weniger häufig spekuliert wird, bis Sie positivere Absichtssignale von Nutzenden zur Begrenzung von Verschwendung erhalten.

Achtung :Überspekulationen verursachen eindeutige Kosten für Nutzer hinsichtlich Bandbreite, Arbeitsspeicher und CPU, aber auch für die Websites selbst. Seien Sie sich der Auswirkungen bewusst, die Sie auf Ihre Nutzenden haben, wenn Sie Spekulationen einführen. Mit den Einstellungen für „eagerness“ kannst du die Wahrscheinlichkeit verringern, dass Spekulationen verschwendet werden. Chrome schränkt auch Spekulationen ein, um die Auswirkungen einer übermäßigen Nutzung zu verringern.

Die Option moderate ist ein Mittelweg, und viele Websites könnten von der folgenden einfachen Spekulationsregel profitieren, die alle Links, die durch Bewegen des Mauszeigers oder Mauszeigers nach unten scrollen, als einfache und dennoch leistungsfähige Implementierung von Spekulationsregeln vorab rendert:

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

Limits für Chrome

Selbst bei der Auswahl von eagerness gelten für Chrome Einschränkungen, um eine übermäßige Nutzung dieser API zu verhindern:

eagerness	Prefetch	Vorab rendern
immediate / eager	50	10
moderate / conservative	2 (FIFO)	2 (FIFO)

Spekulationslimits in Chrome

Die Einstellungen für moderate und conservative, die von der Nutzerinteraktion abhängen, wirken sich in der FIFO-Methode (First In, First Out) aus. Nach Erreichen des Limits führt eine neue Spekulation dazu, dass die älteste Spekulation abgebrochen und durch die neue ersetzt wird, um Arbeitsspeicher zu sparen.

Die Tatsache, dass 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 „immediate“ und „eager“ werden nicht durch eine Nutzeraktion ausgelöst. Daher haben sie ein höheres Limit, da der Browser nicht erkennen kann, welche erforderlich sind und wann sie benötigt werden.

Eine Spekulation, die durch das Verschieben aus der FIFO-Warteschlange abgebrochen wird, kann erneut ausgelöst werden, z. B. indem der Mauszeiger noch einmal auf diesen Link bewegt wird. Dies führt dazu, dass diese URL erneut 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 zwischenspeichert, sodass eine Wiederholung der Spekulation ein deutlich geringeres Netzwerk und somit deutlich geringere Zeitkosten zur Folge hätte.

Die Limits für immediate und eager gelten ebenfalls. Wenn du ein Skriptelement für Spekulationsregeln mit diesen „Eagerness-Levels“ entfernst, kannst du neue Kapazitäten schaffen, indem die entfernten Spekulationen abgebrochen werden. Diese URLs können auch neu spekuliert werden, wenn sie in einem neuen URL-Skript enthalten sind und die Beschränkung noch nicht erreicht wurde.

Chrome verhindert außerdem , dass Spekulationen unter bestimmten Bedingungen verwendet werden, darunter:

• Save Data (Daten speichern).
• Energiesparmodus:
• Arbeitsspeichereinschränkungen.
• Die Einstellung „Seiten vorab laden“ ist deaktiviert (diese Einstellung wird auch durch Chrome-Erweiterungen wie uBlock Origin explizit deaktiviert).
• Seiten werden in Tabs im Hintergrund geöffnet.

All diese Bedingungen zielen darauf ab, die Auswirkungen von übermäßigen Spekulationen zu verringern, wenn sie sich schädlich für die Nutzer darstellen würden.

Optional: source

In Chrome 122 ist der Schlüssel source 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 mithilfe eines Speculation-Rules-HTTP-Headers übermittelt 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 einen Speicherort in einer JSON-Datei, die die Spekulationsregeln enthält:

Speculation-Rules: "/speculationrules.json"

Warnung :Da es sich um einen strukturierten Titel handelt, sind die Anführungszeichen wichtig und müssen im Headerwert enthalten sein.

Für diese Ressource muss der richtige MIME-Typ verwendet werden. Wenn es sich um eine ursprungsübergreifende Ressource handelt, muss eine CORS-Prüfung bestehen.

Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *

Wenn du relative URLs verwenden möchtest, kannst du den "relative_to": "document"-Schlüssel in deine Spekulationsregeln aufnehmen. Andernfalls sind relative URLs relativ zur URL der JSON-Datei für Spekulationsregeln. Dies kann besonders nützlich sein, wenn Sie einige oder alle Links desselben Ursprungs auswählen müssen.

Bessere Cache-Wiederverwendung

Wir haben eine Reihe von Verbesserungen am Caching in Chrome vorgenommen, sodass beim Vorabruf (oder sogar Pre-Rendering) eines Dokuments Ressourcen im HTTP-Cache gespeichert und wiederverwendet werden können. Das bedeutet, dass Spekulationen immer noch Vorteile haben können, auch wenn diese Spekulationen nicht verwendet werden.

Dadurch wird auch das Respektieren deutlich günstiger, z. B. bei Dokumentregeln mit der Eagerness-Einstellung moderate, da Chrome den HTTP-Cache für im Cache speicherbare Ressourcen verwendet.

Wir unterstützen auch den neuen No-Vary-Search-Vorschlag, um die Cache-Wiederverwendung weiter zu verbessern.

No-Vary-Search-Support

Beim Vorabruf oder Pre-Rendering einer Seite können bestimmte URL-Parameter (auch als Suchparameter bezeichnet) für die tatsächlich vom Server bereitgestellte Seite unwichtig sein. Sie werden nur vom clientseitigen JavaScript verwendet.

UTM-Parameter werden von Google Analytics beispielsweise zur Kampagnenmessung verwendet, führen aber normalerweise nicht dazu, dass unterschiedliche Seiten vom Server gesendet werden. Das bedeutet, dass page1.html?utm_content=123 und page1.html?utm_content=456 dieselbe Seite vom Server übermitteln, 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 übermittelten Ressource führen. Auf diese Weise 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 der Prefetch-Navigation unterstützt.

Die Verwendung von expects_no_vary_search wird für Spekulationsregeln unterstützt, 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 ersten Seite /products für die Produkt-IDs 123 und 124 identisch. Die Seiteninhalte unterscheiden sich jedoch letztendlich aufgrund des clientseitigen Renderings, bei dem Produktdaten mit dem Suchparameter id abgerufen werden. Wir rufen diese URL also vorab ab und sie sollte einen No-Vary-Search-HTTP-Header zurückgeben, der darauf hinweist, dass die Seite für jeden id-Suchparameter verwendet werden kann.

Wenn der Nutzer jedoch auf einen der Links klickt, bevor der Prefetch abgeschlossen ist, hat der Browser die /products-Seite möglicherweise nicht erhalten. In diesem Fall weiß der Browser nicht, ob der HTTP-Header No-Vary-Search enthalten sein wird. Der Browser kann dann entscheiden, ob der Link noch einmal abgerufen werden soll oder ob er einen No-Vary-Search-HTTP-Header enthält, bis der Prefetch abgeschlossen ist. Mit der Einstellung expects_no_vary_search weiß der Browser, dass die Seitenantwort voraussichtlich einen No-Vary-Search-HTTP-Header enthält, und kann darauf warten, dass der Prefetch abgeschlossen ist.

Demo

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

Demo zu Spekulationsregeln

Ö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 und sortieren Sie die Daten nach der Spalte Status.

Wenn du den Mauszeiger auf die Früchte bewegst, siehst du die Seiten, die vorab gerendert werden. Wenn du darauf klickst, wird eine viel schnellere LCP-Zeit angezeigt als eines der Schemas, die nicht vorab gerendert werden. Diese Demo wird auch in diesem Video erläutert:

Weitere Informationen zur Fehlerbehebung bei Spekulationsregeln mithilfe der Entwicklertools finden Sie im Blogpost zur Fehlerbehebung bei Spekulationsregeln.

Plattformunterstützung für Spekulationsregeln

Während Spekulationsregeln relativ einfach zu implementieren sind, indem die Regeln in ein <script type="speculationrules">-Element eingeschleust werden, kann der Plattformsupport dafür sorgen, dass dies mit nur einem Klick erledigt wird. Wir haben mit verschiedenen Plattformen und Partnern zusammengearbeitet, um die Einführung von Spekulationsregeln zu vereinfachen.

Wir arbeiten außerdem intensiv an der Standardisierung der API über die Web Incubator Community Group (WICG), damit bei Bedarf auch andere Browser diese spannende API implementieren können.

WordPress

Das WordPress Core Performance-Team (einschließlich Entwickler von Google) hat ein Spulation Rules-Plug-in erstellt. Mit diesem Plug-in können Sie jeder WordPress-Website mit nur einem Klick Dokumentregeln hinzufügen. Sie können dieses Plug-in auch über das WordPress Performance Lab-Plug-in installieren. Es empfiehlt sich, dieses Plug-in zu installieren, da Sie so immer auf dem neuesten Stand sind.

Es sind zwei Gruppen von Einstellungen verfügbar: der Spekulationsmodus und die Einstellung Eagerness:

WordPress Speculation Rules-Plug-in

Weitere Informationen für kompliziertere Einrichtungen, z. B. um bestimmte URLs vom Vorabruf oder zum Pre-Rendering auszuschließen, 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 aktiv. Akamai hat eine Dokumentation darüber veröffentlicht, wie Kunden diese API in ihren CDN-Einstellungen aktivieren können. Außerdem hat das Unternehmen die beeindruckenden Ergebnisse, die mit dieser neuen API möglich sind, bekannt gegeben.

NitroPack

NitroPack ist eine Lösung zur Leistungsoptimierung, die mithilfe der benutzerdefinierten Navigation AI vorhersagt, welche Seiten den Spekulationsregeln hinzugefügt werden sollen. Damit soll eine längere Vorlaufzeit als beim Bewegen des Mauszeigers auf einen Link erreicht werden, ohne unnötigen Spekulation über alle beobachteten Links zu vermeiden. Weitere Informationen finden Sie in der Dokumentation zur Niropack Speculation Rules API. Diese innovative Lösung zeigt, dass die älteren Listenregeln in Kombination mit websitespezifischen Einblicken noch viel zu bieten haben.

Das Chrome-Team arbeitete außerdem mit NitroPack an einem Webinar zur Speculation Rules API, bei dem es um mehr Informationen ging. Dabei wurde unter anderem auf die Überlegungen zwischen einem frühen und häufigen Spekulieren sowie einem späten und weniger häufigen Spekulation eingegangen.

Astro

Astro hat Pre-Rendering-Seiten mit der Speculation Rules API in Version 4.2 als experimentelle Funktion hinzugefügt. So können Entwickler, die Astro verwenden, diese Funktion problemlos aktivieren, während für Browser, die die Speculation Rules API nicht unterstützen, auf einen Standard-Prefetch zurückgreift. Weitere Informationen findest du in der Dokumentation zum Pre-Rendering von Clients.

Fazit

Diese Ergänzungen des Speculation Rules API ermöglichen eine viel einfachere Nutzung dieser spannenden neuen Performance-Funktion für Websites und verringern das Risiko, Ressourcen durch ungenutzte Spekulationen zu verschwenden. Es ist interessant zu sehen, dass Plattformen diese API bereits nutzen. Wir hoffen, dass diese API 2024 häufiger eingesetzt und dadurch letztendlich eine bessere Leistung für Endnutzer erreicht wird.

Neben den Leistungssteigerungen, die die Speculation Rules API bietet, sind wir auch gespannt, welche neuen Möglichkeiten sich dadurch ergeben. View Transitions (Übergänge anzeigen) ist eine neue API, mit der Entwickler Übergänge zwischen Navigationen einfacher festlegen können. Diese Option ist derzeit für Single-Page-Anwendungen (SPAs) verfügbar, aber die mehrseitige Version ist noch in Arbeit und ist in Chrome hinter einem Flag verfügbar. Pre-Rendering ist ein natürliches Add-on für diese Funktion, das dafür sorgt, dass es keine Verzögerung gibt, die andernfalls die angestrebte Verbesserung der Nutzererfahrung durch den Übergang verhindern würde. Wir haben bereits Websites gesehen, auf denen mit dieser Kombination getestet wird.

Wir freuen uns auf die weitere Einführung der Speculation Rules API im Jahr 2024 und halten Sie über alle weiteren Verbesserungen auf dem Laufenden.

Danksagungen

Thumbnail von Robbie Down auf Unsplash