Speculation Rules und Prerendering: Was Analytics bei vorab geladenen Seiten falsch macht
Chromes Speculation Rules API kann eine Seite rendern, bevor ein Nutzer überhaupt klickt. Hier erfahren Sie, wie das naive Analytics verzerrt — und wie cookiefreie, edge-basierte Messung ehrlich bleibt.
Die Seite, die vor dem Klick geladen wurde
Die Speculation Rules API, mittlerweile breit in Chromium-Browsern verfügbar, erlaubt es einer Website zu deklarieren, welche URLs der Browser im Vorfeld einer Navigation prefetchen oder vollständig prerendern soll. Wenn ein Nutzer mit der Maus über ein Element fährt oder Absicht signalisiert, kann das Ziel bereits in einem versteckten Tab gerendert und dann sofort eingeblendet werden. Der Gewinn ist ein nahezu Null-Wert beim Largest Contentful Paint bei der Aktivierung. Das Problem für die Messung ist, dass eine vorab gerenderte Seite Ihre Skripte ausführt, bevor überhaupt jemand entschieden hat, sie zu besuchen.
Wenn Ihr Analytics einen Pageview beim Laden auslöst, bläht Prerendering Ihre Zahlen mit Besuchen auf, die nie stattgefunden haben. Schlimmer noch: Es verzerrt Performance-Daten — eine im Hintergrund vorab gerenderte Seite erfasst Zeiten, die in keinem Verhältnis zu dem stehen, was ein echter Nutzer erlebt hat.
Was während des Prerenderings tatsächlich passiert
Ein vorab gerendertes Dokument wird normal ausgeführt, aber in einem besonderen Lebenszyklus-Zustand. document.prerendering ist true, und die Seite wurde noch nicht in den sichtbaren Tab aktiviert. Das prerenderingchange-Event wird ausgelöst, wenn — und nur wenn — der Nutzer tatsächlich dorthin navigiert. Viele Prerenders werden überhaupt nie aktiviert; der Browser kann sie verwerfen.
Das ist aus zwei Gründen wichtig:
- Zählung. Ein naives
sendBeaconbeiDOMContentLoadedmeldet einen Pageview für ein Dokument, das möglicherweise nie gesehen wird. - Performance-Zuordnung. Core Web Vitals sind relativ zum vom Nutzer wahrgenommenen Laden definiert. Die web-vitals-Bibliothek und die zugrunde liegenden Paint-Timing- und Event-Timing-Spezifikationen berücksichtigen Prerendering, indem sie ab dem Aktivierungspunkt messen und nicht ab dem ursprünglichen Navigationsstart. Eine ohne dieses Bewusstsein erfasste Metrik ist schlicht falsch.
Das korrekte Muster
Die Web-Plattform liefert Ihnen saubere Signale. Verschieben Sie jede Messung, bis die Seite für eine Person tatsächlich sichtbar ist:
if (document.prerendering) {
document.addEventListener('prerenderingchange', recordPageview, { once: true });
} else {
recordPageview();
}
Für das Timing liefert PerformanceNavigationTiming.activationStart den Versatz zwischen Navigationsstart und Aktivierung. Jeder Paint- oder Interaktions-Zeitstempel sollte relativ zu diesem Wert gemessen werden, wobei negative Werte auf null begrenzt werden. Genau das macht Googles web-vitals-Bibliothek intern — wenn Sie LCP oder INP also selbst berechnen, bilden Sie diese Logik nach.
Dieselbe Disziplin gilt für Prefetch, den leichteren Verwandten des Prerenderings. Prefetch ruft nur die Antwort ab; es führt keine Skripte aus und verschmutzt daher selten direkt Ihr Analytics. Aber es verbraucht Bandbreite und kann serverseitige Request-Logs verzerren — eine Erinnerung daran, dass rohe Log-Zählungen und echte Besuche mehr denn je auseinanderdriften.
Warum das ohne Cookies oder Client-State einfacher ist
Spekulationsgetriebenes Prerendering ist ein Ärgernis für zustandsbehaftete Tracker. Ein vorab gerendertes Dokument, das Kennungen setzt, eine Session hydratisiert oder in den Speicher schreibt, tut dies spekulativ — für einen Besuch, der möglicherweise verworfen wird. Das aufzuräumen, gegen die letztendliche echte Aktivierung zu deduplizieren und die seitenübergreifende Identität abzugleichen, wird zu einer echten Fehlerquelle und einem Datenschutzrisiko.
Monoid umgeht diese gesamte Problemklasse. Wir speichern nichts auf dem Gerät — keine Cookies, kein localStorage, keinen Fingerprint. Es gibt keine spekulative Session, die erstellt und später wieder rückgängig gemacht werden müsste. Die Messung ist ein einziges, zustandsloses Signal, das wir erst aussenden, wenn die Seite real ist. Da die Erfassung am Cloudflare-Edge läuft, erfolgt die Aggregation auf Daten, die bereits echte, aktivierte Navigationen widerspiegeln und nicht die optimistischen Vermutungen eines Browsers.
Das ist Datenminimierung, die zu Ihren Gunsten arbeitet. Wenn Sie nichts erfassen, das aufgeräumt werden muss, erzeugt spekulatives Rendering keine verwaisten Identitätsdatensätze oder doppelten Profile. Es bedeutet einfach, dass Sie auf prerenderingchange warten, bevor Sie zählen.
Eine Checkliste für prerender-sicheres Analytics
- Steuern Sie die Pageview-Aussendung über
document.prerenderingund dasprerenderingchange-Event. - Berechnen Sie LCP, FCP und INP relativ zu
activationStart, oder verwenden Sie eine Bibliothek, die das bereits tut. - Behandeln Sie Server-Request-Logs als eine Obermenge echter Besuche, nicht als deren Stellvertreter.
- Stellen Sie sicher, dass Ihre Content-Security-Policy erlaubt, dass Ihr Mess-Endpunkt von einem aktivierten Dokument aus erreicht werden kann; testen Sie im Prerender-Bereich der Chrome DevTools.
- Vermeiden Sie jegliche spekulativen Schreibvorgänge in den Gerätespeicher — der sauberste Weg, prerender-korrekt zu sein, ist, überhaupt keinen Client-State zu halten.
Der größere Zusammenhang
Jede neue Performance-Primitive — bfcache, Soft Navigations und nun Speculation Rules — bricht still und leise die alte Annahme auf, dass ein Seitenaufruf einem menschlichen Besuch entspricht. Analytics, das sich auf Cookies und zustandsbehaftete Sessions stützt, muss immer mehr Abgleichslogik dranschrauben. Analytics, das ein zustandsloses Event im Moment der echten Sichtbarkeit misst, muss lediglich die Lebenszyklus-Events der Plattform respektieren. Schnellere Seiten und ehrliche Zahlen stehen nicht im Widerspruch zueinander; Sie müssen nur zum richtigen Zeitpunkt zählen.
Comments
Loading comments…