⚡ GTM und Page Speed: Tests, Erkenntnisse und 8 Wege zur Beschleunigung Ihrer Website

Marketer wiederholen oft: „Google Tag Manager beschleunigt Websites, Seiten mit GTM laden schneller." Entwickler argumentieren meist: „GTM macht alles nur langsamer." Die Wahrheit liegt wie so oft zwischen diesen Extremen.

Wir haben eine Testreihe mit unterschiedlichen GTM-Konfigurationen durchgeführt: ein leerer Container, ein Container mit 8 Tracking-Codes, hartcodierte Tags, verschiedene Auslösezeitpunkte, Dutzende benutzerdefinierte HTML-Tags mit DOM-Manipulationen. Gemessen haben wir die Geschwindigkeit über webpagetest.org und Lighthouse. Die Ergebnisse waren weniger eindeutig, als es GTM-Präsentationen behaupten.

Unser Ergebnis: Der GTM-Container selbst bremst kaum etwas, aber was Sie hineinpacken, kann 3 oder 10 Sekunden zur Seitenladezeit hinzufügen. Und das Entscheidende: Sie können das steuern.

💡 Kurzüberblick:

Ein leerer GTM-Container verlängert die Seitenladezeit um etwa 100 Millisekunden
Acht Tracking-Tags über GTM bremsen die Seite um 3 Sekunden auf schnellem 3G und bis zu 10 Sekunden auf langsamen Verbindungen
Dieselben 8 Tags direkt in die Seite hartcodiert bremsen noch stärker
Je später Tags ausgelöst werden, desto geringer ihre Auswirkung: 1,5 Sekunden Verzögerung nach Window Loaded reduziert die Ladezeit um 6 Sekunden auf langsamem 3G
Eine durchdachte Trigger-Konfiguration und Container-Bereinigung stellen die Geschwindigkeit ohne Datenverlust wieder her

So haben wir getestet

Die Methodik ist einfach, aber gründlich. Wir haben jeden Test mindestens dreimal durchgeführt und den Durchschnitt berechnet.

Werkzeuge: webpagetest.org (Server in Irland, EC2, Chrome und Firefox für Desktop, OnePlus 5 für mobile Tests) und die integrierte Lighthouse-Prüfung in den Chrome DevTools. In Lighthouse haben wir sowohl mobile als auch Desktop-Berichte betrachtet. Chrome wurde im Inkognito-Modus gestartet, ohne Erweiterungen, Laptop-Leistung auf Maximum.

Gemessene Metriken:

In webpagetest.org: Document complete (Sekunden, bis statische Inhalte, Bilder, Styles geladen sind) und Fully loaded (der Zeitpunkt nach onLoad, an dem die Netzwerkaktivität für 2 Sekunden abflaut). In Lighthouse: First Meaningful Paint, Time to Interactive, First CPU Idle und Max Potential First Input Delay (FID).

Tracking-Codes in den Tests: Google Analytics (gtag.js), Facebook Pixel, Reddit Pixel, Quora Pixel, LinkedIn Insights, Twitter Universal Tag, Google Ads Remarketing (gtag.js), Hotjar. Acht weit verbreitete Skripte.

Verglichene Szenarien:

Saubere Seite ohne Drittanbieter-Skripte und ohne GTM
Seite mit 8 Tracking-Codes direkt vor </head> hartcodiert, ohne GTM
Leerer GTM-Container ohne Tags
Alle 8 Tags über GTM, Trigger All Pages (auch bekannt als gtm.js)
Dieselben 8 Tags über GTM, Trigger DOM Ready (gtm.dom)
Dieselben 8 Tags über GTM, Trigger Window Loaded (gtm.load)
Dieselben 8 Tags, Auslösung 1,5 Sekunden nach Window Loaded
GTM-Container mit aktiviertem Vorschau- und Debug-Modus
GTM-Container mit 100 benutzerdefinierten HTML-Tags, die Elemente am Ende des <body> hinzufügen
GTM-Container mit 100 benutzerdefinierten HTML-Tags, die Elemente an einer bestimmten Stelle der Seite hinzufügen (nach H2)
GTM-Container mit 100 benutzerdefinierten HTML-Tags, die alle Links durchsuchen und ein Element nach dem 21. einfügen
GTM-Container mit 1976 konstanten Variablen (bis zur Grenze gefüllt, 200 KB)

Was die Tests gezeigt haben

Asynchron bedeutet nicht „folgenlos"

