Speculation Rules API 2026: Prerender-Guide

Warum die Speculation Rules API 2026 zum wichtigsten Performance-Hebel wird

Klickt ein Nutzer auf einen Link, vergehen typischerweise zwischen 800 ms und 3 Sekunden, bis die nächste Seite vollständig sichtbar ist. Der Großteil dieser Zeit ist reine Wartezeit – DNS-Lookup, TCP-Handshake, TTFB, HTML-Parsing, render-blockierendes CSS und JavaScript. Die Speculation Rules API dreht dieses Modell komplett um. Statt erst nach dem Klick zu laden, lädt der Browser die wahrscheinlich nächste Seite bereits, während der Nutzer noch auf der aktuellen Seite ist – und rendert sie sogar fertig. Das Ergebnis fühlt sich an wie ein Tab-Wechsel, nicht wie eine Navigation.

Seit Chrome 109 ist die API stabil. Mit den Updates in Chrome 143 (Januar 2026, neue Mobile-Heuristik) und dem Chrome 144 Origin Trial für „prerender until script" ist das Tooling 2026 endlich produktionsreif – und gleichzeitig flexibel genug, um typische Stolperfallen wie doppelt feuernde Analytics oder unerwünschte Side-Effects zu vermeiden. Ehrlich gesagt: Wenn man das einmal in Lighthouse oder CrUX gesehen hat, will man nicht mehr zurück. Dieser Leitfaden zeigt, wie Sie die API von Grund auf implementieren, welche Parameter wirklich zählen und wie Sie messen, ob die Spekulation tatsächlich Performance bringt.

Was die Speculation Rules API genau macht

Die API ist ein deklarativer JSON-basierter Mechanismus, mit dem Sie dem Browser mitteilen, welche URLs er spekulativ vorbereiten darf. „Spekulativ" heißt: Der Browser handelt auf eigene Rechnung, lange bevor klar ist, ob der Nutzer wirklich klickt. Dabei stehen drei Eskalationsstufen zur Verfügung – jede mit anderem Kosten/Nutzen-Profil.

Die drei Strategien im Vergleich

Prefetch: Der Browser holt nur das HTML-Dokument der Zielseite. Subressourcen, JavaScript und Rendering passieren erst beim tatsächlichen Klick. Niedrigste Kosten, moderater Nutzen (typisch –200 bis –400 ms LCP bei der Folgenavigation).
Prerender: Der Browser lädt das Dokument und rendert es vollständig in einem unsichtbaren Hintergrund-Tab – inklusive aller Subressourcen, CSS, JavaScript, Fonts und Bilder. Bei Aktivierung erscheint die Seite instant (LCP < 100 ms). Höchste Kosten, höchster Nutzen.
Prerender until script (Chrome 144 Origin Trial): der Mittelweg. Holt das Dokument, fängt mit dem Rendering an, lädt CSS/Bilder/Fonts – pausiert aber bei <script>-Tags, bis der Nutzer wirklich navigiert. Verhindert das Auslösen von Analytics, A/B-Tests, Tracking-Pixeln und teurem JS-Code für Seiten, die nie besucht werden.

Was passiert bei einem Prerender unter der Haube?

Beim Prerender öffnet Chrome einen separaten Renderer-Prozess für ein verstecktes Dokument. Dieses Dokument durchläuft den kompletten Lebenszyklus: HTTP-Request, HTML-Parsing, CSS-Berechnung, JavaScript-Ausführung, Layout, Paint. Allerdings setzt der Browser einen Flag, sodass die Seite weiß, dass sie im Prerender-Status läuft – über die document.prerendering-API. So lassen sich sensible Operationen (Analytics, Personalisierung, Login-Checks) bis zum tatsächlichen prerenderingchange-Event verzögern. Genau dort liegt die Kunst der ganzen Sache.

Implementierung: Der minimale Einstieg in 5 Minuten

Der einfachste Weg ist ein <script>-Tag mit dem Typ speculationrules direkt im HTML. Platzieren Sie das folgende Snippet im <head> oder <body> – beides funktioniert.

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "href_matches": "/*"
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

