Google-Seitengeschwindigkeit und SEO verbessern mit verzögerten Tag-Manager-Triggern

In diesem Beitrag nutzen wir ein paar Tools. Ich liste sie hier alle auf, und du kannst dir die Links holen, sobald du sie brauchst. Als Webflow-Profi verwendest du die meisten davon wahrscheinlich jeden Tag, aber du brauchst:

• Google PageSpeed Insights
• Google Lighthouse (hier gibt es keinen Link: Öffne Chrome, wähle Ansicht, Entwickler und dann Entwicklertools, und dort brauchst du den Tab Lighthouse. Es ist im Grunde dasselbe wie PageSpeed, liefert aber noch ein paar weitere nützliche Erkenntnisse. Mehr Infos hier.)
• Pingdom
• GTmetrix
• ThinkWithGoogle
• Experte.com Update: Janis von experte.com hat den Beitrag gelesen und uns auf ein tolles kostenloses Tool aufmerksam gemacht, mit dem du deine gesamte Website crawlen und für jede Seite einen Geschwindigkeitstest im Bulk durchführen kannst. Wirklich gut, und es spart dir jede Menge Zeit, wenn du viele Seiten prüfen musst. Du kannst damit auch eine bestimmte Liste von URLs testen und zu den offiziellen PageSpeed-Ergebnissen weiterklicken, falls du Empfehlungen und Details sehen möchtest.

Alle diese Tools machen ziemlich ähnliche Dinge und messen deine Seitengeschwindigkeit, aber es lohnt sich, die Ergebnisse verschiedener Tools zu vergleichen.

Vorab ein Hinweis: Du brauchst dieses Tutorial nicht, wenn du keine Probleme hast und nicht wie wir eine Menge Werbe-Tracking-Tags im Tag Manager laufen hast. Wir setzen diese Methode bei unseren Webflow Projekten häufig ein, um Tags zu verzögern und die Website schneller zu machen, denn in Webflow hast du beim Einbinden von Code und der Entscheidung, wann er ausgelöst wird, nicht besonders viel Kontrolle. Das heißt aber nicht, dass du die Methode nicht auch auf jeder anderen Website nutzen solltest, auf der viele Tags bei Seitenaufrufen feuern oder einfach direkt im Code eingebettet sind. Beginnen wir also mit der Frage, warum du das beim Google Tag Manager und bei Conversion-Tracking, Remarketing-Tags und Ähnlichem von Werbenetzwerken wie Facebook (Meta), Google Ads, LinkedIn, Twitter (heute X), Pinterest und anderen brauchst, ebenso bei Tools wie Heatmaps von Hotjar oder Microsoft Clarity. (Nebenbei: Wenn du noch keine Scroll-, Heat- und Klick-Maps hast und sie gern hättest, installiere einfach Microsoft Clarity. Es ist ein tolles kostenloses Heatmap-Tool. Dazu haben wir einen eigenen How-to-Beitrag verfasst.)

Noch etwas: Wenn du Code von Plattformen wie Facebook, Google Ads und so weiter in deiner Website verwendest und dafür nicht den Google Tag Manager nutzt, solltest du ernsthaft darüber nachdenken, ihn herauszunehmen und den Code stattdessen über den Tag Manager einzubinden. Wir sind ein kleines Webflow-Studio, und als Webflow-Designer wollen wir es immer ordentlich, aufgeräumt und einfach, und genau das bietet der Tag Manager. Die Grundlagen zur Installation des Tag Managers, zum Einbinden von Google Analytics über den Tag Manager und zum Einrichten einfacher Conversions findest du in den verlinkten Beiträgen, und unser Überblick darüber, warum du den Google Tag Manager in Webflow nutzen solltest, erklärt das große Ganze. Mit dem Tag Manager lassen sich Tracking-Codes ganz einfach in deine Website einbauen und bequem verwalten. In späteren Beiträgen zeigen wir noch mehr Anleitungen zu weiterem Werbe-Tracking und weiteren Conversions. Wenn du dir etwas Bestimmtes wünschst, schreib es in die Kommentare.

