Du lässt den Lighthouse-Test über die Website eines Kunden laufen und der Performance-Wert ist im roten Bereich. Dein erster Reflex: die Bilder sind zu groß. Doch die Bilder sind sauber optimiert. Der eigentliche Bremsklotz sind 28 Skripte, die von fremden Servern nachgeladen werden – ein Chat-Widget, zwei Werbe-Pixel, ein Bewertungs-Widget, der Cookie-Banner, ein A/B-Testing-Tool, der Tag Manager und eine Handvoll Dinge, an die sich niemand mehr erinnert. Willkommen beim vielleicht meistunterschätzten Performance-Problem des Jahres 2026.
Third-Party-Skripte sind Code, den nicht du, sondern ein externer Anbieter ausliefert und kontrolliert. Sie sind praktisch, weil sie in Minuten Funktionen hinzufügen. Und sie sind gefährlich, weil sie sich still summieren, bis die Website spürbar langsamer wird und die Datenschutzerklärung ausufert. Beide Probleme haben dieselbe Wurzel – und lassen sich mit demselben Aufräumen lösen.
Third-Party-Skripte reduzieren: warum das Problem 2026 wächst
Das Ausmaß ist gut dokumentiert. Laut dem Web Almanac 2025 von HTTP Archive binden über 90 % aller Seiten mindestens einen Drittanbieter ein. Im Median lädt eine durchschnittliche Seite 83 Third-Party-Requests am Desktop und 79 mobil; bei den 1.000 größten Seiten sind es sogar 129 beziehungsweise 106. Und der Trend zeigt nach oben: Gegenüber dem Vorjahr kamen bei den Top-Seiten 15 zusätzliche Requests dazu.
Die häufigsten Kategorien sind Werbenetzwerke, Analytics und CDNs, angeführt von Google-Diensten wie Google Fonts, dem Tag Manager und Google Analytics; Metas Facebook-Skript taucht auf rund 21 % der Seiten auf. Wichtig zu wissen: Der Web Almanac betont selbst, dass diese Zahlen eine Untergrenze sind – durch Techniken wie CNAME-Cloaking und serverseitiges Tracking bleibt ein Teil der Drittanbieter unsichtbar.
Parallel dazu wird das Web spürbar träger. Im selben Datensatz stieg die mediane Total Blocking Time auf Mobilgeräten von 1.209 Millisekunden im Jahr 2024 auf 1.916 Millisekunden 2025 – ein Plus von 58 %. Und nur 48 % der Seiten bestehen mobil die Core Web Vitals. JavaScript, das den Hauptthread blockiert, ist einer der größten Treiber dieser Blockierzeit – und ein erheblicher Teil dieses JavaScripts kommt eben nicht aus deinem Code, sondern von Dritten.
Warum fremde Skripte doppelt teuer sind
Ein Third-Party-Skript kostet dich an zwei Fronten. Technisch belegt es den Hauptthread des Browsers: Solange ein Analytics- oder Werbeskript ausgeführt wird, kann die Seite oft nicht auf Klicks oder Eingaben reagieren. Genau das misst die Interaction to Next Paint, einer der drei Core Web Vitals. Wie du diese Werte gezielt verbesserst, zeigt der Beitrag Core Web Vitals verbessern – doch der schnellste Hebel ist oft, gar nicht erst so viel fremden Code zu laden.
Datenschutzrechtlich ist jedes eingebundene Skript ein Datenfluss zu einem Dritten. Der Browser des Besuchers verbindet sich mit dem Server des Anbieters und überträgt dabei mindestens die IP-Adresse, oft mehr. Für viele dieser Verbindungen brauchst du eine Einwilligung, was den Cookie-Banner aufbläht und die Ladekette weiter verlängert. Die Systematik dahinter – wann ein externer Dienst Einwilligung braucht – beschreibt der Beitrag externe Dienste DSGVO-konform einbinden. Kurz: Weniger Drittanbieter bedeuten gleichzeitig eine schnellere Seite und eine kleinere Angriffsfläche für Abmahnungen.
Schritt 1: Inventur statt Bauchgefühl
Bevor du optimierst, brauchst du eine ehrliche Liste. Öffne die Entwicklertools des Browsers, wechsle in den Netzwerk-Tab und lade die Seite neu. Sortiere nach Domain und markiere alles, was nicht vom Server deines Kunden kommt. Ergänzend zeigt dir ein Tool wie WebPageTest oder der Coverage-Tab von Chrome, wie viel des geladenen Skript-Codes überhaupt genutzt wird – bei fremden Skripten ist der ungenutzte Anteil oft erschreckend hoch.
Ordne jeden Fund einer von drei Kategorien zu: geschäftskritisch, nützlich, oder vergessen. Der vergessene A/B-Test aus der letzten Kampagne, das Pixel eines Werbekanals, der längst abgeschaltet ist, das doppelt eingebundene Analytics – solche Leichen findest du fast in jedem gewachsenen Projekt. Sie fliegen ersatzlos raus. Das ist der schnellste Gewinn und kostet dich außer Prüfzeit nichts.
Schritt 2: Notwendiges richtig laden
Was bleibt, lädst du so, dass es die Seite nicht blockiert. Nicht kritische Skripte gehören mit async oder defer eingebunden, damit sie den Seitenaufbau nicht aufhalten. Für Einbettungen wie YouTube-Videos oder Karten lohnt sich eine Fassade – ein leichtes Vorschaubild, das den schweren Player erst nach dem Klick nachlädt. Das spart beim ersten Seitenaufbau enorm, weil der eigentliche Fremdcode erst dann kommt, wenn der Nutzer ihn wirklich will.
Ein oft übersehener Klassiker ist der Tag Manager. Er wird gerne als „ein einziges Skript" verteidigt, lädt in Wahrheit aber beliebig viele weitere Skripte nach. Prüfe, welche Tags dort tatsächlich aktiv sind, und miste aus – jeder Tag ist ein potenzieller Bremsklotz und ein Datenfluss. Beim Thema Tracking lohnt zusätzlich ein Blick auf Server-side Tracking und was es für die DSGVO heißt, denn es verlagert Last, löst die Einwilligungsfrage aber nicht automatisch.
Schritt 3: Fremdes durch Eigenes ersetzen
Manche Drittanbieter lassen sich schlicht abschaffen, indem du ihre Funktion selbst übernimmst. Der Paradefall sind Schriften: Statt Google Fonts live nachzuladen, hostest du die Schriftdateien selbst auf dem Server deines Kunden. Das spart eine externe Verbindung, beschleunigt den Textaufbau und räumt ein bekanntes Datenschutzrisiko ab – die Details stehen im Beitrag Google Fonts lokal einbinden.
Nach demselben Muster kannst du oft ein schweres Bewertungs-Widget durch statisch eingebundene, ausgewählte Zitate ersetzen oder eine Social-Media-Timeline durch ein simples Verlinken. Nicht jede Funktion rechtfertigt einen dauerhaften Fremdcode auf jeder Seite. Und wenn du ohnehin an der Performance arbeitest, nimm die Bilder gleich mit – Bilder und Third-Party-Skripte sind zusammen für den Löwenanteil des Seitengewichts verantwortlich.
Der dritte Kostenfaktor: Sicherheit
Tempo und Datenschutz sind die offensichtlichen Gründe, fremden Code kurzzuhalten. Der dritte wird gern vergessen: Jedes Third-Party-Skript, das du einbindest, führt fremden Code im Browser deiner Besucher aus – mit den Rechten deiner Seite. Wird der Anbieter kompromittiert, läuft der Schadcode auf der Website deines Kunden, ohne dass dort etwas gehackt wurde. Genau dieses Muster steckt hinter vielen Angriffen auf Bezahl- und Formularseiten und ist eine Spielart des Lieferketten-Risikos, das der Beitrag zum Supply-Chain-Angriff beschreibt.
Die Konsequenz ist dieselbe wie bei Tempo und Datenschutz: Weniger Drittanbieter heißt weniger Vertrauen, das du blind an fremde Server verschenkst. Wo ein Skript zwingend nötig ist, hilft es, es erst nach der Einwilligung zu laden – dann steht der Fremdcode nicht schon beim ersten Seitenaufbau im Browser, sondern nur bei den Besuchern, die aktiv zugestimmt haben. Das entlastet die Ladekette und verkleinert das Zeitfenster für Missbrauch.
Ein ehrliches Wort zu Chat-Widgets
Weil wir selbst aus der Chatbot-Ecke kommen, sei es offen gesagt: Auch ein Chat-Widget ist ein Third-Party-Skript. Wenn du eines einbaust, achte darauf, dass es schlank lädt – idealerweise verzögert und erst bei Interaktion – und dass der Anbieter datensparsam und in der EU gehostet ist. Ein Assistent wie Ragnova sollte einer Kundenseite helfen, nicht ihre Ladezeit ruinieren; die gleiche Sorgfalt, die du jedem anderen Fremdskript widmest, gilt auch hier.
Aus der Optimierung ein Standbein machen
Für kleine Agenturen ist das Aufräumen von Third-Party-Skripten eine dankbare Leistung, weil das Ergebnis messbar ist: ein besserer Lighthouse-Wert, schnellere Ladezeiten, ein schlankerer Cookie-Banner. Das lässt sich dem Kunden zeigen und rechtfertigt ein wiederkehrendes Performance- und Datenschutz-Audit – ein sinnvoller Baustein für jeden Wartungsvertrag.
Ein Hinweis zum Schluss: Die datenschutzrechtliche Bewertung, welche Dienste Einwilligung brauchen, kann im Einzelfall knifflig sein und ersetzt keine Rechtsberatung. Die technische Seite aber ist eindeutig – jeder Drittanbieter, den du entfernst oder zähmst, macht die Seite deines Kunden schneller und datensparsamer zugleich. Selten fallen Tempo und Datenschutz so bequem zusammen.
- Über 90 % aller Seiten binden Drittanbieter ein – im Median 83 Requests am Desktop, bei großen Seiten deutlich mehr, mit steigender Tendenz (Web Almanac 2025).
- Fremde Skripte kosten doppelt: Sie blockieren den Hauptthread des Browsers und sind zugleich ein einwilligungspflichtiger Datenfluss zu Dritten.
- Die mediane Total Blocking Time auf Mobilgeräten stieg 2025 um 58 %; nur 48 % der Seiten bestehen mobil die Core Web Vitals.
- Der schnellste Gewinn ist die Inventur: vergessene Pixel, doppeltes Analytics und tote A/B-Tests ersatzlos entfernen.
- Notwendiges verzögert laden (async/defer, Fassaden), den Tag Manager ausmisten und Fremddienste wie Google Fonts durch selbst gehostete Lösungen ersetzen.