Prerender und Speculation Rules richtig messen 2026

Was beim Prerender im Browser wirklich passiert

Speculation Rules sind ein JSON-Regelwerk, das eine Seite entweder in einem script-Element mit dem Typ speculationrules oder über den HTTP-Header Speculation-Rules ausliefert. Zwei Stufen sind vorgesehen. prefetch holt lediglich das Zieldokument vorab. prerender geht deutlich weiter: Unterstützende Browser laden den Inhalt, rendern ihn und legen ihn in einem unsichtbaren Tab im speicherinternen Cache des Dokuments ab - einschließlich aller Subressourcen, der Ausführung des kompletten JavaScripts und sogar der Datenabrufe, die dieses JavaScript selbst startet (MDN Web Docs, Speculation Rules API). Für den Besucher entsteht dadurch beim Klick der Eindruck, die Seite sei bereits fertig gewesen.

Beim Klick tauscht der Browser den unsichtbaren Tab gegen die aktuelle Seite aus. Dieser Moment heißt Aktivierung - und genau hier trennen sich Technik und Messung. Zwischen dem Start des Prerenders und der Aktivierung können mehrere Sekunden liegen, in denen die Seite bereits vollständig läuft, ohne dass jemand sie sieht. Drei Bausteine machen diesen Zustand im Code sichtbar: die Eigenschaft document.prerendering, das Ereignis prerenderingchange, das beim Aktivieren feuert, und activationStart aus dem PerformanceNavigationTiming-Eintrag, das die Zeit zwischen Prerender-Start und Aktivierung angibt (MDN Web Docs, Speculation Rules API).

• Aufgeschobene Schnittstellen - Notifications, Geolocation, Kamera- und Mikrofonzugriff, Web Audio, Sensoren sowie ServiceWorkerRegistration.register() liefern im Vorab-Tab zunächst nur ein offenes Promise und laufen erst nach der Aktivierung weiter (MDN Web Docs).
• Blockierte Interaktionen - Vollbild, Window.open(), Zahlungsdialoge und Clipboard-Zugriffe scheitern, weil sie eine Nutzerinteraktion, Fokus oder Sichtbarkeit voraussetzen (MDN Web Docs).
• Stumme Dialoge - alert(), confirm() und prompt() kehren zurück, ohne etwas anzuzeigen (MDN Web Docs).
• Verzögerte Nebenwirkungen - Downloads starten erst nach der Aktivierung, Cross-Origin-Iframes werden erst dann geladen, sessionStorage arbeitet auf einem Klon und wird beim Aktivieren zurückgetauscht (MDN Web Docs).
• Abbruchgründe - eine Navigation auf eine andere Site verwirft den Prerender sofort, ebenso javascript:-, data:-, blob:- und about:-URLs (MDN Web Docs).

Was der Browser nicht zurückhält, ist gewöhnliches Analytics-JavaScript. Ein Zähl-Pixel, das beim Laden feuert, sendet seinen Treffer auch aus dem unsichtbaren Tab. Für die Auswertung heißt das: Die Seite gilt als aufgerufen, obwohl der Besucher möglicherweise weitergescrollt und den Link gar nicht geklickt hat. Diese Lücke ist kein Fehler des Browsers, sondern eine bewusste Entwurfsentscheidung - die Plattform stellt mit document.prerendering und prerenderingchange genau die Werkzeuge bereit, mit denen ein Skript sein Verhalten selbst steuern kann.

Um das Ausmaß der möglichen Ressourcenverschwendung einzuordnen: Ein Prerender verbraucht ungefähr so viele Ressourcen wie das Rendern eines Iframes.

— MDN Web Docs, Speculation Rules API (sinngemäß übersetzt)

Warum der Effekt seit Chrome 121 in der Breite ankommt

Prerender über Speculation Rules ist keine Neuheit: Chrome und Edge unterstützen die Regeln seit Version 109 (Chrome for Developers). Alltagstauglich wurde die Technik allerdings erst mit den Erweiterungen der folgenden Versionen. Chrome 121 brachte den Parameter eagerness und machte den Schlüssel source optional, ab Chrome 122 stand das vollständige Paket aus Dokumentregeln und abgestufter Eagerness bereit (Chrome for Developers). Chrome 136 ergänzte das Feld tag für die Unterscheidung mehrerer Regelsätze, Chrome 138 den target_hint für Ziele in neuen Tabs (Chrome for Developers). Erst Dokumentregeln erlauben die kurze Formulierung: nimm alle Links dieses Dokuments, außer diesen hier.

