Das Argument für die Begrenzung von Analyse- und Tracking-Scripten

Das Argument für die Begrenzung von Analyse- und Tracking-Scripten

Ich verbringe einen großen Teil meiner Zeit mit der Prüfung von Websites, und in etwa 90 % dieser Audits finde ich ungenutzte Tracking-Scripte. Scripte, an deren Hinzufügung sich niemand erinnert, Scripte, die Daten tracken, die niemand liest, Scripte, die vor zwei Jahren vom Marketing als „nur ein weiteres Pixel“ hinzugefügt wurden. Jedes einzelne schien zu diesem Zeitpunkt harmlos zu sein. Zusammen fügen sie jedem Seitenladevorgang Sekunden hinzu.

Laut dem Web-Tracker-Bericht 2024 von Kaspersky hat die durchschnittliche Website mittlerweile 48 Tracker. Der 2025 Web Almanac zeigt, dass über 90 % der Webseiten mindestens einen Drittanbieter enthalten, und die Top 1.000 der meistbesuchten Websites lösen auf dem Desktop im Median 129 Drittanbieter-Anfragen aus. Das ist keine Tracking-Strategie. Das ist ein Performance-Problem.

Zuletzt geprüft von Arjen Karel im März 2026

Warum Websites Analyse- und Tracking-Scripte verwenden

Analyse- und Tracking-Scripte erfüllen einen echten Zweck. Google Analytics sagt Ihnen, woher Ihre Besucher kommen. Facebook Pixel trackt Werbekonversionen. Hotjar zeigt Ihnen, wohin die Leute klicken. Ohne diese Daten raten Sie nur.

Das Problem ist nicht, dass diese Tools existieren. Das Problem ist, dass die meisten Websites viel mehr Tracking laden, als sie benötigen. Beliebte Tools wie Google Analytics, Facebook Pixel und Cloudflare-Analytics fügen alle JavaScript, Cookies und HTTP-Anfragen hinzu. Und sie sind selten das einzige Tracking auf der Seite.

Fakt: In etwa 90 % aller Audits finde ich ungenutzte Tracking-Scripte. Normalerweise werden diese Scripte spät über einen Tag Manager oder ein anderes Drittanbieter-Script injiziert.

Wie schwerfällig sind diese Scripte?

Nicht alle Tracking-Scripte sind gleich. Hier ist, was die gängigsten Sie tatsächlich kosten:

• Google Analytics 4 (gtag.js): 134 KB komprimiert, 371 KB unkomprimiert. Wird asynchron geladen, blockiert also nicht das Rendering, aber das JavaScript muss dennoch auf dem main thread analysiert und ausgeführt werden.
• Google Tag Manager: ~33 KB komprimiert für die Library selbst, plus alle Tags, die Sie darin platzieren. Der mediane Container ist etwa 50 KB groß. Ein leerer GTM-Container fügt eine Verzögerung von etwa 100 ms hinzu. Acht Tracking-Tags innerhalb des GTM fügen etwa 3 Sekunden bei Fast 3G und 10 Sekunden bei Slow 3G hinzu.
• Facebook/Meta Pixel: 340 KB unkomprimiert (95 KB komprimiert). Das ist 7-mal größer als Google Analytics. Es stellt 4 HTTP-Anfragen, bevor es fertig ist, und fügt jedem Seitenladevorgang 1,3 bis 1,5 Sekunden hinzu.
• Consent Management Platforms: OneTrust kann je nach Konfiguration 124 bis 347 KB hinzufügen. In einem Fall wurde ein Consent-Banner zum LCP-Element, wodurch sich der LCP von 1,43 s auf 3,61 s erhöhte.

Kombinieren Sie GA4 + GTM + Facebook Pixel + ein Consent-Banner und Sie kommen auf etwa 400 bis 600 KB Tracking-JavaScript, bevor Ihr eigener Code überhaupt ausgeführt wird. Das ist oft mehr als der gesamte eigentliche Seiteninhalt.

Wie sich Tracking-Scripte auf die Core Web Vitals auswirken

Largest Contentful Paint

