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 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>

Hinweis: Eine frühere Version der Dokumentregeln, die während des Ursprungstests verfügbar war, hatte eine komplexere href_matches, die zusätzliche Syntax zum Abgleich von URL-Parametern und Fragmenten ({"href_matches": "/*\\?*#*"}) erforderte. Dies wurde in der Release-Version vereinfacht.

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 der immediate-Einstellung, wir planen jedoch, sie in Zukunft irgendwo zwischen immediate und moderate zu platzieren.
• moderate:Diese Funktion führt zu Spekulationen, wenn du den Mauszeiger 200 Millisekunden lang auf einen Link bewegst (oder auf das Ereignis pointerdown, wenn das früher schon einmal war, und auf Mobilgeräten, wo kein hover-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.

Achtung :Übermäßige Spekulationen verursachen Kosten für die Nutzer in Bezug auf Bandbreite, Arbeitsspeicher und CPU, aber auch für die Websites selbst. Achte darauf, welche Auswirkungen du auf deine Nutzer hast, wenn du Spekulationen anwendest. Mit den Einstellungen für „eagerness“ lässt sich die Wahrscheinlichkeit verringern, dass Spekulationen verschwendet werden. Auch Spekulationen werden in Chrome eingeschränkt, um die Auswirkungen einer übermäßigen Nutzung zu reduzieren.

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)

Spekulationslimits in Chrome

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"

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 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:

<ph type="x-smartling-placeholder">

</ph>

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. 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">

</ph>

WordPress-Plug-in für Spekulationsregeln

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