Die Verbreitung ist inzwischen erheblich. In den Messungen des Web Almanac 2025 liefern in den Top 1.000 Websites 3 Prozent der Desktop- und 5 Prozent der mobilen Seiten Speculation Rules aus; im Longtail der Top 10 Millionen sind es 24 Prozent auf dem Desktop und 35 Prozent auf mobilen Seiten (HTTP Archive Web Almanac 2025). Der Sprung erklärt sich vor allem aus dem Content-Management: WordPress liefert seit Version 6.8 spekulatives Laden standardmäßig im Frontend aus, konfiguriert als prefetch mit der Eagerness-Stufe conservative; ausgenommen sind angemeldete Nutzer und Installationen ohne sprechende Permalinks (WordPress Core, Speculative Loading in 6.8).

Wer diese Voreinstellung von Prefetch auf Prerender hebt - im CMS über einen Filter, im eigenen Code über eine Zeile im Regelwerk -, verändert die Datenlage schlagartig. Und selbst ohne eigenes Regelwerk entstehen vorgerenderte Aufrufe: Chrome rendert Seiten aus der Adressleiste heraus vor, wenn die Vorhersage auf Basis des bisherigen Verlaufs sehr zuverlässig erscheint, ebenso beim Zeigen auf einen Eintrag der Lesezeichenleiste und bei Suchergebnisseiten, wenn die Suchmaschine das anweist (Chrome for Developers). Gleichzeitig bleibt Prerender ein Hinweis und kein Befehl: Der Browser kann ihn wegen Nutzereinstellungen, Speicherdruck oder eigener Heuristiken übergehen (Chrome for Developers).

Wie Prerender die Messung verzerrt

Die Verzerrung tritt in vier typischen Ausprägungen auf. Sie treffen unterschiedliche Kennzahlen, haben aber dieselbe Ursache: Ein Ereignis wird zum Zeitpunkt der Vorbereitung erfasst statt zum Zeitpunkt der Betrachtung. Wer die Fehlerbilder kennt, erkennt sie in den eigenen Daten deutlich schneller - ähnlich wie beim automatisierten Verkehr, der ohne Filterung dieselben Berichte verwässert und den wir im Beitrag zum Filtern von Bot-Traffic aus Analytics im Detail beschreiben.

Ein Rechenbeispiel macht die Größenordnung greifbar: Meldet ein Zähler an einem Tag 1.000 Seitenaufrufe und wurden 220 davon in einem Vorab-Tab erzeugt, der nicht aktiviert wurde, sind nur 780 Aufrufe tatsächlich gesehen worden - 22 Prozent der gemeldeten Zahl waren reine Vorbereitung (Beispielwerte zur Veranschaulichung). Wie hoch der Anteil real ausfällt, hängt vollständig vom Regelwerk, von der Eagerness-Stufe und vom Nutzerverhalten ab. Verlässlich ist nur die Richtung: Ohne Korrektur meldet der Zähler mehr, als jemand gesehen hat.

Tracker bis zur Aktivierung verzögern

Die saubere Lösung besteht nicht darin, Prerender zu vermeiden, sondern darin, die Messung an die Aktivierung zu koppeln. Das Muster ist kurz: Läuft das Dokument im Prerender-Zustand, wird die Messung an das Ereignis prerenderingchange gehängt und dort genau einmal gestartet; läuft es normal, startet sie sofort. Skripte, die diesen Zustand nicht kennen, zählen andernfalls im Vorab-Tab mit (MDN Web Docs, Speculation Rules API).

function startMeasurement() {
  // Seitenaufruf, Sitzungsstart, Ziel-Ereignisse
}

if (document.prerendering) {
  document.addEventListener('prerenderingchange', startMeasurement, { once: true });
} else {
  startMeasurement();
}

Für die Auswertung ist zusätzlich interessant, ob eine Seite überhaupt vorgerendert wurde. Diese Information liefert activationStart: Ein Wert größer als null bedeutet, dass zwischen Prerender-Start und Aktivierung Zeit vergangen ist. In Kombination mit document.prerendering ergibt das eine belastbare Erkennung, die auch dann funktioniert, wenn das Skript erst nach der Aktivierung ausgeführt wird (MDN Web Docs, Speculation Rules API).

const nav = performance.getEntriesByType('navigation')[0];
const activation = nav ? nav.activationStart : 0;
const wasPrerendered = document.prerendering || activation > 0;

const navigationType = wasPrerendered
  ? 'prerender'
  : (nav ? nav.type : 'navigate'); // navigate | reload | back_forward