Jedes Script konkurriert während des Ladens der Seite um Netzwerkbandbreite und CPU-Zeit. Sogar asynchrone Scripte verbrauchen Bandbreite, die für das LCP-Bild oder kritisches CSS verwendet werden könnte. Wenn Sie 8 Tracking-Scripte zusammen mit Ihrem Hero-Bild laden, zwingen Sie den Browser, seine begrenzte mobile Bandbreite auf alle diese Scripte aufzuteilen.

Dies ist besonders in mobilen Netzwerken problematisch. Der 2025 Web Almanac berichtet von einer medianen mobilen Total Blocking Time von 1.916 ms (ein Plus von 58 % gegenüber 2024). Ein Großteil dieser Blockierung stammt von Drittanbieter-JavaScript. Sie können Ihre Scripte aufschieben, aber sie konkurrieren immer noch um Ressourcen, sobald sie mit dem Laden beginnen.

Interaction to Next Paint

Interaction to Next Paint (INP) ist der Bereich, in dem Tracking-Scripte den größten Schaden anrichten. Der 2024 Web Almanac stellte fest, dass der Presentation Delay der Hauptfaktor für einen schlechten INP ist, und die Scripte, die dies verursachen, sind Tools zur Verhaltensverfolgung, Consent-Anbieter und Werbepixel.

Viele Tracking-Scripte arbeiten noch lange nach dem Laden der Seite weiter. Google Analytics kann so konfiguriert werden, dass jeder Klick getrackt wird. Heatmap-Tools wie Hotjar lauschen auf jede Mausbewegung. Jeder dieser Event-Listener fügt den Benutzerinteraktionen Verarbeitungszeit hinzu. Wenn ein Besucher auf eine Schaltfläche klickt und Ihr Code 50 ms benötigt, um dies zu verarbeiten, aber drei Tracking-Scripte ebenfalls Event-Listener auslösen, die weitere 150 ms hinzufügen, fühlt sich die Interaktion träge an.

Die Zahlen sprechen für sich: 77 % aller mobilen Seiten bestehen den INP, aber nur 53 % der Top 1.000 der meistbesuchten Websites. Diese Top-Websites haben komplexeres JavaScript und mehr Drittanbieter-Scripte. Wenn Sie Ihre Seiten reaktionsschnell halten wollen, sind Tracking-Scripte der erste Punkt, an dem Sie ansetzen sollten.

Time to First Byte und Cookie-Overhead

Jedes Tracking-Script kann seine eigenen Cookies setzen. Einzelne Cookies sind klein (im Median 40 Byte laut dem Kapitel über Cookies im 2025 Web Almanac), aber ihre kollektive Auswirkung summiert sich, da Cookie-Daten mit jeder HTTP-Anfrage gesendet werden. Wenn Ihre Website 4 KB an Cookies setzt und 39 Ressourcen lädt, sind das 156 KB an zusätzlichen Upload-Daten über diese Anfragen hinweg.

Wenn die gesamten Cookie-Daten etwa 1.500 Byte überschreiten, passen die Request-Header nicht mehr in ein einzelnes TCP-Paket. Das erzwingt zusätzliche Roundtrips und erhöht direkt Ihren Time to First Byte bei nachfolgenden Navigationen und dem Laden statischer Ressourcen.

Cumulative Layout Shift

Consent-Banner sind hier der schlimmste Übeltäter. Wenn ein Cookie-Consent-Banner spät gerendert wird und den Seiteninhalt nach unten schiebt, verursacht dies einen Layout Shift. Einige Consent-Plattformen injizieren große DOM-Bäume (über 200 Knoten), die das Layout der Seite verändern. In einem dokumentierten Fall war ein Consent-Banner das LCP-Element für 50 % der Seitenaufrufe, weil es über dem eigentlichen Inhalt gerendert wurde.

Strategien für intelligenteres Tracking

Auditieren Sie, was Sie tatsächlich nutzen

Öffnen Sie Ihren Tag Manager und gehen Sie jeden einzelnen Tag durch. Fragen Sie bei jedem: Wer liest diese Daten? Wann wurden sie zuletzt geprüft? Wenn niemand antworten kann, entfernen Sie ihn. Ich finde regelmäßig Tags für A/B-Testing-Tools von Kampagnen, die vor Monaten endeten, Pixel für Werbeplattformen, die das Unternehmen nicht mehr nutzt, und doppelte Analyse-Implementierungen (sowohl GA4 über GTM als auch ein fest im Code verankertes gtag.js).

