Speculation Rules API: Prädiktives Prerendering für nahtlose Navigation

1. Was ist die Speculation Rules API

Die Speculation Rules API ist eine deklarative Browser-Schnittstelle, mit der eine Website dem Browser mitteilt, welche Folgeseiten der Nutzer mit hoher Wahrscheinlichkeit als nächstes aufrufen wird. Die Regeln werden als JSON-Objekt in einem <script type="speculationrules">-Element eingebettet, sodass keine zusätzliche JavaScript-Bibliothek nötig ist. Der Browser wertet diese Regeln selbstständig aus und entscheidet anhand von Nutzerinteraktionen wie Mauszeigerbewegung oder Berührung, wann er tatsächlich aktiv wird.

Im Kern unterscheidet die API zwei Aktionen: prefetch für das reine Herunterladen des HTML-Dokuments in den HTTP-Cache und prerender für das vollständige Rendern der Zielseite in einem versteckten, inaktiven Tab-ähnlichen Prozess. Letzteres schließt das Ausführen von JavaScript, das Laden von Subressourcen und den kompletten Seitenaufbau ein. Klickt der Nutzer tatsächlich auf den vorhergesagten Link, tauscht der Browser lediglich den bereits fertigen Zustand ein, was den wahrgenommenen Seitenwechsel auf wenige Millisekunden reduziert.

2. Unterschied zu klassischem <link rel="prefetch">

Das altbekannte <link rel="prefetch"> lädt lediglich die Rohdaten einer Ressource, meist das HTML-Dokument, in den Browser-Cache. Es findet dabei kein Rendering, kein Parsen des DOM-Baums und keine Ausführung von JavaScript statt. Beim tatsächlichen Seitenwechsel muss der Browser trotzdem noch das komplette Rendering durchführen, wodurch zwar der Netzwerk-Roundtrip entfällt, aber ein spürbarer Teil der Ladezeit bestehen bleibt.

Prerendering über die Speculation Rules API geht deutlich weiter, denn es baut die Zielseite bereits vollständig auf, inklusive Layout, Style-Berechnung und Skriptausführung. Dadurch fühlt sich die Navigation für den Nutzer nicht wie ein Laden an, sondern wie ein simples Umschalten zwischen zwei bereits fertigen Zuständen. Dieser Ansatz ersetzt in Chrome faktisch die früher experimentelle NoState-Prefetch-Technik und die veraltete <link rel="prerender">-Direktive vollständig.

3. Eagerness-Stufen: Eager vs. Moderate in der Praxis

Die Eagerness-Einstellung steuert, wie aggressiv der Browser eine Regel auslöst. Die Stufe immediate startet die Spekulation sofort, sobald die Regel geladen wird, während eager bereits bei der ersten Nutzerinteraktion in der Nähe eines Links reagiert. Die Stufe moderate wartet auf ein Hover-Ereignis von etwa zweihundert Millisekunden oder auf ein Pointerdown-Ereignis, und conservative löst ausschliesslich bei einem tatsächlichen Pointerdown aus, also unmittelbar bevor der Klick abgeschlossen wird.

Für die meisten Onlineshops empfiehlt sich ein Mittelweg: Kategorie- und Produktlisten-Links erhalten moderate, damit nur echte Kaufabsicht ein Prerendering auslöst, während besonders wichtige Konversionspfade wie der Warenkorb-Button durchaus eager vertragen. Das folgende Beispiel zeigt eine praxisnahe Konfiguration mit gemischten Eagerness-Stufen für unterschiedliche URL-Muster.

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "document",
      "where": { "href_matches": "/checkout/warenkorb*" },
      "eagerness": "eager"
    },
    {
      "source": "document",
      "where": { "href_matches": "/produkt/*" },
      "eagerness": "moderate"
    }
  ],
  "prefetch": [
    {
      "source": "document",
      "where": { "href_matches": "/kategorie/*" },
      "eagerness": "conservative"
    }
  ]
}
</script>

4. Document Rules vs. List Rules

Bei source: "document" wertet der Browser alle Links im aktuellen Dokument fortlaufend aus und wendet die im Feld where definierten Muster wie href_matches automatisch auf neue Links an, die etwa nach einer AJAX-Aktualisierung hinzukommen. Dieser Ansatz eignet sich hervorragend für Kategorie- und Suchergebnisseiten, deren Linkstruktur sich dynamisch ändert, ohne dass die Regeln manuell nachgeführt werden müssen.

Die Alternative source: "list" gibt eine feste Liste konkreter URLs vor, die unabhängig vom sichtbaren Linkbestand spekulativ geladen werden sollen. Das ist sinnvoll für bekannte High-Traffic-Ziele wie die Startseite eines Folgeschritts im Checkout oder eine besonders häufig aufgerufene Landingpage, die im aktuellen Dokument gar nicht verlinkt sein muss. Beide Quelltypen lassen sich in derselben Regelmenge kombinieren.

5. Browser-Support und schrittweise Aktivierung