1. Seitenaufruf - erst nach der Aktivierung senden, nicht beim Laden des Dokuments.
2. Sitzungsstart - an dieselbe Bedingung koppeln, sonst beginnt die Sitzung im unsichtbaren Tab und die Verweildauer startet zu früh.
3. Ziel-Ereignisse - Bestell-, Formular- und Lead-Signale ausschließlich nach der Aktivierung auslösen, damit keine Doppelzählung entsteht.
4. Ereignisse im Vorab-Tab - falls Sie sie brauchen, zwischenspeichern und nach der Aktivierung mit dem korrekten Zeitstempel nachreichen.
5. Serverseitig - Zugriffe mit gesetztem Sec-Purpose-Header in Logauswertungen getrennt führen, statt sie in die Reichweite zu rechnen.
6. Nach jedem Deploy prüfen - eine geänderte Skriptversion kann die Verzögerung stillschweigend entfernen; ein wiederkehrender Browser-Check mit echtem Seitenaufbau macht das sichtbar.

Web Vitals auf die Aktivierung beziehen

Prerender verbessert die wahrgenommene Geschwindigkeit real. Die Chrome-Dokumentation beschreibt als Effekt einen LCP nahe null, geringeres CLS - weil Layoutverschiebungen des Ladevorgangs vor der ersten Ansicht stattfinden - und ein verbessertes INP (Chrome for Developers). Genau deshalb braucht die Messung einen definierten Nullpunkt. Ohne Korrektur wird die Zeit ab dem Prerender-Start gemessen, und die Kennzahl beschreibt nicht mehr, wie lange jemand gewartet hat, sondern wie lange der Browser vorgearbeitet hat.

const nav = performance.getEntriesByType('navigation')[0];
const activation = nav ? nav.activationStart : 0;

// LCP-Eintrag relativ zur Aktivierung bewerten
const lcpAfterActivation = Math.max(0, lcpEntry.startTime - activation);

// Dasselbe Prinzip gilt für FCP, TTFB und alle eigenen Marken
const ttfbAfterActivation = Math.max(0, nav.responseStart - activation);

Der zweite Schritt ist wichtiger als die Formel: nicht mitteln, sondern trennen. Der Chrome UX Report weist Navigationstypen seit dem Datensatz 202403 aus, veröffentlicht am 9. April 2024 (Chrome UX Report, Release Notes). Wie stark ein Navigationstyp die Aggregate bewegt, zeigt der Präzedenzfall Back-Forward-Cache: Mit dem breiten Rollout in Chrome 97 verbesserte sich die Bestehensquote für CLS um 4,4 Prozent und für LCP um 2,4 Prozent (Chrome UX Report, Release Notes, Datensatz 202201). Ein wachsender Prerender-Anteil verschiebt Durchschnitte auf dieselbe Weise - nach oben, ohne dass sich die Seite selbst verbessert hätte.

In der Praxis heißt das: Ein Performance-Bericht braucht mindestens die Zeile für reguläre Erstaufrufe getrennt von allen beschleunigten Typen. Wie sich Feld- und Labormessung dabei ergänzen, ist im Beitrag zu Felddaten gegen Labordaten bei Core Web Vitals beschrieben; wo genau die Ladezeit eines Erstaufrufs verloren geht, zeigt die Aufschlüsselung in LCP-Subparts von TTFB bis Render-Delay. Für Anwendungen mit clientseitigem Routing kommt die Frage hinzu, wie Ansichtswechsel überhaupt erfasst werden - dazu der Beitrag zu Core Web Vitals in Single-Page-Apps.

Trefferquote und Wirkung je Navigationstyp auswerten

Sobald die Zählung aktivierungsbasiert arbeitet, wird Prerender von einer Fehlerquelle zu einer Kennzahl. Interessant ist nicht nur, wie viele Navigationen vorgerendert ankamen, sondern auch, wie viele Spekulationen ins Leere liefen. Beide Seiten zusammen ergeben die Trefferquote - und damit die Antwort auf die Frage, ob das Regelwerk gut eingestellt ist oder Bandbreite verbrennt.