Diese Regel weist Chrome an: „Sobald der Nutzer 200 ms über einen Link auf der eigenen Domain hovert (oder ihn auf Mobile berührt), prerendere die Zielseite." Mit dieser einen Regel sehen typische MPA-Sites (E-Commerce, News, Blogs) eine LCP-Verbesserung von 60–80 % bei Folgenavigationen. Die initiale Seite bleibt unverändert – das ist wichtig zu verstehen.

Strukturierte Listen statt Pattern-Matching

Wenn Sie nur ausgewählte URLs vorhersagen wollen – etwa basierend auf Analytics-Daten der häufigsten Klickpfade –, nutzen Sie die list-Quelle:

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "list",
      "urls": [
        "/produkte/bestseller",
        "/warenkorb",
        "/checkout"
      ]
    }
  ],
  "prefetch": [
    {
      "source": "list",
      "urls": [
        "/kategorie/herren",
        "/kategorie/damen",
        "/sale"
      ]
    }
  ]
}
</script>

Hier kombinieren wir beide Strategien: Die Top-3-Conversion-Pfade werden voll prerendered, sekundäre Kategorien nur als HTML vorgeladen. So bleiben Bandbreite und CPU im Rahmen, während die wichtigsten Übergänge instant wirken. Persönlich finde ich diesen hybriden Ansatz fast immer besser als ein reines Pattern-Match – man behält die Kontrolle und vermeidet Bandbreitenexzesse auf Long-Tail-Seiten.

Der eagerness-Parameter: Aggressivität feinsteuern

Die eagerness-Einstellung entscheidet, wann Chrome das Spekulieren beginnt. Falsche Wahl bedeutet entweder verschwendete Bandbreite oder verpasste Performance-Chancen. Hier liegt der Teufel im Detail.

Die vier Stufen im Überblick

