Dreizehn externe Anfragen beim ersten Klick

Wenn ein Browser eine externe Skript-Datei lädt, passiert das nicht in einem Schritt. Er löst zunächst den Domainnamen auf (DNS-Auflösung), baut eine TCP-Verbindung auf, handelt ein HTTPS-Zertifikat aus, lädt die Datei herunter und führt anschließend den JavaScript-Code aus. Diese Kette dauert bei guter Verbindung zwischen 100 und 400 Millisekunden — pro Anfrage. Bei dreizehn Anfragen addiert sich das.

Manche Skripte sind render-blockierend: Der Browser stoppt das Rendern der Seite, bis das Skript vollständig geladen und verarbeitet ist. Das bedeutet: Der Besucher sieht nichts — obwohl die eigentliche Seite längst bereit wäre. Was in der Entwicklungsumgebung mit schneller Leitung unsichtbar bleibt, ist auf dem Mobilnetz eines Besuchers spürbar. Und die ersten Sekunden des Wartens bekommt man nie zurück.

Messbar wird das über die Core Web Vitals — Googles Kennzahlen für Nutzererlebnis, die seit 2021 in das Suchranking einfließen. Drittanbieter-Skripte verschlechtern dabei gleich mehrere Werte: Sie verzögern den Moment, in dem das erste sichtbare Element lädt, und blockieren den Browser während der Skriptausführung, was die Reaktion auf Klicks verlangsamt. Anders als eigene Bilder oder eigener Code sind externe Skripte oft die letzte Optimierungsquelle, die bei einer Analyse überhaupt geprüft wird.

Das Problem entsteht nicht durch Nachlässigkeit. Es entsteht durch viele kleine, vernünftige Entscheidungen.

Ein Unternehmen startet mit einem Analytics-Tool — sinnvoll, man will wissen, was auf der Website passiert. Dann kommt ein Chat-Widget, weil der Vertrieb direkte Anfragen auf der Website will. Dann ein Heatmap-Dienst, weil das Marketing verstehen möchte, wo Besucher abspringen. Ein A/B-Test-Tool. Ein eingebetteter Kalender. Ein Consent-Manager, der seinerseits weitere Dienste koordiniert. Für eine Kampagne wird ein Werbepixel eingebunden.

Jede dieser Entscheidungen ist für sich nachvollziehbar. Niemand hat dabei gedacht: Ich mache die Website jetzt langsamer. Die Entscheidungen fallen zu verschiedenen Zeitpunkten, in verschiedenen Gesprächen, manchmal in verschiedenen Teams. Marketing entscheidet das Tool. Die Agentur oder das Entwicklungsteam baut es ein. Niemand prüft das Gesamtbild.

Google Tag Manager löst dieses Problem nicht. Er ist ein Container, der das Verwalten von Skripten erleichtert — aber den Payload, den er lädt, verändert er nicht. Mit Tag Manager lassen sich dreißig Skripte bequem koordinieren. Schneller werden sie dadurch nicht.

Es gibt in den meisten Unternehmen niemanden, der periodisch prüft: Welche Skripte sind gerade aktiv? Welche werden tatsächlich ausgewertet? Welche wurden eingebunden und seitdem vergessen?

Das Heatmap-Dashboard wird seit einem Jahr nicht mehr aufgerufen. Das Chat-Tool wurde durch ein neueres ersetzt, aber das alte Skript läuft noch. Der Werbepixel wurde für eine Kampagne eingebunden, die vor Monaten endete. Das A/B-Test-Tool ist noch aktiv, obwohl der Test längst abgeschlossen ist. Nichts davon verursacht eine Fehlermeldung. Alles davon kostet Ladezeit.

Was ein Audit dieser Skripte regelmäßig aufzeigt: Aktive Skripte, die kein Team mehr auswertet. Dienste, die sich mit neueren Lösungen überlappen. Skripte, die Nutzerdaten an externe Server übertragen, ohne dass das im Consent-Banner abgebildet ist. Das ist kein Ausnahmefall — es ist das Ergebnis von Jahren ohne Gesamtblick.

Der Ausgangspunkt ist eine vollständige Liste — nicht ungefähr, sondern konkret. Wer im Browser-Netzwerk-Tab beim ersten Seitenaufruf schaut oder Google Lighthouse ausführt, bekommt in wenigen Minuten eine Übersicht: was aktiv ist, wie lange es lädt, was render-blockierend läuft, obwohl es das nicht müsste. Beides ist kostenlos und ohne Entwicklerkenntnisse nutzbar.

Einige Skripte lassen sich mit dem async- oder defer-Attribut laden, ohne das Rendering zu blockieren. Skripte, die personenbezogene Daten übertragen, lassen sich erst nach Consent laden — was automatisch verhindert, dass sie beim ersten Seitenaufruf ausgeführt werden. Skripte, die niemand mehr auswertet, lassen sich entfernen. Keiner dieser Schritte erfordert ein Redesign.

Das ist auch kein einmaliges Projekt. Neue Tools kommen. Kampagnen enden. Teams verändern sich. Ein Skript, das heute sinnvoll ist, kann in einem Jahr inaktiv sein — und trotzdem bei jedem Aufruf laden. Der Stack braucht keinen eigenen Beauftragten, aber einen periodischen Moment der Aufmerksamkeit.

Die eigentliche Frage ist nicht, welche Tools ein Unternehmen nutzt. Die Frage ist: Wer behält den Überblick darüber, was diese Tools beim ersten Seitenaufruf kosten? Jede Entscheidung für ein neues Tool ist eine Ladezeit-Entscheidung. Die meisten werden ohne diesen Gedanken getroffen.