Drittanbieter-Skripte: Hat jedes Tag sein Performance-Budget verdient?
Ein praxisnaher Audit für Analytics, Chat, A/B-Tests, Consent-Tools und andere Drittanbieter: Welche Skripte liefern Geschäftswert – und welche verbrauchen Ladezeit, Main-Thread-Zeit und Wartungsbudget?
Eine Website kann technisch schlank starten und Monate später trotzdem träge wirken. Nicht unbedingt, weil der eigene Code schlechter geworden ist – sondern weil sich nach und nach Analyse-Tags, Heatmaps, Chat-Widgets, A/B-Tests, Bewertungs-Badges, Video-Embeds und Marketing-Pixel angesammelt haben.
Das Problem ist selten ein einzelnes Skript. Es ist die Summe aus Netzwerkverbindungen, JavaScript-Ausführung, DOM-Änderungen und Abhängigkeiten, die niemand mehr vollständig überblickt.
Die bessere Frage lautet deshalb nicht: „Ist dieses Tool schnell?“
Sondern: „Ist der messbare Nutzen dieses Tools groß genug für die technische Last, die wir dauerhaft auf jede relevante Sitzung legen?“
Drittanbieter-Code ist kein kostenloses Feature
Drittanbieter-JavaScript ist Code, den eine Website einbindet, aber nicht selbst kontrolliert. Typische Beispiele sind Analytics, Tag Manager, Werbe- und Conversion-Tags, Chat-Systeme, Social Widgets, eingebettete Player oder Experiment-Plattformen.
web.dev weist darauf hin, dass solche Skripte zusätzliche Netzwerkanfragen auslösen, weitere Ressourcen nachladen und den Main Thread mit Parsing und Ausführung belegen können. Tag Manager können Core Web Vitals indirekt beeinflussen: Bandbreite und Main-Thread-Zeit konkurrieren mit den Ressourcen, die für die eigentliche Seite benötigt werden.
Das ist wichtig, weil die aktuellen Core Web Vitals unterschiedliche Teile der Nutzung abbilden:
- Largest Contentful Paint (LCP) bewertet die wahrgenommene Ladegeschwindigkeit. Als „gut“ gilt ein LCP von höchstens 2,5 Sekunden am 75. Perzentil.
- Interaction to Next Paint (INP) bewertet die Reaktionsfähigkeit. Als „gut“ gelten höchstens 200 Millisekunden am 75. Perzentil.
- Cumulative Layout Shift (CLS) bewertet visuelle Stabilität. Als „gut“ gilt höchstens 0,1 am 75. Perzentil.
Ein zusätzliches Marketing-Tag ist damit nicht automatisch „schlecht“. Aber es konkurriert mit Produktcode, Bildern, Fonts und Nutzerinteraktionen um begrenzte Ressourcen.
Der typische schleichende Fehler: Niemand besitzt das Tag mehr
Viele Websites haben eine erstaunlich ähnliche Entstehungsgeschichte:
- Ein Tool wird für eine Kampagne eingebaut.
- Die Kampagne endet.
- Das Tag bleibt.
- Die Person, die es angelegt hat, wechselt Rolle oder Agentur.
- Niemand möchte es entfernen, weil unklar ist, ob „irgendetwas davon noch gebraucht wird“.
Genau hier wird aus einem Performance-Problem ein Betriebsproblem.
Die web.dev-Empfehlungen für Tag Manager raten ausdrücklich dazu, Tags mit einem Owner zu kennzeichnen. Ohne Verantwortlichkeit entsteht schnell eine Sammlung aus alten Triggern, doppelten Integrationen und Custom-HTML-Tags, deren Zweck nur noch historisch bekannt ist.
Ein sauberer Audit behandelt ein Drittanbieter-Skript deshalb nicht nur als technische Datei, sondern als betriebliche Abhängigkeit mit Eigentümer, Zweck und Ablaufdatum.
Ein brauchbares Inventar braucht mehr als den Skriptnamen
Für jedes Drittanbieter-System sollte mindestens dokumentiert sein:
| Frage | Warum sie zählt |
|---|---|
| Wer ist fachlich verantwortlich? | Jemand muss entscheiden können, ob das Tool noch gebraucht wird. |
| Welchen Geschäftszweck erfüllt es? | „War schon immer da“ ist kein belastbarer Zweck. |
| Auf welchen Seitentypen muss es laufen? | Viele Tags müssen nicht siteweit geladen werden. |
| Wann darf es starten? | Kritische Funktionen brauchen andere Priorität als ein später Analyse- oder Chat-Use-Case. |
| Welche weiteren Origins und Ressourcen lädt es? | Ein kleines Loader-Skript kann eine große Kette auslösen. |
| Wie viel Main-Thread-Zeit verbraucht es? | Bytes allein zeigen nicht, wie teuer JavaScript in der Ausführung ist. |
| Verändert es sichtbaren DOM-Inhalt? | Späte Einblendungen können Layout Shifts oder Rendering-Arbeit erzeugen. |
| Was passiert, wenn der Anbieter langsam oder nicht erreichbar ist? | Externe Verfügbarkeit darf zentrale Seitenfunktionen nicht unnötig blockieren. |
| Wie wird es getestet und zurückgerollt? | Tag-Änderungen sind Produktionsänderungen. |
| Wann wird der Nutzen erneut geprüft? | Sonst bleiben temporäre Tools dauerhaft bestehen. |
Dieses Inventar ist zugleich Performance-Dokumentation und Handover-Material.
Nicht jedes Tag gehört auf jede Seite
Eine der wirkungsvollsten Maßnahmen ist oft erstaunlich banal: Nicht laden, was auf dieser Seite nicht gebraucht wird.
Ein Terminbuchungs-Widget muss nicht auf einer reinen Wissensseite initialisiert werden. Ein Bewertungs-Badge braucht vielleicht nur die Startseite. Ein A/B-Test für den Checkout sollte nicht automatisch auf dem gesamten Magazin laufen.
web.dev empfiehlt, Trigger so spezifisch wie möglich zu setzen und nicht essenzielle Tags später zu laden. Je früher ein Tag startet, desto stärker konkurriert es während der ohnehin ressourcenintensiven Initialphase der Seite.
Das bedeutet nicht, alles pauschal „nach fünf Sekunden“ zu verschieben. Gute Ladeentscheidungen orientieren sich am tatsächlichen Produktmoment:
- Braucht der Nutzer die Funktion sofort?
- Reicht Laden bei Sichtbarkeit des Widgets?
- Reicht Laden nach einer konkreten Interaktion?
- Muss ein Analyse-Event wirklich vor dem ersten Paint verarbeitet werden?
- Gibt es eine serverseitige oder leichtere Alternative?
async und defer lösen nicht jedes Problem
Asynchrones Laden ist wichtig, aber es macht JavaScript nicht kostenlos.
Ein Skript kann den HTML-Parser nicht blockieren und später trotzdem genau in dem Moment CPU-Zeit beanspruchen, in dem ein Nutzer ein Menü öffnet oder ein Formular ausfüllt. Für INP ist nicht nur relevant, wann eine Datei heruntergeladen wurde, sondern wann und wie lange ihre Arbeit den Main Thread belegt.
Deshalb reicht ein Quellcode-Review der Script-Tags nicht aus. Man muss die Seite unter realistischen Bedingungen messen.
Chrome DevTools kann im Performance-Panel Drittanbieteraktivität von First-Party-Code unterscheiden und Drittanbieter nach verbrauchten Ressourcen und CPU-Aktivität sichtbar machen. Im Network-Panel lassen sich außerdem gezielt nur Third-Party-Requests anzeigen.
Damit wird aus „Unsere Seite hat viele externe Skripte“ eine konkrete Aussage wie:
„Dieser Anbieter erzeugt auf der Landingpage mehrere Folge-Requests und belegt während der Interaktionsphase relevante Main-Thread-Zeit, obwohl sein Widget erst nach einem Klick gebraucht wird.“
Das ist eine Information, auf deren Basis man entscheiden kann.
Der wichtigste Test: Was passiert, wenn der Anbieter fehlt?
Performance-Audits messen häufig nur den Normalfall. Für Drittanbieter ist der Fehlerfall mindestens genauso interessant.
Chrome DevTools bietet Request Blocking und Throttling, mit denen einzelne Requests oder Domains lokal blockiert oder verlangsamt werden können. Damit lässt sich prüfen:
- Bleibt die Navigation bedienbar?
- Kann ein Formular weiterhin abgesendet werden?
- Bleibt der Cookie- oder Consent-Dialog funktionsfähig?
- Wird ein leerer Widget-Container sauber ausgeblendet?
- Wartet eigener Code endlos auf ein externes Callback?
- Entstehen Konsolenfehler, die andere Funktionen stoppen?
- Springt das Layout, wenn ein Embed verspätet erscheint?
Ein Marketing-Tool darf gerne ausfallen. Die Kernfunktion der Website sollte deshalb nicht unnötig mit ausfallen.
Performance-Budgets sollten Geschäftswert enthalten
Ein klassisches Performance-Budget setzt Grenzwerte für JavaScript, Requests oder Metriken. Für Drittanbieter ist eine zusätzliche Spalte sinnvoll: Welchen nachweisbaren Nutzen kaufen wir mit diesem Budget?
Ein einfaches Review kann etwa so aussehen:
| Integration | Zweck | Seiten | Ladezeitpunkt | technischer Aufwand | messbarer Nutzen | Entscheidung |
|---|---|---|---|---|---|---|
| Analytics | Produkt-/Marketingmessung | relevante Seiten | nach erforderlichem Consent/Setup | mittel | aktiv genutzt | behalten, beobachten |
| Chat | Lead-Kontakt | Leistungsseiten | bei Interaktion oder spät | hoch | geringe Nutzung | Lazy Load testen |
| altes A/B-Tool | ehemalige Kampagne | siteweit | früh | hoch | keiner mehr | entfernen |
| Video-Embed | Produktdemo | eine Seite | bei Sichtbarkeit/Klick | mittel | hoher Nutzen | begrenzen |
Die Werte müssen nicht perfekt wissenschaftlich sein. Der entscheidende Schritt ist, technische Kosten und Geschäftswert gemeinsam zu betrachten.
Denn „Wir brauchen das fürs Marketing“ und „Das macht die Seite langsam“ sind keine gegensätzlichen Wahrheiten. Beides kann gleichzeitig stimmen. Dann ist die Aufgabe, die Integration so zu gestalten, dass der Wert bleibt und die Last sinkt.
Was Website-Pflichtencheck bei Drittanbieter-Skripten prüfen würde
Bei einem technischen Website-Check betrachten wir nicht nur die Anzahl externer Requests. Je nach Seite und Ziel gehören dazu unter anderem:
- Inventar der Drittanbieter-Origins und Skripte,
- Initiator-Ketten: welches Skript lädt welche weiteren Ressourcen,
- Script-Größe und Netzwerkverhalten,
- Main-Thread- und Long-Task-Aktivität,
- auffällige Auswirkungen auf LCP, INP und CLS,
- doppelte oder offensichtlich ungenutzte Integrationen,
- Tag-Manager-Trigger und unnötig globale Ausführung,
- Ladeverhalten vor und nach relevanten Nutzeraktionen,
- Verhalten bei blockierten oder langsamen Drittanbieter-Domains,
- sichtbare DOM-Injektionen und Layout-Veränderungen,
- technische Verantwortlichkeit und dokumentierte Rückbauoptionen.
Das Ergebnis sollte keine pauschale Liste „böser Skripte“ sein. Sinnvoller ist eine priorisierte Entscheidungsliste: entfernen, begrenzen, später laden, technisch ersetzen, beobachten oder bewusst akzeptieren.
Eine gute Website kennt den Preis ihrer Abhängigkeiten
Drittanbieter-Tools sind nicht grundsätzlich ein Problem. Sie ermöglichen Funktionen, die niemand vernünftigerweise jedes Mal selbst bauen möchte.
Problematisch wird es, wenn ihre Kosten unsichtbar werden.
Wer jedes Tag einem Zweck, einem Owner und einem Performance-Budget zuordnet, kann deutlich leichter entscheiden, welche Integrationen ihren Platz verdienen. Und wenn eine Website sich „irgendwie langsam“ anfühlt, obwohl der eigene Code gar nicht dramatisch gewachsen ist, ist genau dieses Drittanbieter-Inventar ein sehr guter Ort, um mit der Suche zu beginnen.
Website-Pflichtencheck kann dabei helfen, die tatsächliche technische Last sichtbar zu machen und daraus konkrete, priorisierte Maßnahmen abzuleiten – ohne funktionierende Marketing- oder Produktprozesse reflexartig abzuschalten.