Asynchrone Skripte blockieren das Rendering nicht direkt. Aber sie benötigen dennoch CPU-Ressourcen, wodurch die Hauptskripte der Seite langsamer ausgeführt werden. In der Praxis: Das Document Complete-Ereignis trat auf einer sauberen Seite nach 4 Sekunden ein. Mit acht Tags nach 7,7 Sekunden. Ein Unterschied von 3,7 Sekunden, nur weil der Prozessor mit Drittanbieter-Skripten beschäftigt ist.

Vergleich der Document-Complete-Zeit ohne Tags und mit Tags

Selbst ein leerer GTM-Container erhöhte die Ladezeit geringfügig, um etwa 100 Millisekunden.

Auswirkung eines leeren GTM-Containers auf die Ladezeit

Es liegt nicht an GTM, sondern an dem, was Sie hineinpacken

Ein leerer GTM-Container verlängert die Seitenladezeit um etwa 100 Millisekunden, manchmal gibt es überhaupt keine Verzögerung. Probleme beginnen, wenn Sie den Container mit Tags füllen. Aber selbst hier ist der Zusammenhang nicht linear.

Acht Tracking-Tags verlangsamten die Seite um etwa 3 Sekunden auf einer schnellen 3G-Verbindung und um 10 Sekunden auf langsamen Verbindungen. Jedes Tag zieht sein eigenes Skript, und der Browser benötigt Zeit für deren Ausführung.

Document Complete ohne Tags und mit 8 Tags in GTM

Ein Container jedoch, der mit 1976 konstanten Variablen (200 KB, das GTM-Limit) gefüllt war, fügte nur 0,1 bis 0,3 Sekunden hinzu. Variablen laden keine externen Skripte und manipulieren nicht das DOM, daher ist ihre Auswirkung minimal.

Fazit: Entscheidend ist nicht die Größe des Containers, sondern welche Aktionen seine Elemente ausführen.

Hartcodierte Tags bremsen stärker als dieselben Tags über GTM

Als wir 8 Tracking-Skripte direkt in den Seitenquellcode einfügten, wurde die Seite noch spürbarer langsamer. Auf schnellem 3G fügten hartcodierte Tags etwa 600 Millisekunden mehr Verzögerung hinzu im Vergleich zu denselben, über GTM gestarteten Tags.

Vergleich von hartcodierten Tags und Tags über GTM

Im zweiten Diagramm dasselbe Bild aus einem anderen Blickwinkel: Hartcodierte Skripte verlieren bei der Document Complete-Zeit durchgängig gegen GTM.

Document Complete hartcodierte Tags versus GTM

GTM hilft tatsächlich, Seiten etwas schneller zu laden, als wenn Skripte direkt in den Code eingefügt werden. Aber das ist keine universelle Regel. Es gibt Szenarien, in denen das Starten von JS ohne GTM effizienter umgesetzt werden kann, und Simo Ahava, einer der führenden GTM-Experten, stimmt dem zu.

Der Zeitpunkt der Tag-Auslösung ist entscheidend

Je später ein Tag ausgelöst wird, desto weniger beeinträchtigt es den initialen Seitenaufbau. Wir haben vier Zeitpunkte getestet:

Page View (gtm.js), sofort beim Laden des Containers
DOM Ready (gtm.dom), wenn das DOM aufgebaut ist
Window Loaded (gtm.load), wenn alle Ressourcen geladen sind
afterLoad, 1,5 Sekunden nach Window Loaded (benutzerdefinierter Trigger)

Code des benutzerdefinierten afterLoad-Triggers:

1 <script>
2   (function() {
3     try {
4       window.setTimeout(function(){
5         dataLayer.push({
6           'event': 'afterLoad'
7         });
8       }, 1500);
9     } catch (err) {}
10   })();
11 </script>

Ergebnis: DOM Ready und Window Loaded brachten eine kleine Verbesserung. Der deutlichste Gewinn kam jedoch durch afterLoad. Bei langsamem 3G reduzierte sich die Verzögerung um 6 Sekunden im Vergleich zum Page View-Trigger. Bei schnellem 3G um 600 Millisekunden.

Vergleich von Fully Loaded bei verschiedenen Tag-Auslösezeitpunkten

Warum funktioniert das? Die Seite kann Elemente enthalten, die erst dynamisch geladen werden, nachdem alle Ressourcen vollständig geladen sind. Wenn Tags das anfängliche Laden verlangsamen, erscheinen auch diese Elemente später. Indem Sie nicht kritische Tags verzögern, lassen Sie den Hauptinhalt ohne Störung laden.