• Prerender-Anteil - Anteil der aktivierten Prerender an allen gemessenen Navigationen. Steigt er, wirkt die Seite für wiederkehrende Besucher schneller.
• Trefferquote - aktivierte Prerender geteilt durch die Zahl der spekulativen Anfragen aus dem Serverlog (Sec-Purpose). Eine niedrige Quote bedeutet: viel Vorbereitung, wenig Nutzen.
• LCP-Delta je Typ - Median-LCP der regulären Erstaufrufe gegen den aktivierungskorrigierten Median der Prerender-Aufrufe. Das ist der ehrliche Gewinn.
• INP je Typ - Interaktionslatenz getrennt auswerten, weil ein vorgerendertes Dokument beim ersten Klick bereits initialisiert ist.
• Verschwendungsquote - übertragene Bytes für nicht aktivierte Spekulationen, aufgeschlüsselt nach Geräteklasse.
• Einstiegsseiten - Verteilung der aktivierten Prerender über die Seitentypen; häuft sich alles auf wenigen URLs, ist das Regelwerk zu eng oder zu weit gefasst.

Die Auswertung lohnt sich vor allem im Zeitverlauf. Ein Regelwerk, das bei der Einführung eine gute Quote erreicht, kann nach einem Navigations-Relaunch deutlich schlechter dastehen, weil andere Links im Sichtbereich liegen. Ein wiederkehrender Bericht, der Navigationstypen getrennt ausweist, macht solche Verschiebungen sichtbar, ohne dass jemand täglich in die Rohdaten schaut - dafür eignen sich terminierte Reports und Statusseiten, die den Stand automatisch zusammenfassen.

Fehlzählungen erkennen: Signale in den Rohdaten

Nicht jede Website kann das Messskript sofort umstellen. Bis dahin hilft eine Diagnose auf Basis der vorhandenen Daten. Prerender hinterlässt charakteristische Spuren, weil ein Aufruf ohne Betrachter zwangsläufig ohne jede Folgeinteraktion bleibt. Die folgenden Signale treten selten allein auf - kommen zwei oder drei zusammen, ist der Verdacht begründet.

• Seitenaufrufe mit null Sekunden aktiver Zeit - kein Scroll, kein Klick, kein Sichtbarkeitswechsel, und das gehäuft auf denselben URLs (Projekterfahrung).
• Sprunghafte Absprungrate ohne Anlass - die Quote steigt an dem Tag, an dem ein Regelwerk oder ein CMS-Update ausgerollt wurde (Projekterfahrung).
• Doppelte Ziel-Signale - dieselbe Bestell- oder Formularbestätigung erscheint zweimal mit kurzem Abstand.
• Missverhältnis zwischen Log und Zähler - der Webserver meldet deutlich mehr Zugriffe mit Sec-Purpose als der Zähler an Prerender-Aufrufen ausweist.
• Einstiege auf tiefen Seiten ohne Referrer - Zielseiten, die im Regelwerk stehen, tauchen als Einstieg auf, obwohl sie im Menü kaum verlinkt sind.
• LCP-Verteilung mit zwei Gipfeln - ein Gipfel nahe null, ein zweiter im realistischen Bereich; ein starker Hinweis auf unkorrigierte Aktivierungszeiten.

Ein praktischer Zwischenschritt: Führen Sie zwei Wochen lang eine zusätzliche Eigenschaft am Seitenaufruf mit, die den erkannten Navigationstyp enthält, ohne die bestehende Zählung zu verändern. So entsteht eine Vergleichsbasis, bevor Sie die eigentliche Umstellung vornehmen. Der Aufwand liegt bei wenigen Zeilen, der Erkenntnisgewinn ist deutlich größer als jede Schätzung.

Ressourcenkosten: Eager-Regeln nicht ungebremst setzen

Jede Spekulation kostet zweimal: Bandbreite beim Besucher und Rechenzeit auf Ihrem Server. Die Chrome-Dokumentation formuliert das deutlich - Prerendering verbraucht zusätzlichen Speicher und zusätzliche Netzwerkbandbreite, und man solle darauf achten, nicht zu viel vorzurendern (Chrome for Developers). Die Lernressourcen von web.dev empfehlen, Prerender sparsam einzusetzen und nur dann, wenn die Navigation zum Ziel recht wahrscheinlich ist; Prefetch sollte auf schnellen Verbindungen bleiben und bei gesetztem Save-Data-Signal unterbleiben (web.dev, Learn Performance).

Die Obergrenzen stammen aus der Chrome-Dokumentation; nach dem Erreichen einer Grenze verwirft der Browser die älteste Spekulation zugunsten der neuen (Chrome for Developers). Das begrenzt den Schaden, hebt ihn aber nicht auf: Zehn parallele Prerender entsprechen in der Größenordnung zehn zusätzlich gerenderten Iframes (MDN Web Docs, Speculation Rules API). Auf Mobilgeräten mit begrenztem Datenvolumen und auf Servern mit teuren, personalisierten Seiten ist das ein spürbarer Posten.

