24. Sep. 2025
Verfasst von
Ira Holubovska
Die Optimierung der Website-Ladegeschwindigkeit war einer der zentralen Vorteile, die Marketingexperten und Webentwickler sahen, als die erste Version des serverseitigen Google Tag Manager veröffentlicht wurde. Dies sollte gelingen, da Tracking-Skripte nicht mehr fest im Code hinterlegt, sondern über den Google Tag Manager eingebunden würden.
In diesem Artikel zeigen wir Ihnen, wie sich das Verschieben von Tags aus dem GTM-Web-Container in einen Server-Container auf Ihren GTM-PageSpeed auswirkt, wie die Daten tatsächlich aussehen und welcher Ansatz je nach Ihrem Setup sinnvoller ist.
Hinweis:
Sie werden keine PageSpeed-Verbesserungen feststellen, wenn Sie Browser- und Server-Tracking parallel ausführen. Wenn Sie beispielsweise sowohl das Facebook-Pixel als auch die Conversions API gleichzeitig nutzen, wird das Pixel weiterhin im Browser der nutzenden Person geladen und verlangsamt Ihre Website. Ein solches unvollständiges Setup ist einer der häufigsten Gründe dafür, dass der GTM eine Website ausbremst, selbst wenn Teams glauben, die Migration bereits abgeschlossen zu haben.
Bereits 2016 stellte Google fest, dass die ideale Ladezeit einer Website bei 3 Sekunden liegt. Gleichzeitig dauert es im Durchschnitt 22 Sekunden, bis eine mobile Seite vollständig geladen ist.
Wir leben in einer Zeit, in der Smartphones häufiger als Desktop-Geräte genutzt werden und auf Smartphones mehr als 50 % des gesamten Internet-Traffics entfallen. Laut Google sind die Conversion-Raten auf Smartphones jedoch niedriger als auf Desktop-Geräten. Deshalb spielt die Ladezeit der Website eine entscheidende Rolle, um Performance-Standards zu erfüllen.
Es ist kein Geheimnis, dass Nutzende eine schnelle Website erwarten. Wenn die Landingpage zu langsam ist, schließen sie die Seite, brechen den Warenkorb ab und wechseln zur Konkurrenz. In der heutigen Mobile-First-Welt ist die Erstellung schnell ladender Websites erfolgskritisch. Nutzende möchten jeden Blog sofort öffnen und Artikel lesen, neue Kleidung kaufen, Hotelbewertungen prüfen und vieles mehr.
Untersuchungen von Amazon zufolge führt eine Verzögerung der Seitenantwort um nur 1 Sekunde zu einem Conversion-Verlust von 1 %. Das entspricht für das Unternehmen einem jährlichen Umsatzverlust von 1,6 Milliarden US-Dollar.
Wie Sie sehen, kann das Warten auf das Laden überladener Seiten jedes Unternehmen teuer zu stehen kommen.
Jedes Tag, das Sie über den Google Tag Manager hinzufügen, wird als JavaScript im Browser der nutzenden Person ausgeführt. Jedes Skript muss vor oder nach dem Laden der Seite heruntergeladen, geparst und ausgeführt werden – und das kostet Zeit.
Nicht jedes GTM-Setup verhält sich gleich, und genau hier entsteht die meiste Verwirrung. Wie der Container implementiert ist – Web oder Server –, entscheidet darüber, ob der GTM den Browser zusätzlich belastet oder entlastet. Im Web-Container ist jedes hinzugefügte Tag (Analytics, Werbepixel, Chat-Widgets, Heatmaps) ein Skript, das direkt im Browser des Website-Besuchers geladen und ausgeführt wird.
Jedes einzelne Tag konkurriert um dieselben begrenzten Ressourcen: den Hauptthread (Main Thread), die Bandbreite und die Rendering-Zeit. Je mehr Tags Sie anhäufen, desto stärker summiert sich der Performance-Einfluss des Google Tag Manager, auch wenn der GTM selbst ein leichtgewichtiger Container ist.
Serverseitiger GTM verändert den Ort, an dem die Tags ausgeführt werden. Anstatt dutzende Drittanbieter-Skripte clientseitig auszuführen, empfängt Ihr Server-Container die Daten und leitet sie aus der Cloud an Ihre Marketing- und Analytics-Plattformen weiter. Der Browser muss nur noch mit Ihrem eigenen Server kommunizieren und nicht mehr mit dutzenden verschiedenen Drittanbieter-Domains. Das ist der Hauptgrund, warum der PageSpeed-Unterschied beim Google Tag Manager zwischen Web- und Server-Setups meist so groß ist.
2020 veröffentlichte Google einen Server-Container für den Google Tag Manager und Tag Manager 360. Er ermöglicht es Werbetreibenden, Drittanbieter-Tags von ihren Websites in einen neuen Server-Container zu verschieben, der auf Cloud-Servern gehostet wird. Dadurch lädt die Website schneller, das Tracking wird präziser und die Daten sind sicherer. Das Verschieben von Tags in den Server-Container kann helfen, diesen Google-PageSpeed-Fehler zu beheben: „Auswirkungen von Drittanbieter-Code reduzieren – Drittanbieter-Code hat den Hauptthread für 550 ms blockiert“.