Allerdings gibt es einen Vorbehalt: Wenn Sie Tags verzögern, deren Genauigkeit davon abhängt (Google Analytics), verlassen manche Besucher die Seite möglicherweise, bevor der Zähler ausgelöst wird. Ihren Berichten gehen dann Daten verloren. Die Entscheidung, Tags zu verzögern, sollte im Team getroffen werden, nicht einseitig durch einen Entwickler oder Marketer.

Tracking-Tags sind nicht die einzigen Übeltäter

Eine weitere Gruppe „schwerer" Tags sind solche, die das DOM manipulieren. Zum Beispiel benutzerdefinierte HTML-Tags, die Elemente auf der Seite hinzufügen oder verändern.

Wir haben mehrere Varianten getestet:

100 benutzerdefinierte HTML-Tags, die Elemente am Ende von <body> hinzufügen. Jedes Tag führte ein einfaches console.log('hello')-Skript aus und erzeugte ein <div>Hello!</div>. Ohne Angabe einer bestimmten Einfügeposition. Die Auswirkung auf die Ladegeschwindigkeit der Seite erwies sich als minimal, die Elemente wurden einfach am Ende angehängt.

100 benutzerdefinierte HTML-Tags, die Elemente an einer bestimmten Stelle auf der Seite hinzufügen. Jedes Tag suchte nach dem ersten h2 und fügte danach ein h3 ein. Skript:

1 <script>
2   (function() {
3     var h3 = document.createElement('h3');
4     h3.innerText = "An additional element";
5     var title = document.querySelector('h2');
6     if (title) {
7       title.parentElement.insertBefore(h3, title.nextSibling);
8     }
9   })();
10 </script>

Dies fügte dem Seitenaufbau mehrere hundert Millisekunden hinzu. Obwohl das Skript primitiv ist, erfordert das Suchen nach einem Element und das Einfügen Ressourcen.

Auswirkung von 100 Tags mit DOM-Manipulationen auf Fully Loaded

100 benutzerdefinierte HTML-Tags, die alle Links auf der Seite durchsuchen und nach dem 21. ein Element einfügen. Skript:

1 <script>
2   (function() {
3     var h3 = document.createElement('h3');
4     h3.innerText = "An additional element";
5     var element = document.querySelectorAll('a')[20];
6     if (element) {
7       element.parentElement.insertBefore(h3, element.nextSibling);
8     }
9   })();
10 </script>

Unterschied zum vorherigen Experiment: querySelectorAll iteriert über alle Elemente auf der Seite und prüft jedes einzelne, was aufwändiger ist. In webpagetest.org war der Unterschied gering (100-200 ms), aber Lighthouse zeigte einen Anstieg der Time to Interactive um 2-3 Sekunden. Das bedeutet, dass der Browser während des Seitenaufbaus so sehr mit dem Einfügen von Elementen beschäftigt ist, dass er nicht auf Nutzeraktionen reagiert.

Time to Interactive bei umfangreichen DOM-Manipulationen

Ja, 100 identische Skripte sind übertrieben. Aber der Punkt ist, dass bereits wenige komplexe Tags, die das DOM manipulieren, einen ähnlichen Effekt erzeugen können.

Wie Sie die Auswirkungen des GTM auf die Geschwindigkeit reduzieren: 8 Techniken

Bereinigen Sie den Container regelmäßig von verwaisten Tags

Die Audit-Praxis zeigt: Bis zu einem Drittel der Tracking-Codes auf Websites gehören zu Tools, die das Unternehmen nicht mehr nutzt. Sie sind von Analysetool X auf Z umgestiegen, aber die Codes von X laden weiterhin auf jeder Seite und bremsen sie aus.

Das ist zu tun:

Bitten Sie einen Entwickler um eine Liste aller HTTP-Requests und Skripte auf der Seite
Suchen Sie die Domains dieser Requests, identifizieren Sie, zu welchen Tools sie gehören
Fragen Sie Kollegen aus verschiedenen Abteilungen, welche Tools noch genutzt werden
Finden Sie „verwaiste" Skripte, die nicht auf der Liste der genutzten Tools stehen
Ist ein Skript über GTM eingebunden, pausieren Sie es für einen Monat; beschwert sich niemand, löschen Sie es endgültig
Ist ein Skript fest codiert, bitten Sie den Entwickler, es vorübergehend auszukommentieren, und löschen Sie es nach einem Monat

GTM-Container vor Audit auf verwaiste Tags

Verzögern Sie nicht kritische Tags