immediate: Sofort beim Parsen der Regel. Nur für absolut sichere Vorhersagen (z. B. „nach dem Login folgt immer das Dashboard"). Limit in Chrome: 50 Prefetches, 10 Prerenders.
eager: Auf Desktop nach 10 ms Hover. Auf Mobile (seit Chrome 143, Januar 2026) startet die Spekulation 50 ms nachdem ein Link in den Viewport scrollt – eine bewusste Anpassung, weil mobile Geräte kein Hover kennen. Gleiches Limit wie immediate.
moderate: 200 ms Hover oder pointerdown. Auf Mobile aktiviert durch pointerdown. Empfohlener Default für die meisten Sites. Limit: 2 Prefetches, 2 Prerenders gleichzeitig (FIFO).
conservative: Erst bei pointerdown/touchstart – also unmittelbar vor dem Klick. Spart maximal Bandbreite, gewinnt aber meist nur 50–150 ms.

Die richtige Wahl pro Use-Case

Site-Typ	Empfehlung	Begründung
News / Blog	`moderate` mit Pattern-Match	Hohe Klickrate auf Artikel-Karten, Hover-Signale zuverlässig
E-Commerce PLP → PDP	`moderate` + `list` für Top-Kategorien	Bandbreite schonen, Conversion-Pfade priorisieren
Checkout-Flow	`immediate` mit `list`	Nächster Schritt ist deterministisch bekannt
SaaS-Dashboard	`conservative` oder verzichten	SPA, Personalisierung, hohe Backend-Kosten

Chrome 144 Origin Trial: prerender until script

Das größte Problem von klassischem Prerender war bisher, dass JavaScript in der Hintergrundseite vollständig ausgeführt wurde. Das hieß: Analytics-Pageviews feuerten, A/B-Test-Allokationen passierten, Personalisierungs-API-Calls liefen los – auch dann, wenn der Nutzer am Ende nie wirklich auf die Seite kam. Das Resultat? Verzerrte Metriken und unnötiger Backend-Load.

Chrome 144 (Februar 2026) führt im Origin Trial die prerender until script-Stufe ein. Das Verhalten:

HTML-Dokument wird wie bei Prefetch geladen.
HTML-Parser startet, CSS und Bilder werden geholt.
Sobald der Parser auf einen <script>-Tag stößt (inline oder src), pausiert er.
Erst beim tatsächlichen Klick wird der Parser fortgesetzt und JavaScript ausgeführt.

So bekommen Sie 80 % der Prerender-Performance (alle visuellen Subressourcen sind warm im Cache), ohne die Side-Effects. Aktivierung im Origin Trial:

<meta http-equiv="origin-trial" content="IHR_TOKEN_HIER">
<script type="speculationrules">
{
  "prerender": [
    {
      "where": { "href_matches": "/blog/*" },
      "eagerness": "moderate",
      "target_hint": "_self"
    }
  ]
}
</script>

Defensive Coding: document.prerendering korrekt nutzen

Auch ohne den Origin Trial können Sie heute schon sicher prerendern – wenn Ihr JavaScript prerender-bewusst geschrieben ist. Die zentrale API ist document.prerendering und das prerenderingchange-Event.

// Pattern: Analytics nur nach Aktivierung feuern
if (document.prerendering) {
  document.addEventListener('prerenderingchange', () => {
    initAnalytics();
    sendPageview();
  }, { once: true });
} else {
  initAnalytics();
  sendPageview();
}

Dieses Muster gilt für alles, was Side-Effects auslöst: Pageview-Tracking (GA4, Plausible, Matomo), A/B-Test-Variant-Selection, Heatmap-Recorder, Personalisierungs-Bestimmung, In-App-Notifications. Ohne diesen Guard bekommen Sie ein verzerrtes Analytics-Bild und blasen Backend-Calls für Seiten auf, die nie aufgerufen werden. So einfach das aussieht – ich habe bei mehreren Projekten erlebt, dass dieser eine Schritt für sich genommen schon den größten Erfolg brachte.

Was im Prerender automatisch eingeschränkt ist

Chrome blockiert im Prerender-Status proaktiv viele riskante Operationen, um Side-Effects zu verhindern:

Permission-Requests (Notifications, Geolocation) werden verzögert
Audio/Video startet nicht automatisch
Service-Worker fetchEvent-Handler erhalten den Hinweis event.request.headers.get('Sec-Purpose')
Cross-Origin-Iframes werden aufgeschoben oder verworfen
window.alert, confirm, prompt werden ignoriert

Auslieferung per HTTP-Header

Wenn Sie Speculation Rules nicht in jedes HTML einbetten wollen – etwa weil Sie ein CDN nutzen oder die Regeln zentral managen –, lassen sich die Regeln auch per Response-Header ausliefern.

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Speculation-Rules: "/rules/site-prerender.json"

Die referenzierte Datei muss mit dem MIME-Type application/speculationrules+json ausgeliefert werden:

# nginx-Konfiguration
location = /rules/site-prerender.json {
  default_type application/speculationrules+json;
  add_header Cache-Control "public, max-age=3600";
}

Vorteil: Sie können Regeln cachen, regional ausspielen (über Edge-Logik) und ohne Deploy am HTML ändern. Nachteil: eine zusätzliche HTTP-Abfrage, falls die Datei noch nicht im Cache ist.

Performance-Kosten realistisch einschätzen

Speculation Rules sind kein Gratis-Feature. Jeder Prerender erzeugt einen kompletten Render-Prozess und läuft den vollen Seitenlebenszyklus durch. Das kostet:

Bandbreite: Ein durchschnittliches Seitendokument plus Subressourcen liegt 2026 bei ~2,3 MB. Bei 5 Prerenders sind das 11,5 MB – pro Nutzer-Session zusätzlich.
Server-Last: Jeder Prerender ist ein vollwertiger Request. Auf Backends mit teurer Personalisierung (DB-Joins, Empfehlungs-Engine) verdoppelt sich die Last leicht.
Client-CPU: Auf Low-End-Mobiles kann ein Hintergrund-Prerender den Main-Thread der aktuellen Seite blockieren – das verschlechtert dann den INP.

Chrome berücksichtigt das automatisch: Bei aktiviertem Save-Data-Modus, Energy-Saver-Modus oder bei deaktivierter „Preload pages"-Einstellung werden Speculation Rules vollständig ignoriert. Sie müssen also nicht selbst auf Connection-Type prüfen – aber Sie sollten Ihre Annahmen nicht auf Prerender stützen, da die Liefergarantie schlicht fehlt.

Wechselwirkung mit Core Web Vitals

Speculation Rules verändern Core Web Vitals auf eine subtile Weise: Sie verbessern Folgenavigationen, nicht den initialen Page-Load. Das wirkt sich so aus:

LCP: Bei vollem Prerender liegt der LCP der Folgeseite typischerweise bei 50–150 ms (statt 1.500–2.500 ms). Da der CrUX-Report alle Navigationen zählt, hebt das Ihren Site-LCP-P75 messbar.
INP: Hier ist Vorsicht geboten. Wenn Hintergrund-Prerenders während einer aktiven Interaktion laufen, kann der Main-Thread blockiert werden. Empfehlung: conservative oder moderate verwenden, nicht immediate.
CLS: Bei vollem Prerender ist CLS der Folgeseite oft 0, weil das Layout bereits final berechnet ist, bevor der Nutzer überhaupt klickt.

Debugging und Verifikation in den DevTools

Chrome DevTools haben einen dedizierten Bereich für Speculative Loads. So überprüfen Sie, ob Ihre Regeln greifen:

DevTools öffnen (F12).
Tab Application auswählen.
In der Seitennavigation: Background services → Speculative Loads → Speculations.
Die Tabelle zeigt jede spekulative URL, ihren Status (Ready, Failure, Triggered) und – im Fehlerfall – einen detaillierten Grund.

Häufige Fehler-Codes und ihre Bedeutung:

MojoBindingsInvalidated: Cross-Origin-Prerender ohne erforderlichen Header – meist ein Zeichen, dass Sie versehentlich auf eine andere Domain zeigen.
BlockedByClient: Eine Browser-Erweiterung (z. B. uBlock Origin) hat die Spekulation blockiert.
LowEndDevice: Chromes Heuristik hat das Gerät als zu schwach für Prerender eingestuft.
MemoryLimitExceeded: Bereits zu viele aktive Speculations.

Praktischer Implementierungs-Workflow

So gehen Sie eine echte Einführung an, ohne die Site zu destabilisieren:

Analytics auditieren: Identifizieren Sie alle Skripte mit Side-Effects (Pageview-Tracker, A/B-Tests, Heatmaps). Wrappen Sie sie in document.prerendering-Guards.
Mit Prefetch starten: Bevor Sie Prerender aktivieren, deployen Sie Prefetch-Regeln. Das ist risikoarm und liefert bereits 30–40 % der Performance-Vorteile.
Top-3-Pfade per Prerender: Aus den Analytics die häufigsten Klickziele extrahieren (typisch: Homepage → Kategorie, Kategorie → Produkt, Warenkorb → Checkout). Diese als list-basiertes Prerender deployen.
RUM messen: Mit der web-vitals-Bibliothek CrUX-Daten sammeln. onLCP, onINP und onCLS liefern Werte mit dem Attribut navigationType: "prerender" – so isolieren Sie den Effekt.
Eagerness anpassen: Falls Bandbreitenkosten zu hoch sind, von moderate auf conservative wechseln. Falls die Trefferquote zu niedrig ist, auf eager hochdrehen.
Origin Trial einplanen: Sobald „prerender until script" stabil wird (vermutlich Chrome 148, ca. Mai 2026), als Default-Strategie übernehmen.

Häufige Fehler und wie Sie sie vermeiden

Pageview-Tracking läuft mehrfach: Folge fehlender document.prerendering-Guards. Lösung siehe oben; bei GA4 reicht ein document.addEventListener('prerenderingchange', ...).
Login-Status falsch: Wenn Cookies erst nach der echten Navigation gesetzt werden, sieht die prerendered Seite einen veralteten Status. Lösung: Bei prerenderingchange die kritischen API-Calls erneut prüfen.
Cross-Origin-Prerender scheitert: Standardmäßig erlaubt die API nur Same-Origin. Für Cross-Origin braucht es das Supports-Loading-Mode: credentialed-prerender-Header auf der Zielseite.
Hohe Server-Last: Bei eager oder immediate mit breitem Pattern-Match generieren Sie unbeabsichtigt 5–10× mehr Backend-Traffic. Lösung: Server-seitig per Sec-Purpose: prefetch;prerender-Header billigere Antwortpfade nutzen (z. B. ohne A/B-Test-Variant-Selection).

FAQ – häufig gestellte Fragen

Was ist der Unterschied zwischen Speculation Rules API und dem alten `<link rel="prefetch">`?

Klassisches Prefetch über <link rel="prefetch"> lädt eine Ressource in den HTTP-Cache, ohne sie zu rendern – und ohne Eskalationsstufen oder Eagerness-Steuerung. Die Speculation Rules API ist deklarativ via JSON, unterstützt sowohl Prefetch als auch echtes Prerendering, hat eingebaute Eagerness-Heuristiken (Hover, Viewport, pointerdown), respektiert Save-Data und Battery-Saver automatisch und liefert detailliertes DevTools-Debugging. Für Folgenavigationen ist sie der klar überlegene Mechanismus.

Funktioniert die Speculation Rules API in Single-Page-Applications (SPAs)?

Nicht direkt. Die API zielt auf Dokument-Navigationen ab – also den Wechsel der gesamten Seite. In klassischen SPAs (React, Vue, Angular mit Client-Side-Routing) gibt's nur einen Dokumentenwechsel beim ersten Aufruf; danach werden Routen intern via history.pushState simuliert. Wenn Sie Speculation Rules in SPAs nutzen wollen, müssen Sie auf eine MPA-Architektur oder ein hybrides Modell wie Astro, Next.js (mit App Router) oder Remix wechseln, das echte Document-Transitions unterstützt.

Wie groß ist der Performance-Gewinn durch Prerender messbar?

Aktuelle Field-Daten 2025/2026 zeigen je nach Site und Eagerness:

LCP der Folgeseite: typisch –1.200 bis –2.000 ms (von ~2.500 ms auf 50–500 ms)
FCP der Folgeseite: nahe 0, da der erste Frame schon vor dem Klick gerendert ist
Conversion-Rate auf Checkout-Pfaden: +5 bis +12 %, dokumentiert von Shopify und mehreren E-Commerce-Plattformen

Werden Speculation Rules für SEO und Googlebot relevant?

Direkt nicht – Googlebot rendert Seiten ohne Prerendering, und Spekulationsregeln werden vom Crawler ignoriert. Indirekt aber sehr wohl: Google nutzt Core Web Vitals als Ranking-Signal, und CrUX-Daten umfassen alle realen Navigationen, einschließlich prerendered. Eine Site mit aggressivem Prerender hebt also ihren P75-LCP messbar – was sich indirekt positiv aufs Ranking auswirken kann.

Brauche ich eine Fallback-Strategie für Browser ohne Speculation-Rules-Unterstützung?

Ja, wenn Sie 100 % Coverage wollen. Chromium-Browser (Chrome, Edge, Opera, Brave, Samsung Internet) decken 2026 ~80 % des globalen Traffics ab. Firefox und Safari haben noch kein stabiles Shipping. Für nicht unterstützte Browser können Sie mit HTMLScriptElement.supports("speculationrules") erkennen und auf klassisches <link rel="prefetch"> zurückfallen. Da die API ein progressives Enhancement ist, schadet das Fehlen jedoch nichts – die Site funktioniert ganz normal, nur eben ohne den Speed-Bonus.

Fazit: Wann sich Speculation Rules sofort lohnen

Wenn Ihre Site eine klassische MPA ist – also Inhaltsseiten, E-Commerce, Blogs oder Dokumentationen mit echten Seitenwechseln –, ist die Speculation Rules API 2026 die einzelne Maßnahme mit dem höchsten Aufwand-zu-Wirkung-Verhältnis, die mir aktuell einfällt. Eine einzige <script type="speculationrules">-Zeile mit moderate-Eagerness verbessert das Folge-LCP der gesamten Site um 60–80 %. Mit ein paar zusätzlichen document.prerendering-Guards in Ihrem Analytics-Code stehen Sie sauber da und können den Performance-Sprung in Lighthouse, CrUX und in der echten Conversion-Rate messen.

Im nächsten Schritt empfehle ich, das in unserem Core Web Vitals 2026 Leitfaden beschriebene RUM-Setup zu implementieren – damit sehen Sie objektiv, ob Ihre Spekulationsregeln in der Realität die erwartete Wirkung entfalten.