Warum machen wir also diese Anleitung und die folgenden Schritte, um alles zu beschleunigen? Okay, öffne die Links in der Liste, gib die Seiten ein, die du scannen willst, und führe die Geschwindigkeitstests durch. Teste am besten im Inkognito-Modus von Chrome, damit deine Erweiterungen Dinge wie Lighthouse nicht beeinflussen. Wenn du eine ganze Reihe von Tracking-Codes hast, siehst du vielleicht Warnungen zu LCP, INP, CLS (oder FID in älteren Berichten) und so weiter, dazu Vorschläge, einigen Code aufzuschieben, um alles zu beschleunigen. Lass diese Tabs nach den Tests geöffnet. Wir kommen später darauf zurück und schauen, ob sich etwas verbessert hat, ob es weniger Gemecker übers Aufschieben gibt und ob sich deine Werte verbessert haben, wenn wir die Tests am Ende erneut laufen lassen.

Zuerst: Was ist LCP? Die Abkürzung steht für Largest Contentful Paint. Fertig. Mist, nicht wirklich, ich meine, was zum Teufel ist das? Im Grunde geht es darum, wann du sehen kannst, was auf deiner Seite ist, also wann alles aufgehört hat zu laden und im sichtbaren Bereich erscheint. Etwas genauer: Es ist die Zeit, die das größte sichtbare Element beim Öffnen der Seite braucht, meist ein Hero-Bild oder ein großer Textblock, bis es auf dem Bildschirm erscheint. Google möchte, dass das in unter 2,5 Sekunden passiert.

Kurz zu den anderen Abkürzungen: FID (First Input Delay) war früher der Core Web Vital dafür, wie schnell eine Seite auf einen Klick oder Tap reagiert, doch am 12. März 2024 hat Google ihn durch INP (Interaction to Next Paint) ersetzt. Zeigen die Tools, die du verwendest, noch FID an, arbeiten sie mit älteren Daten. So oder so schaden aufwendige Tracking-Skripte beiden Werten, weil der Browser mit deren Ausführung beschäftigt ist, statt auf deine Besucher zu reagieren.

Normalerweise soll LCP schnell sein (eigentlich soll alles schnell sein), aber warum sollten Tracking-Codes das ausbremsen? Das hängt damit zusammen, wie diese Code-Schnipsel laden. Grundsätzlich gibt es zwei Wege: synchron und asynchron. Beim ersten lädt eins nach dem anderen, und alles muss warten, bis das Vorherige geladen ist, bevor es selbst anfängt. Das ist also wahrscheinlich nicht ideal, oder? Dein Headerbild und dein Text sollen nicht erst auf irgendein Tracking-Skript warten müssen, nur weil es im Head deiner Seite steht. Hier kommt asynchron ins Spiel. Dabei lädt alles parallel, sodass nichts auf etwas anderes wartet. Das Problem: Zwar kann nun alles laden, wann es will, aber es steigt die benötigte Bandbreite, weil viele Dinge gleichzeitig geladen werden, und es steigt auch die Last für den Browser des Nutzers, weil er viele Dinge gleichzeitig rendert und verarbeitet.

Der Tag Manager ist zwar großartig, lädt aber asynchron, sodass die Elemente deiner Seite und alle hinzugefügten Tags gleichzeitig laden und um Ressourcen konkurrieren, was nicht so toll ist. Aber wie lösen wir das, ohne einfach alle Tags rauszuwerfen? Wir verzögern, was nicht sofort geladen werden muss, und genau das machen wir jetzt. Was wichtig ist, lassen wir mit dem guten alten All-Pages-Trigger sofort feuern, und den Rest, der dir wichtig ist, den du aber nicht sofort brauchst, etwas später, damit der andere wichtige Teil der Seite zuerst laden kann. Dafür legen wir einen Trigger an, ergänzen benutzerdefinierten Code in einem Tag und erstellen einen weiteren benutzerdefinierten Trigger, der die Tags auslöst, die nicht als Erstes laden müssen.

Dann legen wir los:

Schritt 1: Entscheide, was am wichtigsten ist und was nicht