Je weniger Tags am All Pages-Trigger hängen, desto schneller der initiale Ladevorgang. Nicht alle Tags lassen sich verzögern, aber wenn Sie diesen Ansatz zumindest bei einigen anwenden, wird die Verbesserung spürbar.

So implementieren Sie die Verzögerung (Methode von Pavel Brechik):

Schritt 1. Erstellen Sie ein benutzerdefiniertes HTML-Tag mit folgendem Code:

1 <script>
2   (function() {
3    try {
4      window.setTimeout(
5       function(){
6        dataLayer.push({'event': 'afterLoad'});
7       }, 1500);
8     } catch (err) {}
9   })();
10 </script>

Schritt 2. Lassen Sie dieses Tag über den Window Loaded-Trigger auslösen.

Einrichten des Window-Loaded-Triggers für benutzerdefinierte HTML-Tags

Schritt 3. Erstellen Sie einen benutzerdefinierten Trigger für das afterLoad-Ereignis.

Erstellen eines benutzerdefinierten afterLoad-Triggers in GTM

Schritt 4. Weisen Sie diesen Trigger den Tags zu, die verzögert werden können.

Ergebnis bei langsamem 3G: Verzögerung um 6 Sekunden reduziert, bei schnellem 3G um 600 Millisekunden.

Fully Loaded bei verschiedenen Tag-Auslösezeitpunkten

Welche Tags verzögert werden können und welche nicht, sollten Sie im Team entscheiden. Entwickler würden idealerweise alles für die Geschwindigkeit entfernen, Marketer alles für die Datenqualität hinzufügen. Die Wahrheit liegt in der Mitte.

Nutzen Sie Tags nur auf den Seiten, die Sie benötigen

Nicht jedes Tag muss auf der gesamten Website feuern. Ein Google Ads Remarketing-Pixel kann ausschließlich auf Kampagnen-Landingpages ausgelöst werden, nicht auf der ganzen Site. LinkedIn Insights nur auf Seiten, auf denen LinkedIn-Traffic ankommt. Richten Sie Ausschlüsse in Triggern ein, das reduziert die Anzahl der Skripte, die auf einer typischen Seite ausgeführt werden.

Einrichten eines Triggers nur für bestimmte Seiten in GTM

Vermeiden Sie aufwendige DOM-Manipulationen

Wenn Sie ein benutzerdefiniertes HTML-Tag benötigen, das der Seite etwas hinzufügt, versuchen Sie, dies so leichtgewichtig wie möglich zu tun. Vermeiden Sie querySelectorAll mit Iteration über alle Elemente. Fügen Sie nicht Dutzende identischer Elemente an verschiedenen Stellen der Seite ein. Jede DOM-Manipulation verbraucht Browser-Ressourcen in einem Moment, in dem dieser bereits mit dem Rendern der Seite beschäftigt ist.

Beispiel für optimierten benutzerdefinierten HTML-Tag in GTM

Messen Sie die Geschwindigkeit nicht bei aktiviertem Vorschaumodus

Der Vorschau- und Debug-Modus im GTM erzeugt eine zusätzliche Last im Browser, die echte Besucher nicht haben. Messen Sie die Geschwindigkeit mit aktivierter Vorschau, fallen die Ergebnisse schlechter aus als die Realität. Schalten Sie vor einem Geschwindigkeits-Audit stets den Debug-Modus aus.

Deaktivieren des GTM-Vorschaumodus für Geschwindigkeitstests

Testen Sie die Geschwindigkeit nach jeder Container-Änderung

Haben Sie ein neues Tag hinzugefügt oder einen Trigger geändert, prüfen Sie sofort die Seitengeschwindigkeit über webpagetest.org oder Lighthouse. Nehmen Sie Messungen vor und nach der Änderung vor. So erwischen Sie ein problematisches Tag sofort, statt sich später zu fragen, warum die Seite plötzlich 2 Sekunden langsamer lädt.

Halten Sie den Container schlank

Löschen Sie ungenutzte Tags, Trigger und Variablen. Dabei geht es weniger um Geschwindigkeit (wie der Test mit 1976 Variablen zeigte), sondern um die Beherrschbarkeit. In einem Container mit hundert Tags verliert man leicht ein problematisches Skript. In einem Container mit zwei Dutzend ist jede Einheit sichtbar.

Aufgeräumter strukturierter GTM-Container

Trennen Sie die Spreu vom Weizen: Was wirklich Ladezeit spart

Ziehen wir ein Fazit aus den Experimenten. Hier ist, was in absteigender Reihenfolge den größten Effekt bringt:

