Wie stark bremst Session Replay die Website-Geschwindigkeit?

Bremst Session Replay die Website-Performance?

Session Replay, also die Wiedergabe aufgezeichneter Besuche, kostet eine Seite an drei Stellen, weshalb die Antwort auf "bremst Session Replay die Website-Performance" ja lautet: Skript-Bytes beim ersten Laden, Hauptthread-CPU für das Serialisieren von DOM-Mutationen und Upload-Bandbreite während des Besuchs. Wie groß jeder einzelne Posten wird, hängt vom Recorder, von der DOM-Größe der Seite und von der Sampling-Konfiguration ab. Sentry veröffentlicht einen datierten Benchmark samt Methodik, und diese Zahlen verorten die sichtbaren Kosten auf dem Hauptthread, nicht im Netzwerk.

Welche drei Kosten verursacht das Aufzeichnen einer Sitzung?

Ein Recorder belastet eine Seite einmal beim Laden und danach fortlaufend für den Rest des Besuchs. Die einmalige Belastung ist das Bundle, das heruntergeladen, geparst und ausgeführt wird, bevor es seinen ersten DOM-Snapshot machen kann. Die laufende Belastung teilt sich zwischen CPU, die Mutationsdatensätze in JSON-Ereignisse serialisiert, und Netzwerk, das diese Ereignisse in Batches hochlädt. Weil Session Replay einen Besuch aus DOM-Mutationen statt aus Videobildern rekonstruiert, skaliert die CPU-Zeile mit Ihrer Seite.

Wie groß ist ein Session-Replay-Skript?

Das Recorder-Bundle ist der einzige Teil, den ein Besucher bezahlt, bevor die Seite interaktiv wird. Bundlephobia misst @rrweb/record 2.1.4, die aufzeichnende Hälfte von rrweb, mit 23.262 Bytes gzipped und das vollständige rrweb-Paket samt Player mit 78.597 Bytes gzipped. Sentrys eigene Dokumentation hält fest, dass "as of version 7.78.0 the Session Replay plugin is an additional ~36KB gzipped" zusätzlich zum Error-SDK. Flowsery liefert ein Skript unter 10 KB. Laden Sie den gewählten Recorder asynchron, damit seine Bytes nie vor dem ersten Rendering liegen, und messen Sie den Vorher-nachher-Vergleich selbst in Lighthouse, statt einem Größen-Badge zu vertrauen.

Wie viel Hauptthread-Zeit kostet die DOM-Serialisierung?

Die CPU-Kosten konzentrieren sich auf den ersten vollständigen Snapshot und sinken danach für den Rest der Sitzung auf Arbeit pro Batch. rrweb registriert einen MutationObserver, weshalb der Guide festhält, dass rrweb "does not support IE11 and below because it uses the MutationObserver API"; diese API übergibt dem Recorder einen gesammelten Batch von Datensätzen, statt bei jeder DOM-Änderung einzeln auszulösen, sodass die Serialisierung batchweise läuft und nicht bei jeder Knotenberührung. Für den Snapshot gibt es veröffentlichte Zahlen: rrweb-Issue #1337 maß die Serialisierung eines vollständigen Snapshots mit durchschnittlich 34,55 ms auf einem Dokument aus tief verschachtelten divs und mit 27,35 ms nach dem Entfernen wiederholter closest()-Aufrufe.

Googles web.dev-Artikel zu Long Tasks definiert den Schwellenwert und die Rechnung:

blocking time = task duration - 50 ms

Ein Snapshot von 34,55 ms trägt daher 0 ms Blocking Time bei, denn "any task that takes longer than 50 milliseconds is a long task", und alles Kürzere zählt nicht. Snapshots auf deutlich größeren DOM-Bäumen überschreiten diese Linie, und rrwebs Tracker hat die Meldungen dazu: Issue #1547 berichtet, eine interne Prüfung "lags by 1 to 3 seconds on pages with lots of nodes", und Issue #1820 dokumentiert die Blockade des Hauptthreads, wenn ein Zendesk-Widget auf der Seite liegt. Kein öffentlicher Benchmark bildet die DOM-Knotenzahl auf Serialisierungs-Millisekunden ab, behandeln Sie also jede Anbieterangabe einer festen CPU-Zahl pro Seite als ungemessen.

Recorder können nicht dringende Arbeit in requestIdleCallback schieben, doch die W3C-Spezifikation deckelt jede Idle-Deadline "to a maximum value of 50ms", damit der Browser Luft behält, um Eingaben innerhalb des 100-ms-Fensters zu beantworten, das sich unmittelbar anfühlt. MDN warnt, dass ohne die Option timeout "it's possible multiple seconds will elapse before the callback is fired", Idle-Scheduling passt also zu Kompression und Upload, nicht zum Snapshot.

