Warum du Analytics- und Tracking-Skripte begrenzen solltest

Warum du Analytics und Tracking-Skripte begrenzen solltest

Ich verbringe viel Zeit mit Website-Audits. Bei etwa 90 % davon finde ich ungenutzte Tracking-Skripte. Skripte, an deren Einbau sich niemand erinnert. Skripte, die Daten tracken, die niemand liest. Skripte, die vor zwei Jahren vom Marketing als „nur ein weiterer Pixel“ hinzugefügt wurden. Jedes einzelne schien damals harmlos. Zusammen verlängern sie jede Ladezeit um Sekunden.

Laut dem Web-Tracking-Report 2024 von Kaspersky hat die durchschnittliche Website heute 48 Tracker. Der Web Almanac 2025 zeigt, dass über 90 % der Seiten mindestens einen Drittanbieter einbinden. Die 1.000 meistbesuchten Websites lösen auf dem Desktop im Median 129 Drittanbieter-Requests aus. Das ist keine Tracking-Strategie. Das ist ein Performance-Problem.

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

Warum Websites Analytics und Tracking-Skripte nutzen

Analytics und Tracking-Skripte erfüllen einen echten Zweck. Google Analytics zeigt dir, woher deine Besucher kommen. Der Facebook Pixel trackt Anzeigen-Conversions. Hotjar zeigt dir, wohin Nutzer klicken. Ohne diese Daten rätst du nur.

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

Fakt: Bei etwa 90 % aller Audits finde ich ungenutzte Tracking-Skripte. Meistens werden diese Skripte spät über einen Tag Manager oder ein anderes Drittanbieter-Skript eingefügt.

Wie schwer sind diese Skripte?

Nicht alle Tracking-Skripte sind gleich. Das kosten dich die gängigsten wirklich:

• Google Analytics 4 (gtag.js): 134 KB komprimiert, 371 KB unkomprimiert. Wird asynchron geladen, blockiert also nicht das Rendering. Das JavaScript muss aber trotzdem auf dem main thread geparst und ausgeführt werden.
• Google Tag Manager: ~33 KB komprimiert für die Bibliothek selbst, plus alle Tags, die du hinzufügst. Der Median-Container ist etwa 50 KB groß. Ein leerer GTM-Container verursacht etwa 100 ms Verzögerung. Acht Tracking-Tags im GTM kosten etwa 3 Sekunden bei schnellem 3G und 10 Sekunden bei langsamem 3G.
• Facebook/Meta Pixel: 340 KB unkomprimiert (95 KB komprimiert). Das ist 7-mal größer als Google Analytics. Er macht 4 HTTP-Requests, bis er fertig ist. Er verlängert jede Ladezeit um 1,3 bis 1,5 Sekunden.
• Consent Management Platforms: OneTrust kann je nach Konfiguration 124 bis 347 KB hinzufügen. In einem Fall wurde ein Consent-Banner zum LCP-Element. Das verschlechterte den LCP-Wert von 1,43 s auf 3,61 s.

Kombiniere GA4, GTM, Facebook Pixel und ein Consent-Banner. Du landest bei etwa 400 bis 600 KB Tracking-JavaScript, bevor dein eigener Code überhaupt läuft. Das ist oft mehr als der gesamte eigentliche Inhalt der Seite.

Wie Tracking-Skripte die Core Web Vitals beeinflussen

Largest Contentful Paint

Jedes Skript konkurriert während der Ladezeit um Netzwerkbandbreite und CPU-Zeit. Auch asynchrone Skripte verbrauchen Bandbreite. Diese Bandbreite fehlt dem LCP-Bild oder dem Critical CSS. Wenn du 8 Tracking-Skripte neben deinem Hero-Bild lädst, zwingst du den Browser zum Teilen. Er muss seine begrenzte mobile Bandbreite auf alle verteilen.

Das ist in mobilen Netzwerken besonders schlimm. Der Web Almanac 2025 meldet eine mobile Total Blocking Time von 1.916 ms im Median (58 % mehr als 2024). Ein Großteil dieser Blockierung kommt von Drittanbieter-JavaScript. Du kannst deine Skripte verzögern, aber sie konkurrieren weiterhin um Ressourcen, sobald das Laden beginnt.

Interaction to Next Paint

Beim Interaction to Next Paint (INP) richten Tracking-Skripte den größten Schaden an. Laut dem Web Almanac 2024 ist Presentation Delay der Hauptgrund für einen schlechten INP. Die Skripte, die das verursachen, sind Behavior-Tracking-Tools, Consent-Provider und Werbepixel.

Viele Tracking-Skripte arbeiten noch lange, nachdem die Seite geladen ist. Google Analytics kann so konfiguriert werden, dass es jeden Klick trackt. Heatmap-Tools wie Hotjar registrieren jede Mausbewegung. Jeder dieser Event-Listener erhöht die Verarbeitungszeit von Nutzerinteraktionen. Ein Besucher klickt auf einen Button. Dein Code braucht 50 ms für die Verarbeitung. Drei Tracking-Skripte feuern aber ebenfalls Event-Listener und fügen weitere 150 ms hinzu. Die Interaktion fühlt sich träge an.

Die Zahlen sprechen für sich. 77 % aller mobilen Seiten bestehen den INP, aber nur 53 % der 1.000 meistbesuchten Websites. Diese Top-Websites haben komplexeres JavaScript und mehr Drittanbieter-Skripte. Wenn du deine Seiten responsiv halten willst, sind Tracking-Skripte der erste Ansatzpunkt.

