Der Browser kann vor dem Nutzer ankommen: Speculation Rules sicher einführen

Ein Nutzer bewegt den Mauszeiger Richtung „Details“, klickt – und die nächste Seite ist praktisch sofort da. Genau dafür sind Speculation Rules gedacht: Der Browser kann wahrscheinliche nächste Dokumente vorab laden oder sogar vollständig prerendern.

Der Performance-Gewinn kann groß sein. Der Haken ist unsichtbar: Beim Prerendern kann eine Seite bereits JavaScript ausführen, Daten nachladen, Client-Speicher verändern und Requests auslösen, obwohl der Nutzer die Seite noch gar nicht gesehen hat.

Damit wird aus einer Performance-Optimierung eine Frage der Anwendungslogik. Wenn Pageviews, Warenkorb-Aktionen, Login-Zustand oder teure Backend-Abfragen an „Seite wurde geladen“ gekoppelt sind, kann der Browser Arbeit ausführen, bevor eine echte Navigation stattfindet.

Warum das 2026 genauer geprüft werden sollte

Chrome hat seine Eagerness-Heuristiken weiterentwickelt. eager verhält sich nicht mehr wie immediate: Auf Desktop wird seit Chrome 143 bereits nach sehr kurzem Hover spekuliert, auf Mobilgeräten verwendet Chrome seit Januar 2026 viewport-basierte Heuristiken. moderate und conservative warten auf stärkere Nutzersignale.

Gleichzeitig führt MDN die Speculation Rules API weiterhin als nicht Baseline und nur eingeschränkt browserübergreifend verfügbar. Die Funktion sollte deshalb als Progressive Enhancement gebaut werden: Wenn ein Browser nicht spekuliert, muss die normale Navigation vollständig korrekt bleiben.

Die richtige Frage lautet nicht: „Welche Seiten können wir prerendern?“ Sondern: „Welche Navigationen sind billig, sicher und wahrscheinlich genug, um vorgezogen zu werden?“

Prefetch und Prerender sind nicht dasselbe

Beim Prefetch wird ein zukünftiges Dokument vorab geladen. Das ist meist der risikoärmere Einstieg, kostet aber trotzdem Netzwerk und kann Backend-Requests erzeugen. Chrome empfiehlt komplexeren Websites ausdrücklich, zunächst mit Prefetch zu beginnen.

Prerender geht weiter: Der Browser lädt das Dokument samt Ressourcen und beginnt, die Seite in einem unsichtbaren Zustand auszuführen. JavaScript kann laufen und zusätzliche Requests starten. Eine prerenderte Seite ist deshalb nicht nur ein aggressiver Cache, sondern eher eine noch nicht sichtbare Instanz der nächsten Seite.

Red Flag 1: Ein GET verändert Zustand

Wenn Links wie /logout, /add-to-cart?id=42, /accept-invite oder /delete?item=7 schon beim Abruf Zustand verändern, kann spekulatives Laden diese Aktion auslösen, ohne dass der Nutzer bewusst geklickt hat.

Chrome nennt solche Fälle ausdrücklich als URLs, die nicht spekuliert werden sollten. Der eigentliche Fix liegt tiefer: Zustandsänderungen gehören nicht in vermeintlich harmlose GET-Navigationen.

Vor dem Rollout sollte deshalb inventarisiert werden:

• Welche GET-Routen verändern Daten oder Sessions?
• Lösen Query-Parameter serverseitige Aktionen aus?
• Starten Downloads, Exporte oder Generierungsjobs schon beim Seitenaufruf?
• Gibt es Logout-, Invite- oder Adminlinks, die Mutation und Navigation vermischen?

Ein Performance-Audit deckt hier oft gleichzeitig ein HTTP-Designproblem auf.

Red Flag 2: Analytics zählt Seiten, die niemand gesehen hat

Viele Tracking-Setups senden einen Pageview beim Initialisieren der Seite. Beim Prerendern ist „initialisiert“ aber nicht dasselbe wie „gesehen“.

MDN warnt davor, dass JavaScript während Prerendering Analytics, Ad Impressions oder andere Seiteneffekte auslösen kann. Dafür stehen unter anderem document.prerendering, prerenderingchange und PerformanceNavigationTiming.activationStart zur Verfügung.

Ein sauberer Rollout prüft deshalb:

• feuern Pageviews erst bei echter Aktivierung?
• werden Conversion- oder Impression-Events vorzeitig ausgelöst?
• verstehen Drittanbieter-SDKs Prerendering?
• können nicht kompatible Skripte bis nach Aktivierung verzögert werden?

Sonst wird die Navigation schneller und die Messung gleichzeitig schlechter.

Red Flag 3: Der sofort sichtbare Zustand ist schon veraltet

Stellen Sie sich vor, eine Kontoseite wird im ausgeloggten Zustand prerendert. In einem zweiten Tab meldet sich der Nutzer an und öffnet danach die bereits vorbereitete Seite. Oder der Warenkorb wird prerendert, bevor auf der aktuellen Seite noch ein Produkt hinzugefügt wird.

Ohne Revalidierung kann die schnelle Seite einen falschen Zustand zeigen. MDN beschreibt genau diese Risiken bei nutzerspezifischem und schnell veraltetem serverseitigem State.

Mögliche Gegenmaßnahmen sind:

