Drittanbieter-Code
Von Christian Schreiber · Aktualisiert am
Drittanbieter-Code ist alles, was eine Seite von einer Domain lädt, die der Betreiber nicht kontrolliert: Tag Manager, Analyse, Werbung, Consent-Banner, Chat-Widgets, A/B-Tests, Session Replay, eingebettete Videos, Social-Buttons, Bewertungskarussells und Zahlungskomponenten. Jedes dieser Elemente wurde aus einem Grund eingebaut, meist von einem anderen Team, und jedes kostet bei jedem Seitenaufruf Netzwerkbytes und Zeit auf dem Hauptthread. In unseren Messungen lädt fast jede Startseite Drittanbieter-Code, und die schwersten Tags überholen in der CPU-Zeit regelmäßig das eigene JavaScript der Website. Dieser Ratgeber erklärt, was Drittanbieter-Code mit den Core Web Vitals macht, wie Sie ihn prüfen und wie Sie die Tags, die bleiben, laden, ohne dass sie die Seite blockieren.
Aus den Messungen von PerfDelta: 96 % der 4.108 Startseiten laden Code von Drittanbietern, im Median von fünf Anbietern. Nur 74 % der Websites mit Felddaten erreichen einen guten INP. Mehr dazu im Datenblock unten.
Wie Drittanbieter-Code die Core Web Vitals beeinflusst
- INP. Tags laufen auf dem Hauptthread. Ein Tag Manager, der beim Laden zwanzig Trigger auslöst, ein Session-Replay-Skript, das das DOM serialisiert, oder ein A/B-Test-Werkzeug, das die Seite umschreibt, halten den Thread genau dann beschäftigt, wenn der Besucher zu tippen beginnt. Das ist die Metrik, der Drittanbieter am meisten schaden, und die, an der die meisten Websites scheitern.
- LCP. Synchron im Kopf geladene Skripte verzögern das Rendern; A/B-Test-Werkzeuge, die die Seite verstecken, bis die Variante feststeht, addieren ihre gesamte Ladezeit auf den LCP; und Drittanbieter-Anfragen konkurrieren mit dem LCP-Bild um Bandbreite und Verbindungen.
- CLS. Werbung, Einbettungen und Cookie-Banner, die sich ohne reservierten Platz einfügen, schieben Inhalte nach unten. Spät geladene Schriften eines Schriftdienstes lassen Text umbrechen.
- Seitengewicht und TBT. Jeder Anbieter bringt sein eigenes Bundle mit, oft mit eigenen Kopien von Bibliotheken, die die Seite ohnehin schon lädt.
Der Lighthouse-Befund Auswirkungen von Drittanbieter-Code reduzieren listet jeden Anbieter mit Übertragungsgröße und blockierter Hauptthread-Zeit. PerfDelta-Reports zeigen dieselbe Aufschlüsselung je Seite sowie den Anteil der Seiten je Anbieter über alle gemessenen Websites.
Die vorhandenen Tags prüfen
- Bestandsaufnahme. Exportieren Sie die Liste aus dem Lighthouse-Befund oder dem nach Domain gruppierten Netzwerk-Panel. Ergänzen Sie den Inhalt des Tag-Manager-Containers, denn ein einzelner Container-Eintrag im Audit kann Dutzende Tags verbergen.
- Verantwortliche und Zweck. Benennen Sie für jeden Eintrag das Team, das ihn nutzt, und die Entscheidung, die er stützt. Tags ohne Verantwortliche oder ohne aktuellen Zweck fliegen zuerst; in den meisten Prüfungen ist das ein nennenswerter Teil der Liste.
- Kosten. Notieren Sie Hauptthread-Zeit und Bytes aus dem Audit. Session Replay, A/B-Tests, Chat und Videoeinbettungen sind meist die teuersten; ein einfaches Analyse-Pixel ist billig.
- Zeitpunkt. Entscheiden Sie für jedes verbleibende Tag, ob es vor dem ersten Paint nötig ist (fast nie), vor der ersten Interaktion (Consent, vielleicht Analyse) oder später (alles andere).
Ob ein Tag ungewöhnlich teuer ist, zeigt erst der Vergleich. Der Drittanbieter-Benchmark nennt Hauptthread-Zeit und Transfergröße der häufigsten Dienste auf den Startseiten, die PerfDelta gemessen hat, mit einer eigenen Seite je Dienst: Google Tag Manager, Google Analytics, Google Ads, Meta Pixel, TikTok, LinkedIn Ads, Hotjar, Cookiebot, OneTrust, Usercentrics, Microsoft Clarity, Trustpilot, YouTube und Google Maps. Liegt ein Tag deutlich über dem üblichen Wert seines Dienstes, lohnt dort der genauere Blick zuerst.
Drittanbieter-Code laden, ohne die Seite zu blockieren
1. Tags nie synchron im Kopf laden
Ein synchrones <script src="https://..."> im Kopf hält das Parsen an, bis die Datei von einem fremden Ursprung eingetroffen ist. Jedes Tag sollte async oder defer tragen, und die wenigen, die früh laufen müssen, sollten inline und winzig sein.
2. Unwichtige Tags bis zur Interaktion oder zum Leerlauf zurückstellen
// Chat-Widget erst bei der ersten Interaktion oder im Leerlauf nach dem Laden
const loadChat = () => {
const s = document.createElement('script');
s.src = 'https://chat.example.com/widget.js';
s.async = true;
document.head.append(s);
['scroll', 'pointerdown', 'keydown'].forEach(ev => removeEventListener(ev, loadChat));
};
['scroll', 'pointerdown', 'keydown'].forEach(ev => addEventListener(ev, loadChat, { once: true, passive: true }));
addEventListener('load', () => (window.requestIdleCallback || setTimeout)(loadChat, 3000));
Tag Manager unterstützen dieselbe Idee über den Trigger-Zeitpunkt: Marketing-Tags auf „Fenster geladen“ oder einen Scroll-Trigger statt auf „Seitenaufruf“ setzen.
3. Fassaden für schwere Einbettungen
Eine YouTube-Einbettung lädt hunderte Kilobyte Player-Code, bevor jemand auf Abspielen drückt. Eine Fassade zeigt das Vorschaubild mit einem Abspielknopf und lädt den echten Player erst beim Klick. Dasselbe gilt für Karten, Chat-Starter und Social Feeds. Der Lighthouse-Befund zu Drittanbieter-Ressourcen mit Fassaden nennt die Kandidaten.
4. Analyse serverseitig, wo es sinnvoll ist
Serverseitiges Tagging schickt eine kleine Anfrage vom Browser an einen eigenen Endpunkt und verteilt die Ereignisse vom Server an die Anbieter. Der Browser lädt ein Skript statt zehn, und die Anbieter-Skripte laufen nicht mehr auf dem Hauptthread des Besuchers. Es kostet Infrastruktur und Einrichtungszeit und ist der größte einzelne Gewinn für Websites mit vielen Marketing-Tags.
5. Platz für Werbung, Einbettungen und Banner reservieren
Geben Sie jedem Container, den ein Drittanbieter später füllt, feste Maße oder eine min-height, auch dem Cookie-Banner. Das beseitigt die Layout-Verschiebungen dieser Elemente; der CLS-Ratgeber hat die Details.
6. Preconnect nur zu den ein bis zwei Ursprüngen, die früh zählen
Muss ein Consent-Management-Skript oder ein kritischer Schriftdienst früh laden, verbirgt ein Preconnect einen Teil seiner Verbindungskosten. Setzen Sie keinen Preconnect zu jedem Tag-Ursprung; das macht die Seite langsamer.
7. Regelmäßig neu prüfen
Tags sammeln sich an. Eine vierteljährliche Prüfung des Tag-Manager-Containers gegen die Liste mit Verantwortlichen und Zweck hält die Zahl klein, und das Monitoring des Drittanbieter-Anteils in PerfDelta zeigt, wenn ein neues Tag das Profil der Seite verändert.
Hinweise je Plattform
- WordPress: Plugins fügen Tags ohne Tag Manager ein: Social Sharing, ähnliche Beiträge, Formulare und Analyse-Plugins bringen je eigene Skripte mit. Gleichen Sie die Plugin-Liste mit der Audit-Ausgabe ab.
- Shopify: Apps sind die Hauptquelle; viele fügen auf jeder Seite ein Skript ein, auch wenn die Funktion nur auf einer erscheint. Entfernen Sie ungenutzte Apps und prüfen Sie, dass deinstallierte Apps keine Snippets im Theme hinterlassen haben.
- Unternehmensseiten: Tag Manager plus A/B-Tests plus Personalisierung sind das übliche Trio. Zeitregeln im Tag Manager und ein Anti-Flicker-Snippet mit kurzem Timeout begrenzen den Schaden, bis serverseitiges Tagging steht.
Häufige Fragen
Ist der Google Tag Manager selbst langsam?
Das Container-Skript ist klein. Die Kosten entstehen durch die Tags, die er auslöst, und den Zeitpunkt. Ein Container mit wenigen Tags, die nach dem Laden feuern, kostet wenig; einer mit Dutzenden Tags beim Seitenaufruf kann die Hauptthread-Zeit dominieren.
Welche Drittanbieter-Tags schaden der Performance am meisten?
In den meisten Prüfungen: A/B-Test- und Personalisierungswerkzeuge, die die Seite verstecken, bis sie gelaufen sind, Session Replay, Chat-Widgets, Videoeinbettungen und Werbeskripte. Einfache Analyse-Pixel sind meist billig.
Kann ich Tags verzögert laden, ohne Daten zu verlieren?
Bei Marketing- und Chat-Tags ja. Bei der Analyse verliert das Auslösen bei der ersten Interaktion oder nach dem Laden sehr wenige Seitenaufrufe; eine lange Verzögerung verliert Absprünge. Messen Sie den Unterschied, bevor Sie entscheiden.
Zählt ein Consent-Banner als Drittanbieter-Code?
Ja, und es gehört oft zu den schwereren Posten, weil es früh lädt und ein großes Element rendert. Wählen Sie ein leichtes Consent-Werkzeug, reservieren Sie seinen Platz und lassen Sie es die Seite nicht blockieren.
Was die Messdaten von PerfDelta zeigen
96 % der 4.108 Startseiten laden Code von Drittanbietern, im Median von fünf Anbietern. Nur 74 % der Websites mit Felddaten erreichen einen guten INP.
Die häufigsten Anbieter mit ihrem Anteil und der mittleren Hauptthread-Zeit: Google Tag Manager (66 %, 447 ms Hauptthread), Facebook (27 %, 285 ms Hauptthread), Optanon (19 %, 119 ms Hauptthread), Google/Doubleclick Ads (15 %, 171 ms Hauptthread).
Datenstand 16.10.2026, täglich neu berechnet. Quelle: eigene Messungen von PerfDelta (Chrome UX Report und Lighthouse), Details in den Website Speed Statistiken und in der Methodik.
Grenzwerte und Quellen
Quellen:
- Lighthouse: Auswirkungen von Drittanbieter-Code reduzieren
- web.dev: JavaScript von Drittanbietern
- web.dev: INP optimieren
Alle Quellen abgerufen am 09.10.2026. Grenzwerte und Dokumentation ändern sich; maßgeblich ist die verlinkte Seite.
Eigene Werte testen
Ein kostenloser Scan zeigt, wie Ihre Seiten bei diesen Werten abschneiden, mobil und stationär, mit Feld- und Labdaten nebeneinander.
Kostenlosen Test startenMit einem kostenlosen Konto speichern Sie Ihre Messungen und sehen, wie sich die Werte von Test zu Test verändern. Tägliches Monitoring mit Felddaten und Benachrichtigung gibt es ab dem Tarif Solo.