Das ist wohl die Kopfnuss. Wir schauen normalerweise in den Tag Manager und sehen nach, was dort liegt, was wirklich zuerst laden muss und was wir "verzögern" können. Unsere Google-Analytics-4-Tags laden wir meist weiterhin zuerst, über einen normalen All-Pages-Trigger. Dinge wie Facebook-Tags und Google-Ads-Remarketing-Tags sind wichtig, aber eine zusätzliche Sekunde oder zwei ruinieren niemanden, und wenn du davon eine ganze Menge hast, sind es meist genau die Dinge, über die sich diese Tools beschweren, vor allem Google PageSpeed Insights und Lighthouse.

Schritt 2: Den Full-Loaded-Tag erstellen

Jetzt erstellen wir einen Tag mit benutzerdefiniertem Code und einen Trigger, die ein Event erzeugen. Das gibt der Seite Zeit zu laden, bevor die Tags feuern, die laut Schritt 1 warten können.

Öffne den Tag Manager, gehe zu Tags und klicke auf Neu.

Gib dem Tag einen Namen, wähle Custom HTML als Tag-Typ und füge den Code ein. Der Code liegt in unserem CodePen, also öffne den Delayed-Triggers-Pen auf CodePen (von Jakes van Eeden), kopiere den Code aus dem JS-Tab und füge ihn in den Tag ein.

Falls du es lieber ausgeschrieben siehst: Er macht nur Folgendes. Er wartet 1,5 Sekunden und schickt dann ein Event namens afterLoad an den dataLayer.

<script>
  (function() {
    try {
      // Wait for 1.5 seconds and push an event to the data layer
      window.setTimeout(
        function() {
          dataLayer.push({'event': 'afterLoad'});
        },
        1500
      );
    } catch (err) {}
  })();
</script>

Wenn dieser Tag feuert, läuft der eingefügte benutzerdefinierte Code und erzeugt im dataLayer der Seite ein Event, das 1,5 Sekunden wartet. Du kannst den Wert erhöhen, wenn du willst, aber 1,5 sollten reichen, und dieser Tag löst erst aus, wenn das Window-Loaded-Trigger-Event feuert.

Wähle nun den Trigger aus. Hier solltest du einen neuen Trigger erstellen, statt den üblichen All-Pages-Trigger zu verwenden, denn wir wollen der Seite zuerst Zeit zum Laden geben. Wähle also Page View als Typ und dann Window Loaded. Gib deinem Trigger einen Namen und speichere alles.

Jetzt hast du einen Tag, der beim Feuern ein dataLayer-Event erzeugt und nur beim Window-Loaded-Event auslöst.

Schritt 3: Den Custom-Event-Trigger erstellen, den du bei allen zu verzögernden Tags verwendest

Gehe zu Triggers und klicke auf Neu.

Gib dem Trigger einen Namen, wähle Custom Event als Trigger-Typ und afterLoad als Event-Namen. Bei afterLoad kommt es auf die Groß- und Kleinschreibung an. Speichern, und du bist fertig.

Diesen Custom-Event-Trigger kannst du jetzt als ausgewählten Trigger für alle Tags verwenden, die etwas verzögert werden sollen.

Aber was passiert da eigentlich? Fassen wir zusammen.

Anders als bei den meisten All-Pages-Triggern wartet der Tag, den du am Anfang erstellt hast, jetzt darauf, dass der Window-Loaded-Trigger feuert. Sobald das passiert, wartet er 1,5 Sekunden, bevor er ein Event namens afterLoad an den dataLayer schickt. Dann feuert dein Fully-Loaded-Trigger und löst alle Tags aus, denen du ihn hinzugefügt hast. So bekommt alles andere Zeit zu laden, und viele der Skripte, über die sich Google PageSpeed gewöhnlich beschwert, werden zurückgehalten. Das hilft nicht nur deinen Werten, sondern sorgt auch für eine bessere Nutzererfahrung und weniger Abzüge bei Tools, die so etwas überwachen.

