Drittanbieter-Skripte: Wie sie deine Ladezeit bremsen

Drittanbieter-Skripte sind JavaScript-Dateien, die nicht von deinem eigenen Server kommen: Analytics, Tag Manager, Consent-Banner, Chat-Widgets, Social-Buttons, eingebettete Videos, Karten, A/B-Test-Werkzeuge, Werbepixel. Jedes einzelne davon hat einen nachvollziehbaren Zweck, und trotzdem ist die Summe oft der Grund, warum eine sauber gebaute Seite träge wirkt. Der Kern des Problems: Du kontrollierst weder die Dateigröße noch den Code noch die Antwortzeit des fremden Servers, bezahlst aber mit der Ladezeit deiner Besucher.

Dieser Beitrag betrachtet Geschwindigkeit deshalb nicht pro Kennzahl, sondern pro Skriptquelle. Die Frage lautet nicht „Wie verbessere ich LCP oder INP?“, sondern „Welches Skript kostet mich was, und was davon ist es wert?“ Du bekommst eine Methode, um Drittanbieter-Code zu inventarisieren, zu messen und in drei Gruppen zu sortieren: behalten, später laden, entfernen.

Warum fremder Code teurer ist als eigener

Ein eigenes Skript kannst du minimieren, bündeln, cachen und im Zweifel umschreiben. Bei einem Drittanbieter-Skript hast du nichts davon in der Hand. Der Anbieter darf es morgen um zehn Funktionen erweitern, ohne dass du etwas merkst, und dein Lighthouse-Wert kippt ohne einen einzigen Commit auf deiner Seite. Dazu kommen Kosten, die in keiner Dateigrößen-Tabelle auftauchen.

Der erste Kostenblock ist das Netzwerk. Für jede neue Domain braucht der Browser eine DNS-Auflösung, einen TCP-Verbindungsaufbau und einen TLS-Handshake, bevor überhaupt ein Byte Nutzlast fließt. Hat ein Widget fünf Hosts im Schlepptau, vervielfacht sich dieser Aufwand. Der zweite Block ist der Hauptthread: Der Browser muss das Skript herunterladen, parsen, kompilieren und ausführen, und während dieser Zeit kann er keine Klicks verarbeiten und kein Layout berechnen. Der dritte Block ist die Kettenreaktion. Viele Skripte laden weitere Skripte nach, und ein Tag Manager lädt Tags, die wiederum Pixel, Schriften und Stylesheets holen. Was im HTML nach einer Zeile aussieht, sind in Wahrheit Dutzende Anfragen.

Dazu kommt ein Effekt, der gern übersehen wird: Drittanbieter-Code verändert die Seite. Ein Chat-Widget blendet nach zwei Sekunden eine Schaltfläche ein, ein Consent-Banner schiebt den Inhalt nach unten, ein Bewertungs-Widget reserviert keinen Platz und lässt das Layout springen. Damit treffen fremde Skripte mehrere Web-Vitals-Werte gleichzeitig, was erklärt, warum die Suche nach einer einzelnen Ursache oft ins Leere läuft.

Inventur: Welche Drittanbieter laufen überhaupt auf deiner Seite?

Bevor du etwas optimierst, brauchst du eine vollständige Liste. Sie ist fast immer länger als gedacht, weil Skripte über Jahre angesammelt wurden: Jemand hat vor drei Jahren einen Heatmap-Test gestartet, eine Agentur hat einen Remarketing-Pixel eingebaut, ein Plugin lädt still eine Schriftart von einem fremden Server. So gehst du vor:

• Netzwerk-Tab der Browser-Entwicklertools: Seite bei leerem Cache neu laden, nach Domain sortieren und alles markieren, was nicht zu deiner eigenen Domain oder deinem CDN gehört. Die Spalte mit der Dateigröße allein reicht nicht, achte auch auf die Wasserfall-Darstellung und darauf, welche Anfrage welche andere ausgelöst hat.
• Lighthouse oder PageSpeed Insights: Der Bericht gruppiert die Last nach Drittanbietern und zeigt die Blockierzeit des Hauptthreads je Anbieter. Das ist die schnellste Rangliste, die du bekommst, und sie trennt Übertragungsgröße von Ausführungszeit.
• Performance-Panel: Nimm die Seite auf und suche nach langen Aufgaben (Long Tasks, über 50 Millisekunden). Die Aufrufliste verrät, ob ein Skript von dir oder von einem Anbieter stammt.
• Tag-Manager-Container selbst: Öffne die Liste aller Tags, Trigger und Variablen. Hier stehen oft Tags, die niemand mehr kennt, deren Pixel aber weiter feuern.
• Quelltext und Templates: Suche nach eingebetteten Iframes, Skript-Tags im Footer und nach Plugins, die Skripte per Hook einschleusen. Nicht jedes Skript taucht beim ersten Seitenaufruf auf, manche laden erst nach einer Interaktion oder nur auf bestimmten Vorlagen.