Regelwerk sauber aufsetzen: Ausschlüsse und Randfälle

Ein gutes Regelwerk ist kurz und besteht größtenteils aus Ausnahmen. Dokumentregeln erlauben, alle Links einzuschließen und einzelne Muster auszunehmen - über href_matches für Pfade und selector_matches für CSS-Selektoren. Damit lassen sich Bereiche markieren, die grundsätzlich nicht spekulativ geladen werden sollen, ohne jede URL einzeln pflegen zu müssen (MDN Web Docs, Speculation Rules API).

{
  "prerender": [
    {
      "eagerness": "moderate",
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/logout*" } },
          { "not": { "href_matches": "/*\\?*(^|&)add-to-cart=*" } },
          { "not": { "href_matches": "/konto/*" } },
          { "not": { "selector_matches": ".no-prerender" } },
          { "not": { "selector_matches": "[rel~=nofollow]" } }
        ]
      }
    }
  ]
}

• Zustandsändernde Pfade ausschließen - Abmelden, Warenkorb, Bestellbestätigung, Freigabe- und Löschaktionen.
• Personalisierte Bereiche ausnehmen - Konto, Kundenportal und alles, was pro Nutzer gerendert wird und teure Abfragen auslöst.
• Markierung im Markup - eine Klasse wie .no-prerender an kritischen Links spart spätere Pfadlisten und überlebt Relaunches besser.
• Content-Security-Policy beachten - enthält die Seite eine script-src-Direktive, muss die Quelle 'inline-speculation-rules', ein Hash oder eine Nonce ergänzt werden, sonst wird das Regelwerk verworfen (MDN Web Docs).
• Cross-Origin-Fälle - Prerender ist standardmäßig auf denselben Origin beschränkt; same-site übergreifend braucht das Ziel den Header Supports-Loading-Mode: credentialed-prerender (MDN Web Docs).
• Feature-Erkennung - HTMLScriptElement.supports('speculationrules') prüft die Unterstützung, bevor Regeln dynamisch eingefügt werden (MDN Web Docs).

Messen, was gesehen wurde - nicht, was der Browser vorbereitet hat

Alle beschriebenen Korrekturen laufen auf denselben Punkt hinaus: Ein Seitenaufruf zählt ab der Aktivierung, nicht ab dem Rendern. Genau so arbeitet die cookielose First-Party-Analytics von XICTRAQ - der Zähler startet, wenn das Dokument aktiv wird, und der erkannte Navigationstyp wird am Aufruf mitgeführt, statt in einem Durchschnitt zu verschwinden. Web Vitals werden aus dem Feld erhoben und auf den Aktivierungszeitpunkt bezogen, damit ein vorbereiteter Aufruf die Verteilung nicht künstlich verschönert.

Der Betrieb bleibt dabei überschaubar. Ein Tracking-Skript aus der eigenen Domain, ein Regelwerk mit klaren Ausschlüssen und ein Bericht, der Navigationstypen getrennt ausweist - mehr braucht es für belastbare Zahlen nicht. Wer Nachweise ohnehin dokumentiert, etwa für die NIS2-Registrierung beim BSI und die Pflichten der Geschäftsleitung, kennt das Prinzip: Eine nachvollziehbare Messung ist weniger Aufwand als eine nachträgliche Rekonstruktion. Dieselbe Deploy-Disziplin gilt für Pflichtelemente im Frontend, etwa die Kennzeichnung von KI-Chatbots nach dem AI Act - was ein Deploy still entfernen kann, gehört regelmäßig geprüft.

Prerender wird nicht verschwinden, im Gegenteil: Schnelle Navigationen sind ein sichtbarer Qualitätsvorteil, und Content-Management-Systeme liefern die Regeln inzwischen mit (HTTP Archive Web Almanac 2025). Die Frage ist deshalb nicht, ob Sie mit Prerender zu tun haben, sondern ob Ihre Zahlen die Technik abbilden. Ein Blick in die Live-Demo zeigt, wie eine aktivierungsbasierte Auswertung im Alltag aussieht; die Tarifübersicht fasst zusammen, welche Auswertungen in welchem Umfang enthalten sind. Und wenn Sie einen Beleg für die eigene Datenlage brauchen: Die cookielose Analytics-Funktion weist gemeldete und aktivierte Aufrufe nebeneinander aus.

Häufig gestellte Fragen zu Prerender und Messung