Nicht-essenzielle Scripte verzögern

Nicht alles muss beim Seitenaufruf geladen werden. Niemand war jemals enttäuscht, dass ein Heatmap-Script erst nach 3 Sekunden mit der Aufzeichnung begann. Lösen Sie Analyse- und Tracking-Tags beim Window Loaded Ereignis aus oder, noch besser, schieben Sie sie auf, bis der Benutzer mit der Seite interagiert. Die Tests von AnalyticsMania zeigten, dass eine Verzögerung der Tag-Auslösung um 1,5 Sekunden nach dem Laden der Seite bei Slow 3G 6 Sekunden einsparte.

// Analyse erst nach der ersten Benutzerinteraktion laden
const events = ['click', 'scroll', 'mousemove', 'touchstart'];
const loadAnalytics = () => {
    events.forEach(e => document.removeEventListener(e, loadAnalytics));
    // Hier Ihr Analyse-Script laden
    const script = document.createElement('script');
    script.src = 'https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX';
    document.head.appendChild(script);
};
events.forEach(e => document.addEventListener(e, loadAnalytics, {once: true}));

Verwendung der Beacon API für benutzerdefinierte Ereignisse

Wenn Sie benutzerdefinierte Analyse-Ereignisse senden (Formularabsendungen, Klicks auf Schaltflächen, Scrolltiefe), verwenden Sie navigator.sendBeacon() anstelle von XMLHttpRequest. Die Beacon API sendet Daten asynchron, ohne den main thread zu blockieren, und es ist garantiert, dass sie auch während der Seitennavigation abgeschlossen wird. Dies ist besonders wichtig, um den INP bei Interaktionen niedrig zu halten, die Analyse-Aufrufe auslösen.

// Analyse-Daten senden, ohne die Interaktion zu blockieren
document.querySelector('.buy-button').addEventListener('click', (e) => {
    // sendBeacon verwenden - blockiert nicht, übersteht Seitennavigation
    navigator.sendBeacon('/analytics', JSON.stringify({
        event: 'purchase_click',
        timestamp: Date.now()
    }));
});

Serverseitige Alternativen in Betracht ziehen

Der effektivste Weg, Tracking-JavaScript zu eliminieren, besteht darin, es gar nicht erst zu laden. Cloudflare Zaraz verlagert die Ausführung von Analysen an die Edge und ersetzt clientseitige Tag-Manager-Scripte durch einen leichtgewichtigen Beacon. GTM Server-Side Container lassen Ihren Server Daten an Analyse-Anbieter weiterleiten, ohne dass JavaScript des Anbieters den Browser erreicht. Diese Ansätze erfordern mehr Aufwand bei der Einrichtung, aber ihre Auswirkung auf die Performance ist nahezu Null.

Für einfachere Anforderungen bieten leichtgewichtige Alternativen wie Plausible (unter 1 KB) oder Umami (etwa 2 KB) Traffic-Analysen zu einem Bruchteil der 134 KB Kosten von GA4.

Wie ein gutes Ergebnis aussieht

Auf den von CoreDash überwachten Websites bestehen Seiten, die weniger als 5 Drittanbieter-Scripte laden, den INP zu etwa 88 %, verglichen mit 64 % bei Seiten, die 15 oder mehr laden. Der Unterschied beim LCP ist genauso deutlich: Weniger konkurrierende Anfragen bedeuten, dass der Browser priorisieren kann, was für den Besucher tatsächlich wichtig ist.

Sie müssen nicht alles Tracking entfernen. Sie müssen bewusst entscheiden, was Sie laden, wann Sie es laden und ob tatsächlich jemand de Daten nutzt. Beginnen Sie mit einem Audit Ihres Tag Managers. Entfernen Sie, was Sie nicht benötigen. Verzögern Sie, was Sie behalten. Verwenden Sie Real User Monitoring, um die Verbesserung in den Felddaten zu verifizieren, da Labortests Ihnen nicht das vollständige Bild vermitteln, wie Tracking-Scripte mit echten Netzwerkbedingungen und realem Benutzerverhalten interagieren.