Warum verlangsamt der Google Tag Manager meine Website?

Meist verlangsamt nicht der Google Tag Manager selbst Ihre Website, sondern die Tags, die er auslöst. Das Standard-Snippet lädt gtm.js asynchron und blockiert den Seitenaufbau nicht; Zeit kosten benutzerdefinierte HTML-Tags, ein zweites Google-Tag aus einem Plugin und alles, was im Moment der Cookie-Zustimmung startet.

Messen Sie deshalb, bevor Sie Tags löschen. In unseren Kundenkonten war GTM häufiger die Ursache für träge Reaktionen auf Klicks (INP) als für langsames Laden (LCP), und einmal wurde er für ein Serverproblem verantwortlich gemacht. Werden bei Ihnen zusätzlich Seitenaufrufe doppelt gezählt, lesen Sie, warum GTM Seitenaufrufe in Google Analytics verdoppelt.

Wie prüfen Sie, ob der Google Tag Manager Ihre Website verlangsamt?

1. Öffnen Sie PageSpeed Insights, geben Sie die URL ein und wählen Sie Mobil. Der obere Block zeigt Felddaten echter Chrome-Nutzer aus 28 Tagen. Notieren Sie LCP und INP: gut sind bis 2,5 Sekunden und bis 200 Millisekunden.
2. Öffnen Sie weiter unten bei den Labordaten die Diagnosen zu ungenutztem JavaScript und Drittanbieter-Code. Dort steht googletagmanager.com mit Übertragungsgröße und Hauptthread-Zeit.
3. Öffnen Sie in Chrome die Entwicklertools → Leistung (Performance), zeichnen Sie einen Seitenaufruf auf und danach einen Klick auf „Akzeptieren“ im Cookie-Banner. Lange Aufgaben (rote Ecke), die von gtm.js oder den geladenen Tags stammen, verschlechtern den INP.
4. Vergleichen Sie die Zeitpunkte. Starten die GTM-Aufgaben erst, nachdem das größte Element gezeichnet ist, liegt Ihr LCP-Problem nicht am Tag Manager.

Was macht den Tag Manager in der Praxis langsam?

• Benutzerdefinierte HTML-Tags. Googles Leitfaden zu Tags und Tag-Managern nennt Bild-Pixel als schnellste Tag-Art, danach benutzerdefinierte Vorlagen, zuletzt benutzerdefiniertes HTML. Ein HTML-Tag mit einer kompletten Anbieter-Bibliothek kann der Browser nicht getrennt zwischenspeichern.
• Alles feuert beim Seitenaufruf. Heatmaps, Chat-Widgets oder Remarketing braucht der erste Bildaufbau nicht. Derselbe Leitfaden empfiehlt, nicht notwendige Tags erst nach Fenster geladen auszulösen.
• Zwei Google-Tags. Ein WordPress-Plugin wie Site Kit oder ein Cookie-Plugin mit eigenem Analytics-Dienst lädt gtag.js zusätzlich zu GTM. Das kostet Hauptthread-Zeit und verdoppelt Daten.
• Zeitpunkt der Einwilligung. Im einfachen Consent Mode bleiben Google-Tags blockiert, bis der Besucher im Banner entscheidet. Der Klick auf „Akzeptieren“ muss dann den ganzen Container laden und ausführen – genau die Interaktion, die INP misst.
• Blockiert statt entfernt. Ein pausiertes oder gelöschtes Tag fehlt im Container. Ein Tag mit Blockierungstrigger wird weiter mitgeladen.

Liegt es in der Praxis am Tag Manager oder am Server?

Ein Kunde aus dem Handel hatte im Mai 2026 einen mobilen INP von 278 ms. Labormessungen zeigten das Muster: Erstbesucher kamen beim Tippen auf „Akzeptieren“ auf 300 bis 368 ms, wiederkehrende Besucher auf 72 ms. Das Cookie-Banner hielt GTM bis zur Zustimmung zurück, und ein WordPress-Plugin lud das Google-Tag ein zweites Mal. Wir haben die Dublette entfernt und starten GTM etwa 800 ms nach dem Laden, sobald der Browser untätig ist. In denselben Wochen wurde auch der Server-Cache verbessert, nicht jede Millisekunde geht also auf GTM zurück. In den Felddaten sank der INP von 229 ms (Mitte Juni) auf 137 ms (Ende Juli) und liegt seitdem unter 155 ms.

Ein B2B-Kunde hatte GTM im Verdacht, weil PageSpeed ihn unter ungenutztem JavaScript aufführte. Der mobile LCP lag im August bei 4,1 Sekunden. Die Aufzeichnung zeigte die langen GTM-Aufgaben bei 3,7, 7,4 und 9,3 Sekunden, also alle nach dem Zeichnen des Hauptinhalts; der INP war bereits gut. Die eigentliche Ursache war der Server: Allein das erste Byte brauchte 4,2 Sekunden, weil der Seiten-Cache nicht mehr arbeitete. Nach der Reparatur des Caches sank der mobile LCP auf 1,6 Sekunden. Den Container haben wir nicht angefasst.

Sollte ich den Tag Manager verzögert laden?

Nur nach einer Messung und nur mit einer Verzögerung auf Basis von Leerlaufzeit. Wer GTM erst beim ersten Scrollen oder Klicken lädt, verschiebt die Arbeit genau in die Interaktion, die INP misst. Eine kurze Verzögerung nach dem Load-Event (wir nutzen requestIdleCallback) hält den ersten Bildaufbau frei. Der Preis: Besucher, die in dieser Sekunde wieder gehen, werden nicht erfasst, und der Consent-Standard muss trotzdem vor jedem Google-Tag gesetzt sein.

Beheben Sie die Ursache, die die Felddaten zeigen. Leidet der INP beim Akzeptieren der Cookies, entfernen Sie doppelte Google-Tags und laden Sie GTM danach entweder im Leerlauf oder stellen Sie auf den erweiterten Consent Mode um, der die Tags mit abgelehnter Einwilligung lädt (eine rechtliche Entscheidung des Seitenbetreibers). Ist der LCP schlecht, prüfen Sie zuerst die Server-Antwortzeit.

Welche schnellen Prüfungen im Container helfen?

1. Öffnen Sie Tags und sortieren Sie nach Typ. Prüfen Sie bei jedem benutzerdefinierten HTML-Tag, ob ein integrierter Tag-Typ oder eine Vorlage aus Vorlagen → Galerie durchsuchen dasselbe leistet.
2. Pausieren oder löschen Sie Tags, die niemand mehr nutzt (Tag öffnen → Drei-Punkte-Menü → Pausieren), und entfernen Sie danach Trigger und Variablen ohne Tag.
3. Verschieben Sie nicht notwendige Tags auf einen Trigger Fenster geladen (Trigger → Neu → Triggerkonfiguration → Fenster geladen).
4. Starten Sie die Vorschau und prüfen Sie im Tag Assistant, dass GA4 pro Seite genau einen page_view sendet.
5. Veröffentlichen Sie mit Senden und testen Sie die Live-Seite erneut. Die Vorschau ändert nicht, was Ihre Besucher laden.

Quellen

• web.dev: Best Practices für Tags und Tag-Manager
• web.dev: Interaction to Next Paint (INP)
• Google for Developers: Einwilligungsmodus (Consent Mode)

Sie möchten wissen, welche Ihrer Tags Zeit kosten? Wir prüfen Ihren GTM-Container anhand Ihrer Felddaten und beheben, was wir finden. Buchen Sie ein kostenloses Erstgespräch oder lesen Sie, wie wir Google Ads und Conversion-Tracking für unsere Kunden betreuen.