Downloadgröße
| Größe | |
|---|---|
| Minifiziert | 105,5 KB |
| gzip | 36,3 KB |
| Brotli | 31,9 KB |
| Budget (gzip) | 45 KB |
Gemeint ist ar.min.js, die Datei, die das Script-Tag-Snippet lädt, mit der Aufzeichnungs-Engine (rrweb) darin. Der Build schlägt fehl, wenn die gzip-Datei über das Budget wächst; ein Update einer Abhängigkeit kann also nicht still jede Kundenwebsite schwerer machen. Der Player, der Sitzungen abspielt, ist nicht enthalten; den lädt nur das Dashboard.
Wie es lädt
- Das Snippet legt eine kleine Warteschlange an und fügt das Skript mit
asyncein, sodass der Browser die Seite weiter parst und rendert, während es lädt. Aufrufe vor seiner Ankunft —init,identify,track— warten in der Schlange und laufen der Reihe nach. - Mit
requireConsentzeichnet der Recorder nichts auf, speichert nichts und sendet nichts, bis die Einwilligung vorliegt. MitsampleRatewird ein Besucher, der nicht in die Stichprobe fällt, gar nicht aufgezeichnet. - Nichts, was der Recorder tut, darf einen Fehler in Ihre Seite werfen: Seine Fehler werden abgefangen und mit
debug: truein die Konsole geschrieben.
Was es im Main Thread tut
- Einmal pro Seite: ein Snapshot. Beim Start der Aufzeichnung liest es die Seite einmal und serialisiert sie, lesbare Stylesheets als Text. Das ist die größte einzelne Arbeit, und sie wächst mit der Seite.
- Solange der Besucher da ist: Änderungen. Ein
MutationObserverund Event-Listener notieren, was sich ändert — Elemente, Text, Scrollen, Klicks, Formulareingaben (auf dem Gerät maskiert) —, statt die Seite neu zu lesen. - Alle 5 Sekunden: ein Versand. Änderungen werden gebündelt und mit
fetchgesendet; wird der Tab verborgen oder geschlossen, geht der Rest mitkeepaliveodersendBeacon. Die Pakete sind JSON und werden vom Recorder nicht komprimiert. - Gar nicht: Canvas-Aufzeichnung, Schriftarten sammeln, Screenshots oder Video.
In Chrome gemessen
Wir haben eine Shop-Seite — Produktkarten, ein Formular, ein Stylesheet — in Chrome 156.0.8078.47 geladen, einmal ohne Recorder und einmal mit genau dem Snippet, das Kunden einfügen, jeweils 5-mal, und den Median der Differenz der Main-Thread-Zeit genommen, die Chrome selbst meldet. Dann dasselbe mit vierfach gedrosselter CPU, Chromes Ersatz für ein Mittelklasse-Smartphone. Ingest war ein lokaler Stub; das Netzwerk steckt nicht in diesen Zahlen.
| Typische Seite, 921 Elemente | Schwere Seite, 2.721 Elemente | |
|---|---|---|
| Zusätzliche Main-Thread-Zeit beim Laden | 19 ms | 23 ms |
| … mit 4× gedrosselter CPU | 75 ms | 107 ms |
| Längste einzelne Aufgabe, 4× gedrosselte CPU | keine über 50 ms | 65 ms |
| Zusätzliche Main-Thread-Zeit pro Sekunde Aktivität | 7,7 ms | 4,4 ms |
| … mit 4× gedrosselter CPU | 13,1 ms | 12,9 ms |
| Long Tasks während der Aktivität, 4× gedrosselte CPU | 0 | 0 |
| Größter Upload (der Snapshot, unkomprimiert) | 165 KB | 491 KB |
„Aktivität“ sind 10 Sekunden, in denen die Seite zehnmal pro Sekunde zwanzig Elemente ändert und scrollt — mehr als bei den meisten Besuchen. Chrome nennt eine Aufgabe ab 50 ms lang, weil die Seite währenddessen auf keinen Tipp reagiert. Gemessen auf Apple M4.
Grenzen, die man kennen sollte
Eine Seite, deren Snapshot größer als 512 KB ist, wird nicht aufgezeichnet: Der Recorder hört für diese Seite auf und meldet mit debug: true snapshot_too_large in der Konsole. Auf unserer Testseite passiert das knapp über 3.000 Elementen. Siehe verkürzte Sitzungen.
- Die Kosten des Snapshots wachsen mit der Seite. Auf der schweren Seite mit langsamer CPU kann er ein Long Task sein; dann lohnt sich
sampleRateoderar-blockfür ein großes Widget, das niemand sehen muss. - Das sind Laborwerte von einem Rechner. Ihre Seite, die Geräte Ihrer Besucher und andere Skripte auf der Seite verschieben sie, in beide Richtungen.