Drittanbieter-Skripte: Gewicht, das Sie nicht geschrieben haben

Analytics, Tag-Manager, Chat-Widgets und Pixel wirken einzeln harmlos. Zusammen entscheiden sie, wie schnell Ihre Seite ist — so verschaffen Sie sich einen Überblick und dünnen sie aus.

Performance · Veröffentlicht: 3. Oktober 2026 · 6 Min. Lesezeit · Ольга Мирошник

Öffnen Sie auf fast jeder kommerziellen Website das Network-Panel und zählen Sie die Domains. Die eigene Domain, ein CDN, dann ein langer Schwanz: Analytics, ein Tag-Manager, zwei Werbepixel, ein Chat-Widget, ein A/B-Testing-Tool, ein Font-Dienst, eine Karte, ein eingebettetes Video. Keine Zeile dieses Codes hat Ihr Team geschrieben, nichts davon läuft durch Ihre Code-Reviews — und alles läuft mit denselben Rechten wie Ihr eigenes JavaScript.

Jedes Tag wurde aus gutem Grund von jemandem eingebaut, der es brauchte. Das Problem: Für die Summe ist niemand zuständig.

Was jede neue Origin kostet

Verbindungsaufbau. Eine neue Domain bedeutet DNS-Lookup, TCP-Handshake und TLS-Aushandlung, bevor das erste Byte des Skripts ankommt. Im Mobilfunknetz sind das schnell mehrere hundert Millisekunden pro Origin, und ein Skript, das weitere Skripte von noch einer Domain nachlädt, zahlt den Preis erneut.

Zeit im Main Thread. Drittanbieter-JavaScript muss heruntergeladen, geparst und ausgeführt werden — im selben Thread, der Klicks und Taps verarbeitet. Ein Chat-Widget, das ein ganzes UI-Framework hochfährt, oder ein A/B-Tool, das das DOM umschreibt, konkurriert direkt mit den Interaktionen auf Ihrer Seite, und das zeigt sich in einem schlechten INP (Interaction to Next Paint).

Render-Blocking. Ein schlichtes <script src> im <head> ohne async oder defer hält den Parser an, bis es geladen und ausgeführt ist. Manche A/B-Test-Snippets tun das absichtlich und blenden die Seite aus, bis sie fertig sind, um Flackern zu vermeiden.

Single Point of Failure. Ist der Server eines Anbieters langsam oder down, macht ein blockierendes Skript auch Ihre Seite langsam oder leer. Ihre Verfügbarkeit hängt jetzt von seiner ab, und Ihr Monitoring sagt Ihnen nicht, warum.

Datenschutz und Einwilligung. Ein Pixel, das feuert, bevor der Besucher auf das Cookie-Banner reagiert hat, schickt seine Daten ohne Einwilligung an Dritte. Oft genügt schon das Laden des Skripts, um IP-Adresse und Referrer zu übertragen.

Sicherheit. Jedes externe Skript ist Teil Ihrer Lieferkette. Wird der Anbieter oder das CDN kompromittiert, läuft der Code des Angreifers auf Ihrer Checkout-Seite. Eine strikte Content Security Policy wird deutlich schwieriger, wenn die Allowlist mit jedem Tag wächst.

Bestandsaufnahme

Beginnen Sie mit Fakten statt mit Erinnerungen:

Öffnen Sie in den Chrome DevTools Network, laden Sie neu und gruppieren oder sortieren Sie nach Domain. Notieren Sie jede fremde Origin und was von ihr geladen wird.
Öffnen Sie das Coverage-Panel, um zu sehen, wie viel von jedem Skript auf einer typischen Seite tatsächlich ausgeführt wird.
Schauen Sie in den Tag-Manager: Listen Sie jedes Tag, seinen Trigger und das Datum der letzten Änderung auf.

Stellen Sie zu jedem Tag drei Fragen. Wem gehört es? Kann niemand eine Person oder ein Team nennen, ist es ein Kandidat zum Löschen. Wird es noch genutzt? Pixel für Kampagnen, die letztes Jahr endeten, und Testversionen nie gekaufter Tools sind häufige Funde. Muss es auf jeder Seite und sofort laden? Meist nicht.