• kritische Daten nach prerenderingchange gezielt revalidieren,
• Login-, Logout- oder Warenkorbänderungen zwischen Tabs propagieren,
• Spekulationen nach relevanten Zustandswechseln invalidieren,
• bei Bedarf Clear-Site-Data mit prefetchCache und prerenderCache einsetzen,
• sensible Seiten gar nicht oder erst bei stärkerem Nutzersignal prerendern.

Red Flag 4: Die „schnelle“ Seite verdoppelt Infrastrukturarbeit

Eine prerenderte Seite kann Ressourcen vollständig laden, obwohl die Navigation nie stattfindet. Bei statischen CDN-Seiten ist das oft günstig. Bei Dashboards, Suchseiten, Reports oder personalisierten Ansichten können dagegen Datenbank-, API- und Renderkosten entstehen.

Chrome warnt vor Over-Speculation, weil sie Bandbreite, Speicher und CPU beim Nutzer sowie Ressourcen auf der Website verbrauchen kann. Deshalb sollte jede Kandidatenseite auch nach Kostenklasse bewertet werden.

Günstig sind häufig statische Inhalte und gecachte Detailseiten. Teurer sind personalisierte Dashboards, komplexe Suche oder dynamische Reports. Endpoints mit Side Effects sollten überhaupt nicht spekuliert werden.

Eagerness ist eine Produktentscheidung

conservative wartet auf Pointer- oder Touch-Down. moderate reagiert auf deutlicheres Interesse wie längeren Hover. eager spekuliert früher; Chrome hat dieses Verhalten zuletzt verfeinert. immediate startet, sobald die Regel bekannt ist.

Je früher spekuliert wird, desto größer die Chance auf eine sofortige Navigation – und desto größer die Wahrscheinlichkeit verschwendeter Arbeit. Für geschäftliche Websites ist deshalb oft ein gestufter Rollout sinnvoll:

1. Prefetch für wahrscheinliche, günstige Ziele.
2. Prerender nur für wenige sichere Ziele.
3. Zunächst conservative oder moderate.
4. Erst nach Messung aggressiver werden.

Eine Allowlist ist leichter zu beherrschen

Bei Shops, SaaS und Portalen ist eine kleine positive Auswahl meist robuster als „alle internen Links außer …“.

Gute Kandidaten sind redaktionelle Artikel, Leistungsseiten, statische Produktinformationen und häufige Folgeansichten ohne personalisierten Zustand. Schlechte Kandidaten sind Logout, Checkout-Schritte, Warenkorb-Mutationen, Rollenwechsel, Exporte, Adminaktionen und teure Suchergebnisse.

So wächst nicht bei jeder neuen Funktion eine weitere Ausschlussregel.

CSP kann den Rollout still blockieren

Wer eine strikte Content Security Policy nutzt, muss Speculation Rules mitprüfen. Inline-Regeln über script type="speculationrules" unterliegen CSP-Anforderungen. MDN dokumentiert dafür unter anderem 'inline-speculation-rules', Nonces oder Hashes. Alternativ können Regeln über den Speculation-Rules-Response-Header auf externe JSON-Ressourcen verweisen.

Ein typischer Fehler ist deshalb: lokal funktioniert die Regel, in Produktion wird sie durch die ausgelieferte CSP blockiert. Entscheidend sind die echten Response-Header und Browsermeldungen, nicht nur der Quellcode.

Ein sinnvoller Rollout-Test

Ein einzelner Lighthouse-Lauf reicht nicht. Der Test muss Performance und Geschäftslogik verbinden.

Phase 1: Kandidaten nach Navigationswahrscheinlichkeit, Cachebarkeit, Backend-Kosten, Side Effects, Drittanbietern, Analytics sowie Session- und Consent-Abhängigkeit inventarisieren.

Phase 2: Mit wenigen Prefetch-Zielen beginnen und Trefferquote, zusätzliche Requests, Transfermenge, Origin-/API-Last und Fehler messen.

Phase 3: Nur Low-Risk-Ziele prerendern und bewusst Login/Logout in mehreren Tabs, Warenkorb, Consent, dynamische Preise, Widgets, Formulare und Echtzeitdaten testen.

Phase 4: Aktivierung instrumentieren. Mit document.prerendering, prerenderingchange und activationStart lässt sich zwischen normalem Laden, laufendem Prerender und aktivierter Prerender-Navigation unterscheiden.

Erst dann lässt sich beantworten, ob die gewonnene Geschwindigkeit den spekulativen Aufwand rechtfertigt.

Was Website-Pflichtencheck prüfen würde

Ein Speculation-Rules- und Prerender-Audit kann vorhandene Regeln und Eagerness, GET-Routen mit versteckten Mutationen, Logout-/Warenkorb-/Checkout-Pfade, Analytics und Conversion-Events, personalisierten State, Login- und Consent-Wechsel zwischen Tabs, Drittanbieter, Server-/API-/CDN-Kosten, CSP-Kompatibilität, Invalidierung nach Zustandsänderungen, Trefferquote und Fallback-Verhalten in anderen Browsern untersuchen.

Das Ziel ist nicht, möglichst viele Seiten im Voraus zu laden. Das Ziel ist, die richtige nächste Seite so früh wie sinnvoll vorzubereiten, ohne eine Handlung vorwegzunehmen, die der Nutzer noch gar nicht gemacht hat.

Speculative Loading ist dann eine starke Performance-Technik. Ohne Zustands- und Messkonzept kann es dagegen zu einem sehr schnellen Weg werden, die falsche Sache zur falschen Zeit auszuführen.