Was ist die Speculation Rules API?

Die Speculation Rules API ist ein Mechanismus des Chrome-Browsers, um die nächste Seite vorherzusehen, die ein Nutzer besuchen wird, und mit der Vorbereitung zu beginnen, bevor er klickt. In der Idee ist das nichts Neues, Ressourcen vorab zu laden gibt es seit Jahren mit rel=prefetch und rel=preload, wohl aber im Umfang: statt einer einzelnen Datei kann sie die komplette Navigation vorbereiten, einschließlich der Ausführung von JavaScript.

Sie ersetzt das alte Tag link rel=prerender, das Chrome wegen seines schwer kontrollierbaren Ressourcenverbrauchs abgeschafft hat. Die neue API definiert Regeln über einen Block script type=speculationrules im JSON-Format, wodurch sich präzise festlegen lässt, wann gehandelt wird: eine feste Liste von URLs, oder ein Muster, das auf jeden Link zutrifft, der eine Bedingung erfüllt, was die Spezifikation document rules nennt.

Es handelt sich um eine Funktion, die spezifisch für Chromium-basierte Browser ist; sie ist zum Zeitpunkt dieser Redaktion kein universeller Standard, der von allen Browsern unterstützt wird. In den übrigen Browsern lädt die Seite weiterhin auf die gewohnte Weise, ohne den Vorsprung, den diese API liefert, was bei der Bewertung von Performance-Messungen zu berücksichtigen ist.

Die API unterscheidet zwei Aktionen. Prefetch lädt das Zieldokument herunter und hält es im Speicher vor, ohne es auszuführen oder zu rendern; das ist die leichtere Option. Prerender geht weiter: es lädt die komplette Seite in einem versteckten Tab, führt ihr JavaScript aus und hält sie bereit, sodass der Browser beim Klick nur den sichtbaren Tab durch den bereits vorbereiteten ersetzen muss, ohne spürbare Ladezeit.

Wann welche Aktion ausgelöst wird, steuert der Parameter eagerness mit vier Stufen: immediate handelt, sobald der Browser die Regel sieht, eager löst nach einer minimalen Interaktion aus (etwa 10 Millisekunden Mauskontakt über dem Link auf Desktop), moderate wartet auf eine deutlichere Interaktion (etwa 200 Millisekunden, oder den Beginn einer Berührung auf Mobilgeräten), und conservative handelt erst, wenn der Nutzer bereits zu drücken begonnen hat. Je höher die eagerness, desto schneller kommt der Inhalt an, aber desto mehr Anfragen werden auch ohne echten Bedarf ausgelöst.

Document rules erlauben es, das Kriterium über CSS-Selektoren oder URL-Muster (href_matches, selector_matches) festzulegen, statt jeden Link einzeln aufzulisten, damit die Regel automatisch auf alle Links einer Liste oder Kategorie zutrifft.

Die Funktion kam mit Chrome 109 im Januar 2023; der Parameter eagerness folgte mit Chrome 121, und spätere Versionen (136, 138) haben weitere Kontrollen ergänzt, darunter die Möglichkeit anzugeben, in welchem Tab das Ergebnis aktiviert werden soll. Wer die Technik einsetzt, sollte also auch die eingesetzte Chrome-Version im Blick behalten, nicht nur die Regel selbst.

Wenn Bilder bereits komprimiert sind und der Server schnell antwortet, liegt der verbleibende Spielraum, um den LCP (Largest Contentful Paint) zu verbessern, meist in der Navigation selbst: der Zeit, die der Browser braucht, um nach dem Klick mit dem Laden der nächsten Seite zu beginnen. Prerender kann diese Zeit praktisch auf null senken, weil die Seite beim Klick des Nutzers bereits geladen war.

Das ist die technische Erklärung dafür, warum manche Seiten ohne das übliche Ladeflackern «erscheinen»: nicht weil der Server schneller ist, sondern weil der Browser vor dem Klick bereits zu arbeiten begonnen hat. Für den Besucher fühlt sich das wie ein Sprung an, technisch ist es Vorarbeit, die vor dem Klick unsichtbar passiert. Für eine Website, die Bild- und Server-Optimierungen schon ausgeschöpft hat, ist das eines der wenigen verbliebenen Mittel, um den LCP weiter zu senken.

Der Preis liegt auf der anderen Seite: jedes Prerender verbraucht Bandbreite und CPU des Besuchers, auch wenn es nie genutzt wird, sodass ein unkritischer Einsatz bei langen Listen Seiten lädt, die niemand besuchen wird. Deshalb gibt es den Parameter eagerness: damit dieser Preis nur gezahlt wird, wenn ein vernünftiges Signal dafür spricht, dass der Nutzer wirklich klicken wird. Diese Abwägung zwischen Geschwindigkeit und verschwendeten Ressourcen ist der Kern jeder sinnvollen Konfiguration. Wer diese Abwägung ignoriert, verschenkt am Ende entweder Geschwindigkeit oder unnötig verbrauchte Serverkapazität.

• Beginne bei langen Listen (interne Suchergebnisse, Kataloge) mit prefetch und reserviere prerender für die vorhersehbarsten Pfade, etwa den nächsten Schritt in einem Kauftrichter.
• Nutze eagerness moderate oder conservative bei wenig vorhersehbaren Links, und eager oder immediate nur dort, wo der nächste Klick fast sicher ist, etwa ein Weiter-Button in einer Seitennummerierung.
• Wende prerender nicht auf Seiten mit Nebenwirkungen beim Laden an, etwa einem Kauf, einem Formularversand oder einem unerwünschten Analytics-Ereignis; das Laden passiert auch dann, wenn der Nutzer nicht klickt.
• Miss die tatsächliche Wirkung auf den LCP mit Felddaten (CrUX), nicht nur im Labor: das Verhalten ändert sich je nach Gerät und Verbindung des Besuchers.
• Prüfe den Datenverbrauch auf Mobilgeräten mit begrenzter Verbindung, bevor du breite Regeln auf Basis von Listen oder Mustern (document rules) aktivierst.
• Prüfe die Browser-Unterstützung, bevor du dich allein auf diese Technik als Performance-Verbesserung verlässt: zum Zeitpunkt dieser Redaktion ist sie spezifisch für Chromium-basierte Browser.

• Prerender ungefiltert auf die gesamte Ergebnisliste anwenden, was Anfragen vervielfacht und die Verbindung des Besuchers belasten kann, ohne die tatsächliche Erfahrung zu verbessern.
• Prefetch mit prerender verwechseln: prefetch führt kein JavaScript aus und rendert nicht, deshalb bietet es nicht denselben Geschwindigkeitssprung und passt nicht zum selben Anwendungsfall.
• Nicht prüfen, dass die Zielseite keine Nebenwirkungen beim Laden hat, was unerwünschte Aktionen vor dem tatsächlichen Klick auslösen kann.
• Es als Ersatz für die Optimierung von Bildern oder Server behandeln, obwohl es ein zusätzliches Mittel ist, das erst wirkt, wenn diese Verbesserungen ausgeschöpft sind.
• Annehmen, es verbessere das Crawling oder die Indexierung: ein Suchmaschinen-Crawler navigiert nicht wie ein Nutzer in Chrome, deshalb ändert diese Technik nicht, wie von außerhalb des Browsers auf die Seite zugegriffen wird, sondern nur die Erfahrung des menschlichen Besuchers.