Beim ersten Schritt hilft ein SiteScan-Bericht: Er zählt die Drittanbieter-Origins, von denen Ihre Seiten Ressourcen laden, und warnt, wenn es zu viele sind („Reduzieren Sie die Zahl der Drittanbieter-Origins, von denen die Seiten laden“). Außerdem listet er die auf der Website erkannten Technologien und Widgets auf — ein schneller Weg, ein vergessenes Tool zu entdecken.

Techniken, die funktionieren

Entfernen. Das schnellste Skript ist das, das nicht da ist. Zwei tote Tags zu löschen bringt mehr, als fünf lebende zu optimieren.

Verzögern, was bleibt. Analytics und die meisten Pixel vertragen async oder defer oder lassen sich aus dem Tag-Manager nach dem Laden der Seite auslösen. Nichts, was den ersten Bildschirm nicht zeichnet, sollte ihn blockieren.

Bei Interaktion laden. Ein Chat-Widget oder ein YouTube-Embed muss nicht starten, bevor es jemand will. Zeigen Sie eine leichte Fassade — einen statischen Button oder ein Vorschaubild — und laden Sie das Original erst per Klick:

<button class="chat-facade" type="button">Chat starten</button>
<script>
  document.querySelector(".chat-facade").addEventListener("click", () => {
    const s = document.createElement("script");
    s.src = "https://widget.example-chat.com/loader.js";
    document.head.append(s);
  }, { once: true });
</script>

Selbst hosten, wo die Lizenz es erlaubt. Fonts und kleine Bibliotheken von der eigenen Origin sparen die zusätzliche Verbindung und unterliegen Ihren eigenen Caching-Regeln.

Preconnect sparsam einsetzen. <link rel="preconnect"> hilft für die ein, zwei Drittanbieter-Origins auf dem kritischen Pfad. Für zehn Origins gesetzt, verbraucht es nur frühe Bandbreite und Sockets für Dinge, die nicht dringend sind.

Den Tag-Manager sauber halten. Beschränken Sie, wer veröffentlichen darf, verlangen Sie für jedes Tag eine Beschreibung und einen Verantwortlichen und prüfen Sie den Container regelmäßig. Ein Tag-Manager soll das Hinzufügen von Skripten einfach machen — nicht unsichtbar.

Statische Dateien mit Subresource Integrity festnageln. Bei einer versionierten Bibliothek auf einem öffentlichen CDN sorgt ein integrity-Attribut dafür, dass der Browser eine veränderte Datei ablehnt:

<script src="https://cdn.example.com/lib@2.4.1/lib.min.js"
        integrity="sha384-..."
        crossorigin="anonymous"></script>

SRI funktioniert nicht bei Skripten, die der Anbieter an Ort und Stelle austauscht — genau deshalb verdienen diese die meiste Aufmerksamkeit.

Ein Budget festlegen. Einigen Sie sich auf ein Limit — Zahl der Drittanbieter-Origins, Kilobytes an Drittanbieter-JavaScript — und prüfen Sie es, bevor ein neues Tag live geht. Ein Budget macht aus „nur noch ein Pixel“ eine bewusste Entscheidung.

Checkliste

Jede Drittanbieter-Origin ist mit Verantwortlichem und Zweck erfasst.
Ungenutzte Tags und Pixel abgelaufener Kampagnen sind entfernt.
Kein Drittanbieter-Skript blockiert das Rendern des ersten Bildschirms.
Chat-Widgets und Video-Embeds laden bei Interaktion hinter einer Fassade.
Nichts, was Besucher trackt, lädt vor der Einwilligung.
Preconnect wird nur für die ein, zwei kritischen Origins genutzt.
Statische CDN-Dateien tragen ein integrity-Attribut.
Es gibt ein Drittanbieter-Budget, und neue Tags werden dagegen geprüft.

Ebenfalls lesenswert

Prüfen Sie, was davon auf Ihrer Website steckt

Der kostenlose Scan zeigt kaputte Links, JS-Fehler und Performance-Probleme in einer Minute.

Scan starten