Time to First Byte und Cookie-Overhead

Jedes Tracking-Skript kann eigene Cookies setzen. Einzelne Cookies sind klein (Median 40 Bytes laut dem Cookie-Kapitel im Web Almanac 2025). Ihre Wirkung summiert sich aber, da Cookie-Daten mit jedem HTTP-Request gesendet werden. Wenn deine Seite 4 KB an Cookies setzt und 39 Ressourcen lädt, sind das 156 KB zusätzliche Upload-Daten über diese Requests hinweg.

Wenn die gesamten Cookie-Daten etwa 1.500 Bytes überschreiten, passen die Request-Header nicht mehr in ein einziges TCP-Paket. Das erzwingt zusätzliche Roundtrips. Dein Time to First Byte bei weiteren Navigationen und beim Laden statischer Ressourcen steigt direkt an.

Cumulative Layout Shift

Consent-Banner sind hier die schlimmsten Übeltäter. Ein Cookie-Consent-Banner rendert spät und schiebt den Seiteninhalt nach unten. Das verursacht einen Layout Shift. Einige Consent-Plattformen fügen große DOM-Bäume (200+ Nodes) ein, die einen Reflow der Seite verursachen. In einem dokumentierten Fall war ein Consent-Banner bei 50 % der Seitenaufrufe das LCP-Element. Es renderte sich über den eigentlichen Inhalt.

Strategien für intelligenteres Tracking

Prüfe, was du wirklich nutzt

Öffne deinen Tag Manager und gehe jedes einzelne Tag durch. Frage bei jedem: Wer liest diese Daten? Wann wurden sie zuletzt geprüft? Wenn niemand antworten kann, entferne es. Ich finde regelmäßig Tags für A/B-Testing-Tools von Kampagnen, die vor Monaten endeten. Oder Pixel für Werbeplattformen, die das Unternehmen nicht mehr nutzt. Oder doppelte Analytics-Implementierungen (GA4 über GTM und fest verbautes gtag.js).

Verzögere nicht-essenzielle Skripte

Nicht alles muss direkt beim Seitenaufruf laden. Niemand war je enttäuscht, dass ein Heatmap-Skript erst nach 3 Sekunden mit der Aufzeichnung begann. Feuere Analytics und Tracking-Tags beim Window Loaded-Event. Noch besser: Verzögere sie, bis der Nutzer mit der Seite interagiert. Tests von AnalyticsMania zeigten: Eine Verzögerung der Tags um 1,5 Sekunden nach dem Laden der Seite sparte 6 Sekunden bei langsamem 3G.

// Lade Analytics erst nach der ersten Nutzerinteraktion
const events = ['click', 'scroll', 'mousemove', 'touchstart'];
const loadAnalytics = () => {
    events.forEach(e => document.removeEventListener(e, loadAnalytics));
    // Lade dein Analytics-Skript hier
    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}));

Nutze die Beacon API für benutzerdefinierte Events

Wenn du benutzerdefinierte Analytics-Events sendest (Formulareingaben, Button-Klicks, Scrolltiefe), nutze navigator.sendBeacon() statt XMLHttpRequest. Die Beacon API sendet Daten asynchron, ohne den main thread zu blockieren. Sie schließt garantiert ab, selbst während der Navigation auf eine andere Seite. Das ist besonders wichtig, um den INP bei Interaktionen niedrig zu halten, die Analytics-Aufrufe auslösen.

// Sende Analytics-Daten, ohne die Interaktion zu blockieren
document.querySelector('.buy-button').addEventListener('click', (e) => {
    // Nutze sendBeacon - nicht blockierend, überlebt Seitennavigation
    navigator.sendBeacon('/analytics', JSON.stringify({
        event: 'purchase_click',
        timestamp: Date.now()
    }));
});

Ziehe serverseitige Alternativen in Betracht

Der effektivste Weg, Tracking-JavaScript zu eliminieren: Lade es erst gar nicht. Cloudflare Zaraz verlagert die Analytics-Ausführung an die Edge. Es ersetzt clientseitige Tag-Manager-Skripte durch einen ressourcenschonenden Beacon. Mit serverseitigen GTM-Containern leitet dein Server Daten an Analytics-Anbieter weiter. Kein Hersteller-JavaScript erreicht den Browser. Diese Ansätze erfordern mehr Aufwand bei der Einrichtung. Ihre Auswirkung auf die Performance ist dafür nahezu null.

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

Der Idealfall

Auf Websites, die von CoreDash überwacht werden, bestehen Seiten mit weniger als 5 Drittanbieter-Skripten den INP zu etwa 88 %. Bei 15 oder mehr Skripten sind es nur 64 %. Der Unterschied beim LCP ist genauso deutlich. Weniger konkurrierende Requests bedeuten, der Browser kann priorisieren, was für den Besucher wirklich zählt.

Du musst nicht das gesamte Tracking entfernen. Du musst bewusst entscheiden: Was lädst du? Wann lädst du es? Nutzt überhaupt jemand die Daten? Beginne mit einem Audit deines Tag Managers. Entferne, was du nicht brauchst. Verzögere, was du behältst. Nutze Real User Monitoring, um die Verbesserung der field data zu überprüfen. Labortests zeigen dir nicht das vollständige Bild, wie Tracking-Skripte mit echten Netzwerkbedingungen und echtem Nutzerverhalten interagieren.