Messen statt raten: Was ein Skript wirklich kostet

Die Dateigröße ist ein schlechter Maßstab. Ein kleines Skript, das synchron eine Schleife über das ganze DOM fährt, kann schlimmer sein als ein großes, das sich im Hintergrund still verhält. Aussagekräftiger ist der Vergleich mit und ohne Skript. In den Entwicklertools kannst du einzelne Anfragen blockieren und die Seite danach neu messen; bei einem Tag Manager pausierst du einzelne Tags in der Vorschau. Wiederhole jede Messung mehrmals, denn Laborwerte schwanken, und wechsle zwischen einem gedrosselten Mobilprofil und deiner normalen Verbindung.

Beachte dabei den Unterschied zwischen Labor- und Felddaten. Lighthouse misst einen einzelnen synthetischen Ladevorgang, ohne Login, ohne Cookie-Zustimmung und ohne Interaktion. Genau dort zeigt sich aber nicht, was ein Chat-Widget nach dem ersten Klick oder ein Consent-Dialog bei echten Besuchern auslöst. Die Felddaten im Chrome-Nutzerbericht, die du in der Search Console unter den Core Web Vitals findest, spiegeln dagegen echte Geräte, allerdings nur aggregiert und mit Verzögerung. Gute Praxis ist, beides zu kombinieren: Das Labor zeigt dir den Verdacht, das Feld bestätigt, ob er für echte Nutzer zählt.

Ein Beispiel für die Rechnung: Eine Produktseite lädt Analytics, einen Werbepixel, ein Chat-Widget und einen Video-Embed. Du blockierst nacheinander jeden der vier und merkst, dass der Chat allein einen großen Teil der Hauptthread-Blockierung ausmacht, obwohl er auf der Seite nur als kleine Schaltfläche sichtbar ist. Damit hast du einen klaren Kandidaten für eine Verzögerung, ohne dass du eine Zahl erfinden müsstest: Du vergleichst schlicht zwei Messungen derselben Seite.

Die drei Stellhebel: entfernen, verzögern, ersetzen

Jedes Drittanbieter-Skript landet nach der Inventur in einer von drei Schubladen. Die Reihenfolge der Prüfung ist wichtig, weil die billigste Lösung immer die ist, den Code gar nicht erst zu laden.

Entfernen. Stelle bei jedem Skript die unbequeme Frage, wer den Nutzen im letzten Quartal tatsächlich gesehen hat. Ein Heatmap-Werkzeug, dessen Berichte niemand öffnet, ein Social-Share-Zähler, dessen Zahlen niemand anzeigt, ein zweiter Analytics-Dienst, der nur aus Gewohnheit mitläuft: All das kann weg. Entfernen ist der einzige Hebel, der Ladezeit, Datenschutzaufwand und Wartung gleichzeitig senkt.

Verzögern. Was bleiben soll, aber nicht für das erste Rendering gebraucht wird, lädt später. Dazu gehören Chat, Bewertungs-Widgets, Heatmaps und die meisten Marketing-Pixel. Technisch stehen dir dafür mehrere Wege offen, die im nächsten Abschnitt im Detail folgen.

Ersetzen. Manchmal gibt es für den gleichen Zweck eine leichtere Lösung: ein Link zu einem Kartenanbieter statt einer interaktiven Karte, ein statisches Vorschaubild mit Klick statt eines Video-Players, ein schlichter Teilen-Link statt fünf Social-Buttons mit eigenem Skript, selbst gehostete Schriften statt eines Schriftdienstes von einer fremden Domain. Der Nutzen bleibt, die Kosten fallen.

Techniken zum späteren Laden im Detail

Das Attribut async lädt ein Skript parallel zum Parsen des HTML und führt es aus, sobald es fertig ist. Das ist für eigenständige Skripte wie Analytics geeignet, kann die Ausführung aber mitten in das Rendering schieben. Das Attribut defer lädt ebenfalls parallel, führt aber erst nach dem Parsen des Dokuments aus und hält die Reihenfolge ein. Für Skripte, die auf das DOM angewiesen sind, ist das meist die bessere Wahl. Ein Skript ohne beide Attribute blockiert den Parser komplett und gehört im Kopfbereich praktisch nie hin.

