Zwischen dem Klick auf einen Link und dem Moment, in dem die nächste Seite erscheint, liegt für Nutzer die eigentliche Wartezeit im Web. Genau hier setzt die Speculation Rules API an: Sie lässt den Browser eine wahrscheinliche Folgeseite bereits im Hintergrund prefetchen oder komplett prerendern, sodass beim Klick nichts mehr geladen werden muss -- die Seite ist im Millisekundenbereich da statt nach einer oder mehreren Sekunden. Der Hebel ist groß, denn nur 48 Prozent (Chrome UX Report) der mobilen Websites bestehen derzeit alle Core Web Vitals, und der Largest Contentful Paint bleibt mit nur 62 Prozent (Chrome UX Report) bestandener mobiler Seiten die am schwersten zu erfüllende Core-Web-Vitals-Metrik 2026. Die Verbreitung wächst rasch: Bei den mobilen Seiten der Top 10 Millionen nutzen bereits 25 Prozent (Web Almanac 2025) Speculation Rules. Dieser Beitrag erklärt die Eagerness-Stufen, das Vermeiden verschwendeter Prerenders, den Umgang mit Skript-Nebenwirkungen wie Analytics und die 2026 neue Stufe prerender until script -- und wo eine gezielte Frontend-Optimierung den Unterschied macht.
Das Wichtigste in Kürze
- Speculation Rules laden eine wahrscheinliche Folgeseite vorab -- prefetch holt nur das Dokument, prerender baut die komplette Seite im Hintergrund auf, sodass der Klick sie sofort aktiviert.
- Die Eagerness-Stufe entscheidet, wann spekuliert wird: von conservative (erst beim Klick) über moderate (ab 200 Millisekunden Hover) bis immediate (sofort) -- mehr Tempo bedeutet mehr Risiko verschwendeter Prerenders.
- Verschwendung vermeidet man über präzise where-Regeln, eine zur Trefferwahrscheinlichkeit passende Eagerness und die Chrome-eigenen Limits, die nur wenige Spekulationen gleichzeitig zulassen.
- Ein Prerender führt Skripte schon im Hintergrund aus -- Analytics und ähnliche Nebenwirkungen müssen über document.prerendering und das prerenderingchange-Ereignis bis zur Aktivierung aufgeschoben werden.
- Die neue Stufe prerender until script aus Chrome 144 rendert die Seite, hält aber vor blockierenden Skripten an -- ein Mittelweg, der viel Tempo bringt, ohne Skripte vorzeitig auszulösen.
Was Speculation Rules sind und warum sie wirken
Um zu verstehen, warum Speculation Rules so wirksam sind, hilft ein Blick darauf, wie klassische Navigation abläuft. Klickt ein Nutzer auf einen Link, beginnt der Browser erst dann mit allem: Er baut die Verbindung auf, lädt das HTML, entdeckt darin CSS, Schriften, Bilder und Skripte, lädt auch diese und rendert schließlich die Seite. Jede dieser Etappen kostet Zeit, und sie laufen weitgehend nacheinander ab. Der Largest Contentful Paint der neuen Seite entsteht deshalb typischerweise erst nach einer spürbaren Verzögerung. Anders als klassische Resource Hints wie preload und preconnect, die einzelne Dateien vorbereiten, spekuliert diese API auf eine ganze Folgeseite und verschiebt deren komplette Ladearbeit auf einen Zeitpunkt vor dem Klick, an dem der Browser ohnehin Leerlauf hat.
Die API kennt zwei Ausbaustufen. Ein prefetch lädt nur das HTML-Dokument der Zielseite vorab in den Cache -- die Unterressourcen und das Rendering folgen erst nach dem Klick, was den Verbindungsaufbau und die Zeit bis zum ersten Byte spart. Ein prerender geht deutlich weiter: Der Browser lädt das Dokument samt Unterressourcen und rendert die Seite vollständig in einem verborgenen Zustand. Wird die Navigation ausgelöst, tauscht er die vorbereitete Seite nur noch ein. Das Ergebnis ist laut Chrome ein nahezu sofortiger Seitenaufbau mit einem LCP nahe null (Chrome for Developers), oft begleitet von besseren Werten bei CLS und der Interaction to Next Paint. prefetch ist mit rund 6 Prozent (Web Almanac 2024) der Seiten bereits verbreitet, und allein bei JavaScript-Ressourcen stieg die Prefetch-Nutzung von 1,0 auf 4,8 Prozent (Web Almanac 2024) zwischen 2022 und 2024.
prefetch und prerender im Vergleich
Eagerness: die vier Stufen der Vorhersage
Die entscheidende Stellschraube ist die Eagerness. Sie trennt die Frage, welche URLs spekuliert werden, von der Frage, wann das geschieht. Chrome kennt vier Stufen mit klar definierten Auslösern. immediate spekuliert, sobald die Regel gelesen wird. eager beginnt schon bei einer sehr kurzen Berührung des Links -- auf dem Desktop bereits ab rund 10 Millisekunden (Chrome for Developers) Hover. moderate wartet, bis der Nutzer 200 Millisekunden (Chrome for Developers) auf einem Link verweilt oder ihn drückt. conservative schließlich spekuliert erst, wenn der Klick bereits beginnt. Standard ist immediate für explizite URL-Listen und conservative für breite document-Regeln.
| Eagerness | Wann spekuliert wird | Chrome-Limit (prefetch / prerender) | Wofür geeignet |
|---|---|---|---|
| conservative | erst bei pointer- oder touchdown | 2 / 2 (FIFO) | Standard für breite document-Regeln |
| moderate | ab 200 ms Hover oder pointerdown | 2 / 2 (FIFO) | die wahrscheinliche nächste Seite |
| eager | schon ab ca. 10 ms Hover | 50 / 10 | enge Link-Listen mit hoher Klickrate |
| immediate | sofort, sobald die Regel gelesen wird | 50 / 10 | wenige, sehr sichere Ziele |
Die Stufen sind kein Selbstzweck, sondern ein Risikoregler. Je früher spekuliert wird, desto öfter trifft die Vorhersage daneben und desto mehr Arbeit verpufft. Chrome begrenzt das automatisch: Bei immediate und eager hält der Browser bis zu 50 Prefetches und 10 Prerenders (Chrome for Developers) gleichzeitig vor, bei moderate und conservative dagegen nur je zwei (Chrome for Developers), die zudem nach dem First-in-first-out-Prinzip verdrängt werden. Für die meisten Seiten ist moderate der empfohlene Mittelweg.
moderate als Ausgangspunkt
Verschwendete Prerenders vermeiden
Jede Spekulation, die nicht in einer Navigation mündet, ist verschwendete Arbeit: Bandbreite, Rechenzeit und beim Prerender ein kompletter, ungenutzter Seitenaufbau. Auf Mobilgeräten mit begrenztem Datenvolumen oder schwachem Akku ist das besonders heikel, wie unser Beitrag zur mobilen Performance-Optimierung ausführt. Der Schlüssel liegt darin, nur plausible Ziele zu spekulieren und die Eagerness passend zur Trefferwahrscheinlichkeit zu wählen.
<script type="speculationrules">
{
"prefetch": [
{ "where": { "href_matches": "/*" }, "eagerness": "conservative" }
],
"prerender": [
{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": { "href_matches": "/logout" } },
{ "not": { "selector_matches": ".no-prerender" } }
]
},
"eagerness": "moderate"
}
]
}
</script>In diesem Beispiel gilt eine sparsame conservative-Regel für alle internen Links, während nur ein Teil der Seiten unter der aktiveren moderate-Stufe prerendert wird. Über das where-Objekt mit href_matches und selector_matches lässt sich präzise steuern, welche Links infrage kommen: Logout-Links, Warenkorb-Aktionen oder als .no-prerender markierte Elemente werden per not ausgeschlossen (MDN Web Docs). So bleiben zustandsverändernde oder teure Seiten außen vor, und die Spekulation konzentriert sich auf das, was Nutzer wahrscheinlich als Nächstes ansteuern.
Chrome spekuliert nicht in jeder Situation
- where-Regeln präzise fassen und zustandsverändernde Links wie Logout oder Warenkorb ausschließen
- Eagerness passend zur Trefferwahrscheinlichkeit wählen -- moderate als sicherer Ausgangspunkt
- prerender nur für wenige, sehr wahrscheinliche Ziele, prefetch für die breitere Menge
- Elemente, die nicht spekuliert werden sollen, mit einer .no-prerender-Klasse oder passenden rel-Attributen kennzeichnen
- Die Chrome-Limits einkalkulieren und nicht mehr Ziele erwarten, als der Browser gleichzeitig vorhält
- Die Wirkung in den Felddaten prüfen, statt Regeln pauschal auszurollen
Skript-Nebenwirkungen: Analytics und Consent sauber halten
Ein Prerender ist kein passiver Download, sondern ein vollständiger Seitenaufbau -- inklusive der Ausführung von JavaScript. Das ist mächtig, hat aber eine Kehrseite: Alles, was beim Laden Nebenwirkungen auslöst, geschieht bereits im Hintergrund, bevor der Nutzer die Seite überhaupt sieht. Der klassische Fall ist Analytics: Ein Seitenaufruf wird gezählt, obwohl noch niemand navigiert hat -- die Statistik wird verzerrt. Dasselbe gilt für Werbe-Impressionen, A/B-Test-Zuweisungen oder das Setzen bestimmter Cookies.
function startAnalytics() {
// zählt erst, wenn der Nutzer die Seite wirklich sieht
}
if (document.prerendering) {
document.addEventListener("prerenderingchange", startAnalytics, { once: true });
} else {
startAnalytics();
}Der Browser stellt dafür zwei Bausteine bereit. Die Eigenschaft document.prerendering ist während des Prerenderings true, und das Ereignis prerenderingchange feuert genau dann, wenn der Nutzer die Seite tatsächlich aktiviert (MDN Web Docs). Wie im Beispiel lässt sich damit jede Logik, die erst beim echten Seitenbesuch laufen darf, bis zur Aktivierung aufschieben. Für eingebundene Drittanbieter-Skripte, die man nicht selbst kontrolliert, ist das schwieriger -- ein Grund mehr, den Bestand solcher Skripte ohnehin schlank zu halten, wie unser Beitrag zum Entschlacken von Third-Party-Skripten zeigt.
Consent-sichere Prerenders
prerender until script: die neue Stufe aus Chrome 144
Der Zielkonflikt zwischen dem großen Tempo-Gewinn eines vollen Prerenders und seinen Nebenwirkungen hat 2026 eine neue Antwort bekommen. Mit Chrome 144 (Chrome for Developers), veröffentlicht am 23. Januar 2026, kam die Stufe prerender until script als Origin Trial hinzu. Sie ist ein Mittelweg zwischen prefetch und vollem prerender: Der Browser lädt das HTML und die Unterressourcen und beginnt, die Seite zu rendern -- hält den Parser aber an, sobald er auf ein blockierendes Skript trifft, und führt es erst nach der Navigation aus (Chrome for Developers). Der Preload-Scanner lädt in dieser Pause weiter Ressourcen nach.
| Verfahren | Was der Browser tut | Skripte | Tempo-Gewinn |
|---|---|---|---|
| prefetch | lädt nur das HTML-Dokument vor | keine Ausführung | moderat |
| prerender until script | HTML und Unterressourcen laden, Rendering beginnt, Halt vor blockierenden Skripten | erst nach der Navigation | hoch |
| prerender (voll) | rendert die Seite komplett inklusive Skripten | laufen schon im Hintergrund | am höchsten |
Der Gewinn ist beträchtlich: Laut Chrome liegt er deutlich über dem eines reinen prefetch und reicht potenziell fast an einen vollen prerender heran -- ohne dass Skripte vorzeitig laufen und Analytics oder Zustandsänderungen auslösen (Chrome for Developers). Für komplexe Seiten, bei denen ein voller Prerender bislang zu heikel war, ist das eine pragmatische Option. Als Origin Trial ist die Stufe zunächst nur eingeschränkt verfügbar und sollte, wie jede neue Browser-Funktion, mit einem sauberen Rückfall auf prefetch abgesichert werden.
Grenzen und Browser-Support
So wirksam Speculation Rules sind, ein universelles Werkzeug sind sie nicht. Die API ist noch nicht Baseline, das heißt, sie funktioniert nicht in allen weit verbreiteten Browsern (MDN Web Docs) -- was aber unkritisch ist, weil Browser ohne Unterstützung die Regeln schlicht ignorieren und die Seite wie gewohnt laden. Außerdem ist die Adoption über das Web ungleich verteilt: Bei den Top 1000 Seiten liegt sie mit nur 3 Prozent (Web Almanac 2025) auf dem Desktop und 5 Prozent (Web Almanac 2025) mobil niedrig, erreicht bei den Top 1 Million rund 15 Prozent (Web Almanac 2025) und steigt im langen Ende der Top 10 Millionen auf 25 Prozent (Web Almanac 2025). Ein Grund für die hohe Verbreitung im langen Ende ist, dass Speculation Rules inzwischen fest in WordPress eingebaut sind (Web Almanac 2025).
- Kein Ersatz für schnelle Seiten: Prerendering beschleunigt die Folge-Navigation, nicht den ersten Seitenaufruf
- Nicht in jedem Browser verfügbar -- Regeln werden ohne Unterstützung ignoriert
- Datensparmodus, Energiesparmodus und Speicherdruck unterdrücken Spekulationen
- Zustandsverändernde und einwilligungspflichtige Vorgänge müssen bis zur Aktivierung warten
- Cross-Origin-Ziele unterliegen zusätzlichen Einschränkungen und Anforderungen, etwa an den Referrer
Wie wir Speculation Rules sauber einrichten
In der Praxis gehen wir bei Speculation Rules genauso vor wie bei jeder anderen Maßnahme der Frontend-Optimierung: erst messen, dann handeln. Zunächst analysieren wir in einer Performance-Analyse die tatsächlichen Navigationspfade -- welche Seite folgt in einem Funnel typischerweise auf welche, wo entstehen die häufigsten Übergänge. Auf dieser Grundlage wählen wir Ziele und Eagerness so, dass die Trefferquote hoch bleibt und wenig Arbeit verpufft. Wir schließen zustandsverändernde Links aus, koppeln Analytics und einwilligungspflichtige Skripte sauber an die Aktivierung und sichern neue Stufen wie prerender until script mit einem Fallback ab. Anschließend prüfen wir die Wirkung in den Felddaten der Core Web Vitals, statt uns auf Laborwerte allein zu verlassen. Speculation Rules sind für uns Teil eines größeren Leistungsspektrums rund um Ladezeit und Core Web Vitals.
Instant-Navigation entsteht nicht dadurch, dass man möglichst viel prerendert, sondern dadurch, dass man genau die eine wahrscheinliche Folgeseite vorbereitet -- ohne Analytics zu verzerren und ohne auf schwachen Geräten Ressourcen zu verbrennen.
Der Kern in einem Satz
Der Reiz der Speculation Rules liegt darin, dass sie am unmittelbar erlebten Tempo ansetzen: Eine Folgeseite, die beim Klick schon da ist, fühlt sich schneller an als jede noch so gut optimierte Ladeanimation. Weil die Regeln rein deklarativ im Markup stehen und ohne Umbau der bestehenden Seite auskommen, gehören sie zu den effizientesten Bausteinen einer gezielten Frontend-Optimierung -- vorausgesetzt, Eagerness, Ausschlüsse und Consent sind mit Augenmaß gesetzt. Wie schnelle Navigation und Ladezeit auf Conversion und Umsatz wirken, vertieft unser Beitrag zum Zusammenhang von Ladezeit, Conversion-Rate und Umsatz; wie sich Tempo und Ressourcenschonung verbinden lassen, zeigt der Beitrag zu nachhaltigen, performanten Websites.
Quellen und Studien