Die Speculation Rules API wird aktuell von Chromium-basierten Browsern wie Chrome und Edge unterstützt, während Firefox und Safari sie noch nicht implementiert haben. Da die Regeln als reines JSON-Skript eingebunden werden, ignorieren nicht unterstützende Browser das Element einfach, sodass keine Fehler entstehen und die Seite ohne Prerendering ganz normal funktioniert. Ein Feature-Test ist somit nicht zwingend erforderlich, schadet aber nicht als zusätzliche Absicherung für Monitoring-Zwecke.

Für den produktiven Einsatz empfiehlt sich ein schrittweises Vorgehen: zunächst nur prefetch mit konservativer Eagerness für wenige Seitentypen aktivieren, die Auswirkung auf Ladezeiten und Serverlast beobachten, und erst danach gezielt einzelne Bereiche auf prerender umstellen. So lässt sich der Effekt in echten Nutzerdaten messen, bevor die Regeln auf den gesamten Seitenbestand ausgeweitet werden.

6. Server-seitige Überlegungen und Header

Wenn der Browser eine spekulative Anfrage stellt, sendet er den Header Sec-Purpose mit dem Wert prefetch oder prefetch;prerender mit. Server-seitige Logik kann diesen Header auswerten, um beispielsweise Tracking-Pixel oder Analytics-Events erst bei der tatsächlichen, nicht spekulativen Anfrage auszulösen. Ohne diese Unterscheidung würden Seitenaufrufe doppelt gezählt, sobald ein Nutzer eine vorhergesagte Seite letztlich doch nicht besucht.

Zusätzlich existiert der Header No-Vary-Search, mit dem eine Seite dem Browser mitteilt, dass bestimmte Query-Parameter, etwa Tracking-Codes in der URL, keinen Einfluss auf den Seiteninhalt haben. Dadurch kann ein bereits spekulativ geladenes Dokument auch dann wiederverwendet werden, wenn die tatsächlich aufgerufene URL sich in unwichtigen Parametern unterscheidet, was die Trefferquote des Caches spürbar erhöht.

7. Risiken bei Fehlvorhersagen

Der größte Nachteil eines zu aggressiv konfigurierten Regelsatzes ist unnötige Serverlast durch Anfragen, die nie in eine tatsächliche Navigation münden. Wird beispielsweise jede Produktkarte auf einer Listingseite mit eager-Eagerness versehen, kann allein das Überfahren mit der Maus dutzende spekulative Requests auslösen, von denen die meisten verworfen werden. Das belastet nicht nur die Serverinfrastruktur, sondern kostet auch Nutzern mit begrenztem Datenvolumen unnötig Bandbreite.

Ein zweites Risiko betrifft Seiten mit Zustandsänderungen: Speculation Rules dürfen laut Spezifikation nur auf GET-Anfragen ohne Formularversand angewendet werden, sodass ein versehentliches Auslösen von destruktiven Aktionen technisch ausgeschlossen ist. Dennoch können serverseitige Effekte wie das Hochzählen von Aufrufzählern oder das Füllen von Session-abhängigen Caches durch spekulative Requests ausgelöst werden, wenn die Sec-Purpose-Unterscheidung im Backend fehlt. Eine sorgfältige Prüfung aller betroffenen Endpunkte ist deshalb vor dem produktiven Einsatz Pflicht.

8. Praktische Implementierungsstrategie

Der sinnvollste Einstieg ist eine Messung der aktuellen Navigationszeiten mit der Navigation Timing API, um eine belastbare Baseline zu haben, bevor Speculation Rules aktiviert werden. Anschliessend lohnt es sich, mit einer kleinen, klar abgegrenzten Regel zu starten, etwa nur für die am häufigsten angeklickten Kategorie-Links, und die Wirkung über echte Nutzerdaten im Feld zu beobachten statt sich allein auf Labormessungen zu verlassen.

Parallel dazu sollte das Backend-Team prüfen, ob Analytics-Events korrekt zwischen spekulativen und echten Anfragen unterscheiden, und ob teure Datenbankoperationen bei GET-Anfragen ungewollte Nebenwirkungen haben. Erst wenn diese Grundlagen stehen, empfiehlt sich die schrittweise Ausweitung auf weitere Seitentypen und eine feinere Abstimmung der Eagerness-Werte je nach gemessener Konversionswahrscheinlichkeit der jeweiligen Linkgruppe.

9. Zusammenfassung und Ausblick

Die Speculation Rules API verlagert einen Teil der Ladezeit einer Website vom Moment des Klicks in die Zeit davor, in der der Nutzer ohnehin noch liest oder überlegt. Richtig konfiguriert entsteht so ein Navigationserlebnis, das sich für den Nutzer wie eine Single-Page-Anwendung anfühlt, obwohl technisch weiterhin klassische Mehrseiten-Navigation stattfindet. Damit schließt die API eine wichtige Lücke zwischen traditionellen Websites und modernen App-artigen Erlebnissen.

Für die Zukunft ist zu erwarten, dass weitere Browser-Hersteller nachziehen und dass die API um feinere Steuerungsmöglichkeiten für cross-origin Prerendering erweitert wird. Bis dahin bleibt sie ein progressives Enhancement, das unterstützende Browser beschleunigt, ohne andere Browser in irgendeiner Form zu beeinträchtigen, was sie zu einem risikoarmen, aber wirkungsvollen Baustein moderner Performance-Strategien macht.

10. Zusammenfassung

11. FAQ: Speculation Rules API