Async und Defer verschieben aber nur den Zeitpunkt des Starts, nicht die Arbeit selbst. Ein Skript, das nach zwei Sekunden anläuft, blockiert den Hauptthread dann eben zwei Sekunden später, möglicherweise genau in dem Moment, in dem der Besucher auf eine Schaltfläche tippt. Wirksamer ist deshalb, Skripte an eine Bedingung zu koppeln:

• Nach dem Load-Ereignis oder im Leerlauf laden: Das Skript wird erst eingefügt, wenn die Seite fertig aufgebaut ist, etwa über ein Window-Loaded-Ereignis oder über den Leerlauf-Callback des Browsers.
• Nach der ersten Interaktion laden: Das Skript startet erst bei Scrollen, Klick oder Tastendruck. Besucher, die nur lesen und gehen, lösen nichts aus. Der Nachteil: Wer früh abspringt, taucht in der Statistik nicht auf, was bei Analytics-Skripten zu verzerrten Zahlen führt. Nutze diese Technik deshalb für Chat und ähnliche Funktionen, nicht pauschal für Messung.
• Bei Sichtbarkeit laden: Ein Widget weit unten auf der Seite braucht erst Code, wenn der Bereich in den sichtbaren Ausschnitt rückt. Der Intersection Observer des Browsers erledigt das ohne Zusatzbibliothek.
• Verbindungen vorbereiten: Mit preconnect für die eine oder andere kritische Fremddomain sparst du den Handshake, aber setze es sparsam ein. Zu viele Vorverbindungen konkurrieren mit wichtigen Ressourcen um Bandbreite.
• In einen Web Worker auslagern: Bibliotheken wie Partytown verschieben Skripte vom Hauptthread in einen Worker. Das kann gut funktionieren, verlangt aber Tests, weil Skripte, die synchron auf das DOM zugreifen, sich anders verhalten können.

Fassaden: Chat, Video und Karten erst bei Bedarf laden

Eine Fassade (englisch Facade) ist ein leichter Platzhalter, der aussieht wie das echte Widget, aber keinen Fremdcode lädt. Erst wenn jemand klickt oder mit der Maus darüberfährt, tauscht die Seite den Platzhalter gegen das echte Element aus. Die drei klassischen Kandidaten sind Videos, Chat und Karten.

Bei einem eingebetteten Video besteht die Fassade aus einem Vorschaubild mit Abspielsymbol. Ein normaler Video-Iframe zieht schon beim Seitenaufruf Player-Skripte, Schriften und Tracking nach, obwohl vielleicht nur jeder zehnte Besucher auf Play drückt. Bei einem Chat-Widget wird eine statische Schaltfläche ausgeliefert, die nach dem Klick das eigentliche Chat-Skript nachlädt und das Fenster öffnet. Die Wartezeit von einem Augenblick nach dem Klick ist in der Praxis meist akzeptabel, weil der Besucher ohnehin mit einer kurzen Reaktion rechnet. Bei Karten ersetzt ein Vorschaubild mit Adresse und Klick-Schaltfläche die interaktive Karte.

Zwei Fallstricke: Erstens muss die Fassade ihren Platz exakt reservieren, sonst springt das Layout beim Austausch. Gib dem Platzhalter feste Maße oder ein Seitenverhältnis. Zweite Falle: Die Fassade darf nicht das größte sichtbare Element im ersten Bildschirm sein, ohne Teil deiner Ladestrategie zu sein. Liegt ein Video-Vorschaubild oberhalb der Falz, ist es oft der LCP-Kandidat und sollte wie jedes andere wichtige Bild behandelt werden, mit passender Größe und ohne Lazy Loading. Weiter unten auf der Seite hilft das Attribut loading=lazy für Iframes, das den Ladevorgang bis kurz vor die Sichtbarkeit aufschiebt.

Aus Sicht der Suche gilt für Fassaden dasselbe wie für jeden Inhalt, der erst nach einer Interaktion erscheint: Was wichtig für das Ranking ist, gehört nicht in ein Element, das erst beim Klick geladen wird. Ein Video darf hinter einer Fassade stehen, der beschreibende Text drumherum sollte aber im HTML liegen.

Tag Manager und Consent: die Schaltzentrale, die selbst bremst

Ein Tag Manager ist bequem, weil Marketing neue Tags ohne Entwickler einspielen kann. Genau das ist sein Risiko: Der Container wächst, und jeder Tag ist ein Drittanbieter-Skript, das niemand im Code-Review sieht. Der Container selbst ist zudem ein Skript, das früh geladen wird und dann weitere Skripte nachzieht. Drei Regeln helfen.