Wie viel Bandbreite lädt ein Session Replay hoch?

Sentrys Benchmark maß für sein Szenario einen Anstieg des Netzwerk-Uploads von 3,84 KB mit dem Error-SDK allein auf 272,51 KB mit aktiviertem Replay, während der Download bei 8,09 MB und 8,07 MB flach blieb. Der Upload ist der Posten, den Ihr Server und die Verbindung Ihres Besuchers gemeinsam tragen, und er skaliert linear mit den aufgezeichneten Sitzungen:

monthly replay upload = uploaded bytes per session x sessions per month

Bei Sentrys gemessenen 272,51 KB pro aufgezeichnetem Szenario und 50.000 Sitzungen im Monat sind das 13.625.500 KB, also rund 13 GB Upload. Textlastige Apps mit trägen DOMs landen unter diesem Wert, Canvas- oder animationslastige Apps darüber, und genau dafür gibt es rrwebs Storage-Rezept.

Verändert Session Replay die Core Web Vitals?

In Sentrys veröffentlichtem Lauf ließ Session Replay Largest Contentful Paint und Cumulative Layout Shift unberührt und bewegte die Total Blocking Time. Der Benchmark war "last updated on Sept 25, 2023" und lief "on an Apple M1 MacBook Pro against a remote preview server and a remote API backend with 50 iterations".

Total Blocking Time stieg zwischen dem Error-SDK und dem Replay-Build um 415,13 ms, und Sentry merkt an, eine einfachere Testseite "produced an increase of ~100 ms of total JS blocking time". Die Layout-Stabilität bewegte sich überhaupt nicht, was zur Funktionsweise der Metrik passt: Die Aufzeichnung liest das DOM, und Cumulative Layout Shift bewertet Bewegung darin. Ein M1-Laptop ist kein Android-Mittelklassehandy, und niemand hat denselben Benchmark auf schwacher Mobil-Hardware veröffentlicht, messen Sie also Core Web Vitals aus Ihren eigenen Felddaten, bevor Sie entscheiden, dass die Zahlen übertragbar sind.

Wie senken Sie den Session-Replay-Overhead, ohne das Replay zu verlieren?

Sampling entfernt die Ereignisse, die am meisten kosten und am wenigsten belegen. rrwebs Storage-Rezept empfiehlt mousemove: false, um Mausbewegung zu verwerfen, scroll: 150 für höchstens ein Scroll-Ereignis pro 150 ms, media: 800 für Medieninteraktion und input: 'last', um nur den Endwert eines getippten Feldes aufzuzeichnen, mit der Begründung, Sampling "can reduce the storage size by dropping some events". Über Sampling hinaus überspringt blockClass ganze Teilbäume, denn "an element with the class name .rr-block will not be recorded, instead it will replay as a placeholder", und slimDOMOptions entfernt DOM-Teile ohne Replay-Wert. Beginnen Sie mit mousemove und scroll auf Ihrer schwersten Seite und messen Sie dann erneut. Die Maskierung läuft im selben Serialisierungsdurchlauf, deshalb verändert Ihre Maskierungskonfiguration die CPU-Kosten ebenso wie die Datenschutzlage.

Häufig gestellte Fragen

Blockiert Session Replay das erste Rendering einer Seite?

Nicht, wenn der Recorder asynchron lädt, denn ein async-Skript liegt nicht im kritischen Pfad des Parsers. Nahe am ersten Rendering kann der initiale DOM-Snapshot landen, der nach dem Start des Recorders läuft und mit der Knotenzahl skaliert. Sentrys Benchmark zeigte Largest Contentful Paint bei 1529,11 ms mit aktiviertem Replay gegenüber 1599,19 ms ganz ohne SDK, das erste Rendering war in diesem Lauf also nicht der Druckpunkt.

Wie viel fügt das Recorder-Skript dem Seitengewicht hinzu?

Bundlephobia führt @rrweb/record 2.1.4 mit 23.262 Bytes gzipped und das vollständige rrweb-Bundle mit 78.597 Bytes gzipped, und Sentry dokumentiert sein Session-Replay-Plugin mit rund 36 KB gzipped zusätzlich zum Error-SDK. Flowserys Skript liegt unter 10 KB. Prüfen Sie die komprimierte Übertragungsgröße im Netzwerk-Panel Ihres Browsers, denn unkomprimierte Zahlen überzeichnen, was ein Besucher herunterlädt.

Erhöht Session Replay den Datenverbrauch eines Besuchers?