Wenn Sie Tags aus dem Web- in den Server-Container verschieben, werden sie direkt im Server-Container und nicht mehr im Browser geladen. Auf diese Weise lädt die Seite schneller, was sich positiv auf die Nutzererfahrung auswirkt. Wie Sie sehen, sorgt dies für schnellere Ladezeiten, mehr Sicherheit für Ihre Kundendaten und umfassendere Tools zur Datenverwaltung. Dies ist eines der deutlichsten Beispiele dafür, wie der serverseitige Google Tag Manager die Website-Performance verbessern kann, ohne die Tracking-Genauigkeit zu beeinträchtigen.
Tags im Server-Container haben nur Zugriff auf Informationen, die an den Server gesendet werden. Sie können nicht auf andere Daten zugreifen, die Nutzende auf der Website eingeben. Und da diese Tags in Ihrem Server-Container platziert sind, können Sie genau nachvollziehen, welche Tags Daten erfassen und wohin diese Informationen gesendet werden.
Nicht alle Tags wirken sich gleichermaßen auf den PageSpeed aus – eine wichtige Nuance, die man bedenken sollte, bevor man davon ausgeht, dass eine Migration jedes Performance-Problem löst. Ein schlankes Analytics-Snippet und ein ressourcenintensives Retargeting-Pixel belasten die Ladezeit nicht im selben Maße, obwohl beides „nur ein Tag“ ist. Die Tags mit dem größten Einfluss sind in der Regel diejenigen, die mehrere Netzwerkanfragen auslösen, zusätzliche Skripte nachladen oder bei jedem Seitenaufruf statt bei bestimmten Events ausgeführt werden.
Der verlässlichste Weg, dies selbst zu überprüfen, besteht darin, Ihren PageSpeed-Insights-Bericht vor und nach der Migration zu prüfen und den Abschnitt für Drittanbieter-Code in den Ergebnissen direkt zu vergleichen.
Für dieses Experiment habe ich eine Demo-Website verwendet und die Google-PageSpeed-Ergebnisse verglichen, wenn Tags über den GTM-Web-Container im Vergleich zum GTM-Server-Container hinzugefügt wurden. Nicht alle Tags haben den gleichen Einfluss auf den Google-PageSpeed. Für dieses Experiment habe ich die beliebtesten Tags ausgewählt, die von meinen Kunden genutzt werden und sich in den Server-Container verschieben lassen: Facebook, Bing und Active Campaign.
Der GTM-Server-Container bietet native Tags für GA4. Hier finden Sie detaillierte Informationen dazu, wie Sie GA4-Tracking mit dem serverseitigen GTM-Container einrichten. Außerdem haben wir eine benutzerdefinierte Vorlage erstellt, die Ihnen dabei hilft, das Facebook-Pixel in die Server-Umgebung zu verschieben.
Unten sehen Sie die Ergebnisse des Google-Speed-Tests. Der Google-PageSpeed lag bei 95 Punkten auf Mobilgeräten und 100 Punkten auf Desktop-Geräten.

Wir haben diese Tags im Server-Container installiert: GA4, Facebook (Basis- und Conversion-Tracking), Hubspot- und Klaviyo-Tag.
Als wir das Pixel in den Web-Container verschoben haben, sanken die Google PageSpeed-Ergebnisse auf 56 Punkte.


Wenn Sie Tags in den Server-Container des Google Tag Manager verschieben, wird Ihre Website schneller. Das Ausmaß der Auswirkungen hängt von den von Ihnen verwendeten Tags ab. In diesem Test zeigten die bei Kunden beliebtesten Tags (GA4, Facebook und Active Campaign ) einen deutlichen, messbaren Unterschied, sobald sie serverseitig verlagert wurden.
Möchten Sie serverseitig starten?
Kostenlos testen24. Sep. 2025
Blog
Erfahren Sie, wie Sie dataLayer-Variablen, benutzerdefinierte Parameter oder andere Daten vom Web zum Server-Container mit Data Tag senden.
21. Sep. 2026
Kommentare