hello@datascale.de+49 89 921 35 623cookiefrei getrackt · /openDEEN

Suchen Sie nach Leistungen, Integrationen und Blog-Beiträgen.

DatascaleRessourcenChecksTracking-Payload

Check · C05 · Script-Inventar & Performance

Tracking-Payload schätzen: wie viel Kilobyte die Tags kosten

Der Check lädt bis zu sechs bekannte Tracking-Skripte selbst herunter und summiert ihre Größe. Über 100 KB ist „zu prüfen“, über 200 KB kritisch.

Was wird geprüft

Im HTML: Der Scan sucht die Loader von sieben bekannten Trackern, gtm.js, gtag.js, Meta fbevents.js, Hotjar, LinkedIn Insight, Microsoft Clarity und HubSpot, lädt bis zu sechs davon selbst herunter (je drei Sekunden Zeitlimit) und addiert ihre Größe. Bis 100 KB heißt „ok“, bis 200 KB „zu prüfen“, darüber kritisch. Findet er keinen bekannten Loader, ist die Zeile ein Hinweis: nichts zu messen. Der Wert ist eine Schätzung, so steht es auch in der Zeile.

Was der Scan nicht sieht: alles, was der Container nachlädt, also die eigentlichen Tags im Tag Manager, dazu Chat-Widgets, A/B-Tests und Embeds. Er misst Übertragungsgröße oder Rohgröße, je nachdem, was der Server meldet, und nie die Rechenzeit, die ein Skript im Browser kostet.

Warum ist das wichtig

Tracking-Skripte laufen auf jeder Seite, für jeden Besucher, vor jedem Inhalt. Ein Container mit 60 Tags kann auf einem mittleren Android-Gerät mehr Zeit kosten als das Rendering der Seite selbst. Und die Last ist nur das sichtbare Symptom. Hinter 200 KB Tracking stehen meist drei Tools, die dasselbe messen, Session-Recording auf Seiten, die niemand auswertet, und ein Container, in dem seit drei Agenturen niemand aufgeräumt hat. Jedes dieser Skripte ist zugleich ein Eintrag in der Datenschutzerklärung, den jemand pflegen muss.

Häufige Ursachen

  • Mehrere Analytics-Tools messen parallel dasselbe, GA4 plus Heatmap plus Session-Recording plus Produkt-Analytics.
  • Tag-Manager-Container sind über Jahre gewachsen, niemand hat je einen Tag gelöscht.
  • Session-Recording-Tools laden auf jeder Seite, obwohl nur der Checkout untersucht werden sollte.
  • Consent-, Chat- und Personalisierungs-Widgets bringen jeweils ihre eigene Bibliothek mit.

So beheben

Ein Script-Audit mit drei Spalten: Tag, Nutzer der Daten, letzter Zugriff auf den Report. Was keine Spalte füllt, fliegt raus. Doppelte Messung auf ein Tool reduzieren, Session-Recording auf die Seiten begrenzen, die gerade untersucht werden, alles Übrige in einen Container mit Consent-Triggern. Danach im Netzwerk-Tab die tatsächliche Last messen, nicht die Schätzung des Scans. Wer viele Pixel betreibt, prüft den Server-Container: Was serverseitig weitergereicht wird, muss der Browser nicht mehr laden.

Erst selbst prüfen

Der Tracking-Check testet diesen Punkt zusammen mit allen anderen in Sekunden.

Tracking-Check starten →
Der Scan meldet 40 KB, Lighthouse zählt 600 KB Third-Party. Wer hat recht?

Beide, sie messen Verschiedenes. Der Scan lädt nur die Loader der bekannten Tracker aus dem HTML, höchstens sechs, und addiert deren Größe. Was der Tag Manager danach nachlädt, Pixel, Heatmaps, Session-Recording, sieht er nicht. Lighthouse zählt alles, was im Browser ankommt. Der Scan gibt eine Untergrenze; die echte Last steht im Netzwerk-Tab.

Warum ist ein Kilobyte-Wert überhaupt kritisch?

Weil über 200 KB Tracking-Skripte selten aus einem Tool kommen. Meist sind es drei Tools, die dasselbe messen, plus ein Container, aus dem nie jemand einen Tag gelöscht hat. Der Wert selbst bremst weniger als das, was er anzeigt: Jedes dieser Skripte läuft auf jeder Seite, für jeden Besucher, ob mit oder ohne Einwilligung.

Wie senken wir die Payload, ohne Messung zu verlieren?

Inventar machen: Welche Tags feuern, wer nutzt die Daten, wann wurde der Report zuletzt geöffnet. Doppelte Tools abschalten, Session-Recording auf die Seiten begrenzen, die jemand untersucht, und die Reste in einen Container mit Consent-Triggern ziehen. Ein Server-Container nimmt den Browser zusätzlich Arbeit ab, weil viele Pixel dann gar nicht mehr im Client laufen müssen.

Behebung

Verdrahtet in Tagen, nicht in Sprints.

Befunde aus dem Tracking-Check gehen im Audit Sprint in eine Reihenfolge mit Aufwand, jeder Baustein mit Abnahmekriterium.