Du musst nicht unserem Weg folgen und deinen GA-Tag auf All Pages feuern lassen. Auch der lässt sich verzögern, es hängt nur davon ab, wie genau deine Analytics sein sollen, und es liegt ganz bei dir. Überhaupt kannst du jeden Tag, den du nicht sofort brauchst, über das Custom Event feuern lassen, wenn du mit der Verzögerung leben kannst.

Zum Schluss: Veröffentliche den Container, prüfe in der Vorschau des Tag Managers, ob noch alles feuert, und wechsle dann zu den Tabs, die du nach den ersten Tests offen gelassen hast. Führe die Tests erneut durch. Jetzt sollte es eine kleine Verbesserung geben, je nachdem, wie viele Tags du verzögert hast. Mach das aber nicht nur wegen eines besseren Werts. Es ist auch gut für deine Nutzererfahrung, und denk an www.experte.com für Bulk-Tests.

Häufige Fragen zum Verzögern von Tags im Google Tag Manager

Verlangsamt der Google Tag Manager meine Website?

Das kann passieren. Der Tag Manager selbst lädt asynchron und blockiert die Seite deshalb nicht, aber jeder Tag darin ist trotzdem ein Skript, das mit deinen Bildern, Texten und allem anderen um Bandbreite und die Aufmerksamkeit des Browsers konkurriert. Ein Container voller Werbe- und Heatmap-Tags ist es, der Google PageSpeed Insights meckern lässt. Die nicht wesentlichen Tags wie oben beschrieben zu verzögern, ist die Lösung.

Wie verzögere ich einen Tag im Google Tag Manager?

Erstelle einen Custom-HTML-Tag, der nach dem Window-Loaded-Trigger ein afterLoad-Event an den dataLayer schickt (Schritt 2), erstelle einen Custom-Event-Trigger namens afterLoad (Schritt 3) und setze diesen Trigger bei jedem Tag ein, den du zurückhalten willst. Prüfe den Container in der Vorschau und veröffentliche ihn dann.

Schadet das Verzögern von Tags meinen Analytics?

Nur ein wenig, und nur bei den Tags, die du verzögerst. Wer die Seite verlässt, bevor das Fenster geladen ist und die 1,5 Sekunden vergangen sind, löst die verzögerten Tags nicht aus. Deshalb lassen wir Google Analytics 4 auf dem normalen All-Pages-Trigger und verzögern Dinge wie Remarketing-Tags, bei denen eine Sekunde oder zwei kaum einen Unterschied machen.

Behebt das meinen Google-PageSpeed-Wert?

Es sollte helfen, besonders wenn PageSpeed Skripte von Drittanbietern bemängelt, aber erwarte eine kleine Verbesserung und kein Wunder. Teste sowohl auf Mobile als auch auf Desktop, mehr als einmal, und sieh den Wert als Orientierung. Der eigentliche Gewinn sind schnellere Seiten.

Hast du Fragen oder Anmerkungen dazu, wie du die Seitengeschwindigkeit verbessern kannst? Schreib uns in die Kommentare, und denk daran: Führe die Tests, besonders in Lighthouse, sowohl auf Mobile als auch auf Desktop mehr als einmal durch, um zu sehen, ob es einen Unterschied gibt.

Schau dir auch den How-To-Bereich unseres Blogs für weitere Tutorials an. Wenn du beim Tracking lieber ganz ohne Tag Manager auskommen möchtest, haben wir außerdem darüber geschrieben, wie du Google Analytics 4 mit Cloudflare Zaraz einbindest, und wenn du Klicks tracken willst, sobald deine Tags laufen, zeigen wir hier, wie du Button-Klicks in Google Analytics mit dem Tag Manager trackst. Außerdem haben wir kürzlich einen Beitrag dazu veröffentlicht, wie du deine Website schneller machst, indem du Webflow mit Cloudflare nutzt, um dein Webflow-Projekt zu cachen und zu beschleunigen, und die neueste Fassung dieser Tipps findest du im Beitrag zur Optimierung von Webflow mit Cloudflare für Bilder, Assets und Caching im Jahr 2026. Schau dir diese Beiträge unbedingt an.