Übersichtstabelle der Auswirkungen verschiedener Faktoren auf die Ladegeschwindigkeit

Nach unseren Messungen bringt die Verzögerung von Tags über afterLoad die deutlichste Verbesserung, bis zu 6 Sekunden auf langsamen Verbindungen. An zweiter Stelle steht das Entfernen verwaister Tracking-Codes. An dritter Stelle die Begrenzung des Tag-Einsatzbereichs auf bestimmte Seiten.

⁉️🤔 Häufig gestellte Fragen

Bremst ein leerer GTM eine Seite aus?

Praktisch nicht. In unseren Tests fügte ein leerer Container dem Seitenaufbau etwa 100 Millisekunden hinzu. Manchmal gab es überhaupt keine Verzögerung. Das liegt im Bereich der Messtoleranz und ist weder für Nutzer noch für Suchmaschinen spürbar.

Was bremst stärker: GTM oder fest codierte Skripte?

Fest codierte Skripte bremsen etwas mehr. In unserem Test verlangsamten 8 direkt im Code eingefügte Tracking-Tags die Seite um etwa 600 Millisekunden mehr als dieselben Tags über GTM. Aber das ist keine allgemeingültige Regel, gut geschriebenes Custom-JS kann effizienter sein als GTM.

Kann man alle Tags verzögern?

Technisch ja. Aber Sie verlieren Daten: Einige Besucher verlassen die Seite, bevor die Zähler feuern. Google Analytics und ähnliche Tools erfassen dann zu wenig Traffic. Verzögern Sie nur Tags, die keine hohe Genauigkeit erfordern, zum Beispiel Chat-Widgets oder Remarketing-Pixel. Analytics belässt man besser auf Page View.

Wie prüft man, welche Tags im GTM wirklich bremsen?

Führen Sie einen Lighthouse-Audit bei geöffnetem Netzwerk-Tab durch. Sehen Sie, welche Skripte am längsten laden und welche das Rendering blockieren. Gleichen Sie die Domains dieser Skripte mit den Tags im Container ab. Oder führen Sie einen A/B-Test durch: Deaktivieren Sie verdächtige Tags vorübergehend einzeln und messen Sie die Geschwindigkeit.

Was ist mit serverseitigem GTM?

Serverseitiges GTM verlagert die Tag-Verarbeitung vom Browser des Nutzers auf Ihren Server. Der Browser erhält nur einen Container statt einem Dutzend Drittanbieter-Skripte. Das reduziert die Last auf der Client-Seite radikal. Wenn Sie Dutzende Tracking-Tags haben, ist serverseitiges GTM eine Überlegung wert. Die Technologie ist seit 2020 verfügbar, und bis 2026 ist ihre Implementierung spürbar einfacher geworden.

Fazit: Beschleunigt oder bremst GTM?

Weder in Reinform. GTM ist ein Dispatcher: Für sich genommen ist es nahezu gewichtslos, und die Seitengeschwindigkeit wird davon bestimmt, welche Tags und in welcher Menge Sie darüber ausspielen.

Acht Standard-Tracking-Tags über GTM verlängern den Seitenaufbau um 3 bis 10 Sekunden. Dieselben Tags hart codiert bremsen jedoch noch stärker. Ein verzögerter Start per afterLoad gewinnt bis zu 6 Sekunden zurück. Das Entfernen verwaister Tags bringt weitere Sekunden. In Summe kann GTM bei kluger Konfiguration hart codierte Skripte übertreffen, und ohne Konfiguration gegen eine leere Seite vollständig verlieren.

Die Hauptregel ist einfach: Nicht GTM macht die Seite, sondern Sie selbst. Auditieren Sie den Container, entfernen Sie Ballast, verzögern Sie nicht kritische Tags, richten Sie Seitenausschlüsse ein, und die Geschwindigkeit Ihrer Seite wird es Ihnen danken.

1	<script>
2	(function() {
3	try {
4	window.setTimeout(function(){
5	dataLayer.push({
6	'event': 'afterLoad'
7	});
8	}, 1500);
9	} catch (err) {}
10	})();
11	</script>

1	<script>
2	(function() {
3	var h3 = document.createElement('h3');
4	h3.innerText = "An additional element";
5	var title = document.querySelector('h2');
6	if (title) {
7	title.parentElement.insertBefore(h3, title.nextSibling);
8	}
9	})();
10	</script>

Alles für WordPress, Webentwicklung — und mehr

🚀 Google Tag Manager und Website-Geschwindigkeit: was die Tests sagen