Erstens: Miss den Container wie jedes andere Skript. Pausiere ihn testweise und vergleiche. Zweitens: Räume auf. Tags ohne aktiven Zweck, doppelte Pixel (etwa einer im Container und derselbe fest im Theme) und Trigger, die auf jeder Seite feuern, obwohl sie nur auf der Bestellbestätigung nötig sind, kosten Zeit ohne Nutzen. Drittens: Wähle Trigger bewusst. Der früheste Auslöser ist selten nötig; ein Marketing-Pixel braucht keinen Start vor dem ersten Rendering.

Consent-Banner sind ein Sonderfall, weil sie zwei Rollen vereinen. Sie sind ein Drittanbieter-Skript und zugleich der Schalter, der über das Laden aller anderen entscheidet. Laden sie spät, hängen alle abhängigen Tags mit. Laden sie synchron im Kopf, blockieren sie das Rendering. Zudem erscheinen sie oft als großes Element im ersten Bildschirm: Der Banner kann selbst zum LCP-Element werden oder die Seite beim Einblenden verschieben. Reserviere seinen Platz, etwa als feste Leiste am unteren Rand, die den Inhalt überlagert statt ihn zu verschieben, und prüfe, ob dein Anbieter ein schlankes Ladeverfahren unterstützt.

Ein Nebeneffekt, der für die Messung zählt: Wer die Einwilligung verweigert, lädt weniger Skripte. Die Ladezeit hängt also vom Zustimmungsverhalten ab, und Labortests ohne Interaktion zeigen meist den Zustand vor der Entscheidung. Teste deshalb beide Zustände. Die rechtliche Seite, also welche Tags ohne Einwilligung überhaupt laden dürfen, klärst du mit deiner Datenschutzberatung; aus Performance-Sicht ist wichtig, dass ein Skript, das ohnehin nicht laden darf, auch nicht vorher Verbindungen aufbauen sollte.

Dauerhaft im Griff: Regeln gegen das Wiederauswuchern

Eine einmalige Bereinigung hilft nur, bis das nächste Werkzeug eingebaut wird. Damit der Zustand hält, brauchst du Verfahren, keine Einzelaktion:

• Aufnahmeregel: Jedes neue Drittanbieter-Skript braucht einen benannten Verantwortlichen, einen Zweck und ein Datum für die Überprüfung. Ohne diese drei Angaben geht es nicht live.
• Messung vor dem Go-live: Teste die Seite vor und nach dem Einbau. Wer die Kosten sieht, bevor der Code läuft, entscheidet anders als jemand, der sie Monate später entdeckt.
• Regelmäßige Inventur: Ein Termin pro Quartal genügt, um die Liste mit der Realität abzugleichen und tote Tags zu löschen.
• Leistungsbudget für Fremdcode: Lege fest, wie viel Hauptthread-Zeit Drittanbieter insgesamt beanspruchen dürfen, und bewerte neue Wünsche gegen dieses Budget.
• Ablauf bei Anbieterwechsel: Wird ein Dienst ersetzt, muss der alte Code nachweislich verschwinden. Bleibt der Altpixel im Container, zahlst du doppelt.

Typische Fehler beim Zähmen von Drittanbieter-Code

Der häufigste Fehler ist, alles pauschal zu verzögern. Wer Analytics erst nach der ersten Interaktion startet, verliert Besuche, die nie interagieren, und wundert sich über eine höhere Absprungrate in den Berichten. Verzögere nach Funktion, nicht nach Gewohnheit: Messung früh und schlank, Komfortfunktionen spät.

Der zweite Fehler ist, sich auf den Lighthouse-Wert zu fixieren. Ein Skript, das erst nach einem Klick lädt, verbessert den Laborwert, kann aber die Reaktionszeit beim ersten Klick verschlechtern. Prüfe daher die Interaktion selbst und nicht nur das Laden. Der dritte Fehler: Fremde Skripte auf die eigene Domain kopieren, ohne sie zu pflegen. Selbst gehostete Kopien veralten, und manche Dienste funktionieren ohne ihre Server nicht richtig. Das Hosten von Schriften, Bibliotheken und statischen Hilfsdateien ist sinnvoll; das Kopieren eines Werbe- oder Messcodes meistens nicht.

Viertens wird oft vergessen, dass eine Änderung am Skript auch die Funktion berühren kann. Nach jeder Verzögerung oder Fassade solltest du prüfen, ob der Chat noch Nachrichten annimmt, ob die Conversion-Messung noch feuert und ob das Banner die Einwilligung weiterhin korrekt weitergibt. Eine schnelle Seite, deren Messung kaputt ist, hilft niemandem.