Ja, auf der Upload-Seite. Sentry maß 272,51 KB Upload für sein Benchmark-Szenario mit aktiviertem Replay gegenüber 3,84 KB mit dem Error-SDK allein, während das Download-Volumen sich nicht bewegte. Besucher mit getakteten Mobilverbindungen zahlen diesen Upload, und das ist das stärkste Argument dafür, mousemove aus dem Strom zu sampeln.

Warum kostet Session Replay auf manchen Seiten mehr CPU als auf anderen?

Die Serialisierungsarbeit ist eine Funktion von DOM-Knotenzahl und Mutationsrate, nicht von Seitenaufrufen. Ein Dashboard, das bei jedem Tastendruck eine große Tabelle neu rendert, erzeugt mehr Mutationsdatensätze als ein statischer Artikel, und rrweb-Issue #1547 meldet Verzögerungen von 1 bis 3 Sekunden "on pages with lots of nodes". Widgets von Drittanbietern kommen hinzu, was Issue #1820 für das Zendesk Web Widget dokumentiert.

Schadet Session Replay den SEO-Rankings?

Nur auf demselben Weg wie jedes Skript, indem es die Core Web Vitals bewegt. Googles Suchdokumentation sagt, dass die Kern-Ranking-Systeme gute Page Experience belohnen, warnt aber, dass Core Web Vitals allein keine Rankings garantieren (Google Search Central). Da Sentrys Messung die Total Blocking Time bewegte und Largest Contentful Paint sowie Cumulative Layout Shift flach ließ, ist die Reaktionsfähigkeit des Hauptthreads die Metrik, die Sie beobachten.

Wie messe ich den Session-Replay-Overhead auf meiner eigenen Seite?

Laden Sie Ihre schwerste Seite mit deaktiviertem Recorder, nehmen Sie ein Performance-Profil in den Chrome DevTools auf, wiederholen Sie das mit aktiviertem Recorder und vergleichen Sie Scripting-Zeit, Anzahl der Long Tasks und übertragene Bytes. Führen Sie jede Konfiguration mehrmals aus und vergleichen Sie Mediane, denn einzelne Läufe schwanken stärker als der Effekt, den Sie messen. Felddaten von echten Geräten klären, was ein Laborprofil nur nahelegt.

Spart das Deaktivieren von Mousemove-Tracking CPU-Zeit oder nur Bandbreite?

Beides. Die Kosten-Tabelle des Beitrags führt Sampling sowohl bei den Stellhebeln für die Hauptthread-CPU als auch bei denen für die Upload-Bandbreite auf, denn jedes übersprungene Mousemove-Ereignis ist ein Mutationsdatensatz weniger, der serialisiert werden muss, und ein Ereignis weniger, das hochgeladen wird. Mousemove mit mousemove: false abzuschalten ist derselbe Hebel, den das Storage-Rezept von rrweb zuerst empfiehlt.

Was gilt als 'Long Task', den Session Replay vermeiden muss?

Der web.dev-Artikel von Google definiert einen Long Task als alles, was länger als 50 Millisekunden auf dem Hauptthread läuft, wobei die Blocking Time der Aufgabendauer minus 50 ms entspricht. Der Full-Snapshot-Benchmark von rrweb hat 34.55 ms auf einem Dokument mit tief verschachtelten Divs gemessen, was unter dieser Grenze liegt und keine Blocking Time verursacht. Snapshots auf viel größeren DOM-Bäumen sind es, die diese Grenze überschreiten, wie der Issue-Tracker von rrweb mit Berichten über mehrsekündige Verzögerungen zeigt.

Kann requestIdleCallback verhindern, dass Session Replay den Hauptthread blockiert?

Nur für Arbeit, die warten kann. Recorder können Kompression und Upload in requestIdleCallback verschieben, aber die W3C-Spezifikation begrenzt jede Idle-Deadline auf 50 ms, und MDN warnt, dass ein Callback ohne timeout-Option mehrere Sekunden warten kann, bevor er ausgelöst wird. Das macht Idle-Scheduling geeignet für Hintergrundarbeit, nicht für den ersten DOM-Snapshot, der laufen muss, sobald der Recorder startet.

Kostet Session Replay mehr bei einer langsamen CPU oder einer langsamen Netzwerkverbindung?

In Sentrys veröffentlichtem Testlauf trägt die CPU den größeren Teil der Kosten. Der Download blieb mit 8.09 MB gegenüber 8.07 MB bei aktiviertem Replay konstant, während die Total Blocking Time von 2621.67 ms auf 3036.80 ms stieg, und das Fazit des Beitrags lautet, dass die Kosten auf dem Hauptthread anfallen, nicht im Netzwerk. Der Upload wuchs trotzdem von 3.84 KB auf 272.51 KB, sodass eine getaktete Verbindung es ebenfalls spürt, nur weniger stark als eine langsame CPU.