Best Practices für Tags und Tag-Manager

Tags und Tag-Manager für Core Web Vitals optimieren

Tags sind Snippets von Drittanbietercode, die in eine Website eingefügt werden, in der Regel mit einem Tag-Manager. Tags werden am häufigsten für Marketing und Analyse verwendet.

Die Auswirkungen von Tags und Tag-Managern auf die Leistung variieren von Website zu Website stark. Tag Manager lassen sich mit einem Umschlag vergleichen: Der Tag Manager stellt einen Behälter zur Verfügung, aber was Sie ihn füllen und wie Sie ihn verwenden, bleibt Ihnen überlassen.

In diesem Artikel werden Techniken zur Optimierung von Tags und Tag-Managern im Hinblick auf Leistung und Web Vitals beschrieben. Dieser Artikel bezieht sich zwar auf Google Tag Manager, viele der besprochenen Ideen gelten aber auch für andere Tag-Manager.

Auswirkungen auf Core Web Vitals

Tag Manager können Ihre Core Web Vitals häufig indirekt beeinflussen, indem sie Ressourcen verbrauchen, die erforderlich sind, um Ihre Seite schnell zu laden und dafür zu sorgen, dass sie responsiv bleibt. Die Bandbreite kann dazu verwendet werden, das Tag Manager-JavaScript für Ihre Websites herunterzuladen oder für die nachfolgenden Aufrufe zu verwenden. Die CPU-Zeit im Hauptthread kann aufgewendet werden, um den JavaScript-Code im Tag Manager und in den Tags auszuwerten und auszuführen.

Beim Largest Contentful Paint (LCP) kommt es während der kritischen Seitenladezeit zu Bandbreitenkonflikten. Außerdem kann sich durch das Blockieren des Hauptthreads die LCP-Renderingzeit verzögern.

Cumulative Layout Shift (CLS) kann dadurch beeinträchtigt werden, entweder durch verzögertes Laden kritischer Ressourcen vor dem ersten Rendering oder durch Tag-Manager, die Inhalte in die Seite einfügen.

First Input Delay (FID) ist anfällig für CPU-Konflikte im Hauptthread. Dies kann sich auch auf den neueren Messwert Interaction to Next Paint (INP) auswirken und wir haben einen Zusammenhang zwischen der Größe der Tag-Manager und schlechteren INP-Werten festgestellt.

Tag-Typen

Die Auswirkungen von Tags auf die Leistung variieren je nach Tag-Typ. Im Allgemeinen sind Bild-Tags („Pixel“) am leistungsstärksten, gefolgt von benutzerdefinierten Vorlagen und zuletzt benutzerdefinierten HTML-Tags. Anbieter-Tags variieren je nach erlaubter Funktionalität.

Beachten Sie jedoch, dass die Verwendung eines Tags großen Einfluss auf seine Leistung hat. „Pixel“ sind vor allem deshalb sehr leistungsfähig, weil die Art dieses Tag-Typs strenge Einschränkungen für ihre Verwendung vorschreibt. Benutzerdefinierte HTML-Tags sind zwar nicht unbedingt schlecht für die Leistung, aber aufgrund der Freiheit, die sie den Nutzern bieten, können sie leicht missbraucht werden, was sich negativ auf die Leistung auswirkt.

Denken Sie bei Tags an die Skalierung: Die Auswirkungen eines einzelnen Tags auf die Leistung sind möglicherweise vernachlässigbar, können aber erheblich werden, wenn Dutzende oder Hunderte von Tags auf derselben Seite verwendet werden.

Nicht alle Skripts sollten mit einem Tag-Manager geladen werden

Tag-Manager eignen sich in der Regel nicht zum Laden von Ressourcen, die unmittelbare visuelle oder funktionale Aspekte der Nutzererfahrung implementieren, z. B. Cookie-Hinweise, Hero-Images oder Websitefunktionen. Wenn Sie diese Ressourcen mit einem Tag-Manager laden, verzögert sich in der Regel die Bereitstellung. Das ist nicht nutzerfreundlich und kann zu einer Steigerung von Messwerten wie LCP und CLS führen. Außerdem sollten Sie berücksichtigen, dass einige Nutzer Tag-Manager blockieren. Wenn Sie UX-Funktionen mit einem Tag-Manager implementieren, kann dies bei einigen Nutzern zu einer fehlerhaften Website führen.

Vorsicht bei benutzerdefinierten HTML-Tags

Benutzerdefinierte HTML-Tags gibt es schon seit vielen Jahren und werden auf den meisten Websites häufig verwendet. Mit benutzerdefinierten HTML-Tags kannst du deinen eigenen Code mit wenigen Einschränkungen eingeben, da dieses Tag trotz des Namens hauptsächlich dazu dient, einer Seite benutzerdefinierte <script>-Elemente hinzuzufügen.

Benutzerdefinierte HTML-Tags können vielfältig eingesetzt werden und ihre Auswirkungen auf die Leistung variieren erheblich. Beachten Sie beim Messen der Leistung Ihrer Website, dass die meisten Tools die Auswirkung eines benutzerdefinierten HTML-Tags auf die Leistung dem Tag-Manager zuordnen, der das Tag eingefügt hat, und nicht dem Tag selbst.

Mit benutzerdefinierten HTML-Tags kann ein Element in die umgebende Seite eingefügt werden. Das Einfügen von Elementen in die Seite kann zu Leistungsproblemen und in einigen Fällen auch zu Layoutverschiebungen führen.

• Wenn ein Element in die Seite eingefügt wird, muss in den meisten Fällen der Browser die Größe und Position jedes Elements auf der Seite neu berechnen. Dieser Vorgang wird als Layout bezeichnet. Die Auswirkungen eines einzelnen Layouts auf die Leistung sind minimal. Wenn es jedoch übermäßig oft vorkommt, kann dies zu Leistungsproblemen führen. Die Auswirkungen dieses Phänomens sind auf Low-End-Geräten und Seiten mit einer hohen Anzahl von DOM-Elementen größer.
• Wenn ein sichtbares Seitenelement in das DOM eingefügt wird, nachdem der umgebende Bereich bereits gerendert wurde, kann dies zu einer Layoutverschiebung führen. Dieses Phänomen tritt nicht nur bei Tag-Managern auf. Da Tags jedoch in der Regel später als andere Teile der Seite geladen werden, werden sie häufig in das DOM eingefügt, nachdem die umgebende Seite bereits gerendert wurde.

Benutzerdefinierte Vorlagen verwenden

Benutzerdefinierte Vorlagen unterstützen einige der gleichen Vorgänge wie benutzerdefinierte HTML-Tags. Sie basieren jedoch auf einer Sandbox-Version von JavaScript, die APIs für gängige Anwendungsfälle wie Skriptinjektion und Pixel Injection bereitstellt. Wie der Name schon sagt, ermöglichen sie die Erstellung einer Vorlage durch einen Poweruser, der die Leistung im Blick behalten kann. Weniger technisch orientierte Nutzende können die Vorlage dann verwenden. Dies ist häufig sicherer als die Bereitstellung des vollständigen Zugriffs auf benutzerdefiniertes HTML.

Aufgrund der höheren Einschränkungen für benutzerdefinierte Vorlagen treten bei diesen Tags viel weniger Leistungs- oder Sicherheitsprobleme auf. Aus denselben Gründen funktionieren benutzerdefinierte Vorlagen jedoch nicht für alle Anwendungsfälle.

Skripts korrekt einfügen

Ein häufiger Anwendungsfall ist die Verwendung eines Tag-Managers zum Einfügen eines Skripts. Wir empfehlen dafür eine benutzerdefinierte Vorlage und die injectScript API.

Informationen zum Konvertieren eines vorhandenen benutzerdefinierten HTML-Tags mithilfe der InsertScript API finden Sie unter Vorhandenes Tag konvertieren.

Wenn Sie ein benutzerdefiniertes HTML-Tag verwenden müssen, beachten Sie Folgendes:

• Bibliotheken und umfangreiche Drittanbieter-Skripts sollten über ein Skript-Tag geladen werden, mit dem eine externe Datei (z. B. <script src="external-scripts.js">) heruntergeladen wird, anstatt den Inhalt des Skripts direkt in das Tag zu kopieren. Obwohl bei der Verwendung des <script>-Tags ein separater Round-Trip zum Herunterladen der Skriptinhalte entfällt, wird durch diese Praxis die Containergröße erhöht und verhindert, dass das Skript vom Browser separat im Cache gespeichert wird.
• Viele Anbieter empfehlen, ihr <script>-Tag oben im <head> zu platzieren. Für Skripts, die über Tag Manager geladen werden, ist diese Empfehlung normalerweise nicht erforderlich: In den meisten Fällen hat der Browser das Parsing des <head>-Objekts zum Zeitpunkt der Ausführung des Tag Managers bereits abgeschlossen.

Pixel verwenden

In einigen Fällen können Drittanbieterskripts durch Bild- oder iFrame-"Pixel" ersetzt werden. Im Vergleich zu skriptbasierten Pendants unterstützen Pixel unter Umständen weniger Funktionen und gelten deshalb oft als weniger bevorzugte Implementierung. Wenn Pixel jedoch innerhalb von Tag Managern verwendet werden, können sie dynamischer sein, da sie bei Triggern ausgelöst und verschiedene Variablen übergeben werden können. Sie sind der leistungsfähigste und sicherste Tag-Typ, da nach dem Auslösen kein JavaScript ausgeführt wird. Pixel haben eine sehr kleine Ressourcengröße (unter 1 KB) und verursachen keine Layoutverschiebungen.

Erkundigen Sie sich bei Ihrem Drittanbieter, wie er Pixel unterstützt. Außerdem können Sie versuchen, den Code auf ein <noscript>-Tag zu prüfen. Wenn ein Anbieter Pixel unterstützt, werden diese häufig in das <noscript>-Tag eingefügt.

Alternativen zu Pixeln

Pixel wurden vor allem deshalb so beliebt, weil sie früher eine der kostengünstigsten und zuverlässigsten Möglichkeiten zum Senden von HTTP-Anfragen in Situationen waren, in denen die Serverantwort nicht relevant ist ( z. B. beim Senden von Daten an Analyseanbieter). Die APIs navigator.sendBeacon() und fetch() keepalive sind auf denselben Anwendungsfall ausgelegt, sind aber wesentlich zuverlässiger als Pixel.

Die weitere Verwendung von Pixeln ist völlig in Ordnung. Sie werden gut unterstützt und haben nur minimale Auswirkungen auf die Leistung. Falls Sie jedoch eigene Beacons erstellen, lohnt es sich, eine dieser APIs zu verwenden.

sendBeacon()

Die navigator.sendBeacon() API wurde für das Senden kleiner Datenmengen an Webserver entwickelt, wenn die Serverantwort keine Rolle spielt.

const url = "https://example.com/analytics";
const data = JSON.stringify({
    event: "checkout",
    time: performance.now()
});

navigator.sendBeacon(url, data);

Die API von sendBeacon() ist eingeschränkt: Sie unterstützt nur das Senden von POST-Anfragen, das Festlegen benutzerdefinierter Header wird nicht unterstützt. Es wird von allen modernen Browsern unterstützt.

fetch() keepalive

keepalive ist ein Flag, mit dem die Fetch API für nicht blockierende Anfragen wie Ereignisberichte und -analysen verwendet werden kann. Dazu wird keepalive: true in die Parameter eingefügt, die an fetch() übergeben werden.

const url = "https://example.com/analytics";
const data = JSON.stringify({
  event: "checkout",
  time: performance.now()
});

fetch(url, {
    method: 'POST',
    body: data,
    keepalive: true
});

Wenn fetch() keepalive und sendBeacon() sehr ähnlich zu sein scheinen, liegt das daran, dass sie es sind. In Chromium-Browsern basiert sendBeacon() jetzt auf fetch() keepalive.

Wenn Sie sich zwischen fetch() keepalive und sendBeacon() entscheiden, sollten Sie die Funktionen und die Browserunterstützung berücksichtigen, die Sie benötigen. Die Abruf() API ist wesentlich flexibler. keepalive bietet jedoch weniger Browserunterstützung als sendBeacon().

Erläuterung

Tags werden häufig gemäß den Anweisungen eines Drittanbieters erstellt. Wenn nicht klar ist, wozu der Code eines Anbieters dient, fragen Sie eine Person, die diese Funktion kennt. Wenn Sie eine zweite Meinung einholen, können Sie feststellen, ob ein Tag Leistungs- oder Sicherheitsprobleme verursachen kann.

Wir empfehlen außerdem, Tags im Tag Manager mit einem Inhaber zu versehen. Es ist weit zu leicht, den Inhaber eines Tags zu vergessen und scheuen sich, es vorsichtshalber zu entfernen.

Trigger

Grundsätzlich sollten Sie bei der Optimierung von Tag-Triggern im Allgemeinen darauf achten, dass Tags nicht mehr als nötig ausgelöst werden, und einen Trigger auswählen, mit dem die geschäftlichen Anforderungen und die Leistungskosten in Einklang gebracht werden.

Die Trigger selbst sind JavaScript-Code, mit dem die Größe und die Ausführungskosten des Tag Managers erhöht werden. Auch wenn die meisten Trigger klein sind, kann sich der kumulative Effekt summieren. Wenn Sie beispielsweise viele Klickereignisse oder Timer-Trigger verwenden, kann dies die Arbeitslast des Tag-Managers erheblich erhöhen.

Geeignetes Trigger-Ereignis auswählen

Die Auswirkungen auf die Leistung sind nicht festgelegt. Generell gilt: Je früher ein Tag ausgelöst wird, desto größer ist seine Auswirkung auf die Leistung. Ressourcen sind in der Regel während des anfänglichen Seitenaufbaus beschränkt. Daher werden durch das Laden oder Ausführen einer bestimmten Ressource (oder eines Tags) Ressourcen von etwas anderem abgezogen.

Obwohl es wichtig ist, geeignete Trigger für alle Tags auszuwählen, ist dies besonders wichtig für Tags, die große Ressourcen laden oder lange Skripts ausführen.

Tags können bei Seitenaufrufen (normalerweise Page load, am DOM Ready und Window Loaded) oder auf der Grundlage eines benutzerdefinierten Ereignisses ausgelöst werden. Damit der Seitenaufbau nicht beeinträchtigt wird, sollten nicht unbedingt erforderliche Tags nach Window Loaded ausgelöst werden.

Benutzerdefinierte Ereignisse verwenden

Mit benutzerdefinierten Ereignissen können Sie Trigger als Reaktion auf Seitenereignisse auslösen, die nicht von den integrierten Triggern von Google Tag Manager abgedeckt werden. Für viele Tags werden beispielsweise Seitenaufruf-Trigger verwendet. Der Zeitraum zwischen DOM Ready und Window Loaded kann jedoch auf vielen Seiten lang sein, was eine Feinabstimmung erschweren kann, wenn ein Tag ausgelöst wird. Benutzerdefinierte Ereignisse bieten eine Lösung für dieses Problem.

Wenn Sie benutzerdefinierte Ereignisse verwenden möchten, müssen Sie zuerst einen Trigger für benutzerdefinierte Ereignisse erstellen und Ihre Tags so aktualisieren, dass dieser Trigger verwendet wird.

Übertragen Sie das entsprechende Ereignis an die Datenschicht, um den Trigger auszulösen.

// Custom event trigger that fires after 2 seconds
setTimeout(() => {
  dataLayer.push({
    'event' : 'my-custom-event'
  });
}, 2000);

Bestimmte Triggerbedingungen verwenden

Durch die Verwendung bestimmter Triggerbedingungen lässt sich vermeiden, dass ein Tag unnötigerweise ausgelöst wird. Es gibt viele Möglichkeiten, dieses Konzept anzuwenden. Eine der einfachsten, aber nützlichsten Maßnahmen besteht darin, dass ein Tag nur auf Seiten ausgelöst wird, auf denen es tatsächlich verwendet wird.

Integrierte Variablen können ebenfalls in Triggerbedingungen eingebunden werden, um die Tag-Auslösung zu begrenzen.

Beachten Sie jedoch, dass komplexe Triggerbedingungen oder Ausnahmen die Verarbeitungszeit selbst erfordern. Machen Sie sie also nicht zu komplex.

Laden Sie Ihren Tag Manager zu einem geeigneten Zeitpunkt.

Wenn Sie anpassen, wann der Tag Manager selbst geladen wird, kann dies erhebliche Auswirkungen auf die Leistung haben. Trigger können unabhängig von ihrer Konfiguration erst ausgelöst werden, nachdem ein Tag Manager geladen wurde. Obwohl es wichtig ist, für einzelne Tags geeignete Trigger auszuwählen (wie oben erläutert), hat das Experimentieren mit dem Laden des Tag Managers oft die gleiche oder größere Auswirkung, da diese eine Entscheidung sich auf alle Tags auf einer Seite auswirkt.

Wenn Sie den Tag Manager später laden, erhalten Sie auch eine Kontrollebene und können künftige Leistungsprobleme vermeiden. So wird verhindert, dass ein Tag Manager-Nutzer versehentlich ein Tag zu früh lädt, ohne sich dessen Auswirkungen bewusst zu machen.

Variablen

Mithilfe von Variablen können Daten von der Seite gelesen werden. Sie sind in Triggern und in Tags selbst nützlich.

Genau wie Trigger führen auch Variablen dazu, dass JavaScript-Code im Tag Manager hinzugefügt wird, was zu Leistungsproblemen führen kann. Variablen können relativ einfache integrierte Typen sein, mit denen beispielsweise Teile der URL, Cookies, Datenschicht oder DOM gelesen werden können. Es kann sich auch um benutzerdefiniertes JavaScript handeln, das praktisch unbegrenzte Funktionen bietet.

Halten Sie Variablen einfach und auf ein Minimum, da sie vom Tag Manager kontinuierlich ausgewertet werden müssen. Entfernen Sie alte Variablen, die nicht mehr verwendet werden, um sowohl die Größe des Tag Manager-Skripts als auch die dafür erforderliche Verarbeitungszeit zu reduzieren.

Tag-Verwaltung

Die effiziente Verwendung der Tags verringert das Risiko von Leistungsproblemen.

Datenschicht verwenden

Die Datenschicht „enthält alle Informationen, die an Google Tag Manager übergeben werden sollen“. Genauer gesagt, handelt es sich um ein JavaScript-Array von Objekten, die Informationen über die Seite enthalten. Er kann auch zum Auslösen von Tags verwendet werden.

// Contents of the data layer
window.dataLayer = [{
    'pageCategory': 'signup',
    'visitorType': 'high-value'
  }];

// Pushing a variable to the data layer
window.dataLayer.push({'variable_name': 'variable_value'});

// Pushing an event to the data layer
window.dataLayer.push({'event': 'event_name'});

Google Tag Manager kann auch ohne die Datenschicht verwendet werden, wird aber dringend empfohlen. Mit der Datenschicht können Sie die Daten, auf die Skripts von Drittanbietern zugreifen, an einem einzigen Ort konsolidieren. So erhalten Sie einen besseren Einblick in deren Nutzung. Dies kann unter anderem dazu beitragen, redundante Variablenberechnungen und die Skriptausführung zu reduzieren. Außerdem wird damit gesteuert, auf welche Daten über die Tags zugegriffen wird, anstatt vollständigen JavaScript-Variablen- oder DOM-Zugriff zu gewähren.

Doppelte und nicht verwendete Tags entfernen

Doppelte Tags können auftreten, wenn ein Tag nicht nur durch einen Tag-Manager eingeschleust wird, sondern auch im HTML-Markup einer Seite enthalten ist.

Nicht verwendete Tags sollten pausiert oder entfernt werden, anstatt eine Triggerausnahme zu verwenden. Wenn Sie ein Tag pausieren oder entfernen, wird der Code aus dem Container entfernt. Die Blockierung tut dies nicht.

Wenn nicht verwendete Tags entfernt werden, sollten auch die Trigger und Variablen überprüft werden, um festzustellen, ob sie entfernt werden können, wenn sie nur von diesen Tags verwendet werden.

Zulassungs- und Sperrlisten verwenden

Mit Zulassungs- und Ablehnungslisten können Sie sehr detaillierte Einschränkungen für die Tags, Trigger und Variablen konfigurieren, die auf einer Seite zulässig sind. Dies kann verwendet werden, um Best Practices für die Leistung und andere Richtlinien durchzusetzen.

Zulassungs- und Sperrlisten werden über die Datenschicht konfiguriert.

window.dataLayer = [{
  'gtm.allowlist': ['<id>', '<id>', ...],
  'gtm.blocklist': ['customScripts']
}];

Benutzerdefinierte HTML-Tags und JavaScript-Variablen sowie der direkte DOM-Zugriff können beispielsweise nicht zugelassen werden. Es können also nur Pixel und vordefinierte Tags mit Daten aus der Datenschicht verwendet werden. Dies ist zwar sicherlich restriktiv, kann aber zu einer viel leistungsstärkeren und sichereren Tag Manager-Implementierung führen.

Serverseitiges Tagging verwenden

Der Wechsel zum serverseitigen Tagging ist keine leichte Aufgabe. Es lohnt sich aber, in Betracht zu ziehen – insbesondere bei größeren Websites, die mehr Kontrolle über ihre Daten haben möchten. Beim serverseitigen Tagging wird Anbietercode vom Client entfernt und damit die Verarbeitung vom Client auf den Server verlagert.

Wenn Sie beispielsweise clientseitiges Tagging verwenden, führt das Senden von Daten an mehrere Analysekonten dazu, dass der Client separate Anfragen für jeden Endpunkt initiiert. Im Gegensatz dazu sendet der Client beim serverseitigen Tagging eine einzige Anfrage an den serverseitigen Container. Von dort werden diese Daten an verschiedene Analysekonten weitergeleitet.

Beachten Sie, dass serverseitiges Tagging nur mit einigen Tags funktioniert; die Tag-Kompatibilität variiert je nach Anbieter.

Weitere Informationen finden Sie unter Einführung in das serverseitige Tagging.

Container

Tag Manager lassen in der Regel mehrere Instanzen oder „Container“ innerhalb ihrer Einrichtung zu. So können mehrere Container über ein Tag-Verwaltungskonto gesteuert werden.

Nur einen Container pro Seite verwenden

Die Verwendung mehrerer containers auf einer einzigen Seite kann zu erheblichen Leistungsproblemen führen, da dies zusätzlichen Aufwand und die Skriptausführung mit sich bringt. Zumindest dupliziert sie den Kern-Tag-Code selbst. Dieser wird als Teil des JavaScript-Codes des Containers bereitgestellt und kann nicht zwischen den Containern wiederverwendet werden.

Es kommt selten vor, dass mehrere Container effektiv eingesetzt werden. Es kann jedoch Fälle geben, in denen dies – bei guter Kontrolle – funktioniert, wie z. B.:

• Verwenden Sie einen leichteren Container mit Vorabladung und einen größeren Container mit späterer Ladung anstelle eines großen Containers.
• Ein eingeschränkter Container für Tags, die von weniger technisch versierten Nutzern verwendet werden, mit einem weniger eingeschränkten, aber strengeren gesteuerten Container für Tags, die im eingeschränkten Container nicht verwendet werden können.

Wenn Sie mehrere Container pro Seite verwenden müssen, folgen Sie der Google Tag Manager-Anleitung zum Einrichten mehrerer Container.

Bei Bedarf separate Container verwenden

Wenn Sie einen Tag-Manager für mehrere Properties verwenden (z. B. eine Web-App und eine mobile App), kann die Anzahl der verwendeten Container die Produktivität Ihres Workflows beeinträchtigen. Außerdem kann sich das auf die Leistung auswirken.

Im Allgemeinen kann ein einzelner Container effektiv an mehreren Standorten verwendet werden, wenn die Websites in Bezug auf Verwendung und Struktur ähnlich sind. Beispiel: Auch wenn die mobilen Apps und Webanwendungen einer Marke ähnliche Funktionen erfüllen, sind die Anwendungen wahrscheinlich unterschiedlich strukturiert und werden daher effektiver über separate Container verwaltet.

Wenn Sie versuchen, einen einzelnen Container zu allgemein wiederverwenden, werden die Komplexität und die Größe des Containers in der Regel unnötig erhöht, da zur Verwaltung von Tags und Triggern eine komplexe Logik erforderlich ist.

Behalten Sie die Containergröße im Blick

Die Größe eines Containers wird durch seine Tags, Trigger und Variablen bestimmt. Obwohl sich ein kleiner Container weiterhin negativ auf die Seitenleistung auswirken kann, trifft dies mit hoher Wahrscheinlichkeit zu einem großen Container.

Die Containergröße sollte bei der Optimierung der Tag-Nutzung keine Orientierungshilfe sein. Sie ist jedoch oft ein Warnzeichen dafür, dass ein Container nicht gut gewartet und möglicherweise missbraucht wird.

In Google Tag Manager begrenzt die Containergröße auf 200 KB und es wird eine Warnung ausgegeben, wenn die Größe des Containers ab 140 KB beginnt. Die meisten Websites sollten jedoch versuchen, die Container weit kleiner zu halten. Der Medianwert des Websitecontainers beträgt etwa 50 KB.

Die Größe des Containers lässt sich anhand der Größe der Antwort ermitteln, die von https://www.googletagmanager.com/gtag/js?id=YOUR_ID zurückgegeben wird. Diese Antwort enthält die Google Tag Manager-Bibliothek und den Inhalt des Containers. Die Google Tag Manager-Bibliothek selbst ist mit ca. 33 KB komprimiert.

Containerversionen benennen

Eine Containerversion ist ein Snapshot des Containerinhalts zu einem bestimmten Zeitpunkt. Ein aussagekräftiger Name und eine kurze Beschreibung relevanter Änderungen darin können die Behebung zukünftiger Leistungsprobleme erheblich erleichtern.

Tagging-Workflows

Es ist wichtig, Änderungen an Ihren Tags zu verwalten, damit sie sich nicht negativ auf die Seitenleistung auswirken.

Tags vor der Bereitstellung testen

Wenn Sie Ihre Tags vor der Bereitstellung testen, können Sie Probleme (Leistung und ansonsten) schon vor dem Versand erkennen.

Folgendes sollten Sie beim Testen eines Tags beachten:

• Funktioniert das Tag richtig?
• Verursacht das Tag Layoutverschiebungen?
• Werden durch das Tag Ressourcen geladen? Wie groß sind diese Ressourcen?
• Löst das Tag ein lang andauerndes Skript aus?

Vorschaumodus

Im Vorschaumodus können Sie Tag-Änderungen auf Ihrer Website testen, ohne sie zuerst öffentlich bereitstellen zu müssen. Der Vorschaumodus umfasst eine Debugging-Konsole mit Informationen zu Tags.

Die Ausführungszeit von Google Tag Manager im Vorschaumodus ist etwas länger (etwas langsamer), da der zusätzliche Aufwand für die Darstellung von Informationen in der Debugging-Konsole erforderlich ist. Daher wird empfohlen, die im Vorschaumodus erfassten Web Vitals-Messwerte nicht mit denen in der Produktionsphase zu vergleichen. Diese Abweichung sollte sich jedoch nicht auf das Ausführungsverhalten der Tags selbst auswirken.

Eigenständige Tests

Ein alternativer Ansatz zum Testen von Tags besteht darin, eine leere Seite einzurichten, die einen Container mit einem einzigen Tag – dem zu testenden Tag – enthält. Diese Testeinrichtung ist weniger realistisch und es werden einige Probleme nicht erkannt (z. B. ob ein Tag Layoutverschiebungen verursacht). Es kann jedoch einfacher sein, die Auswirkungen des Tags auf Aspekte wie die Skriptausführung zu isolieren und zu messen. Hier erfahren Sie, wie Telegraph mit diesem Isolationsansatz die Leistung von Drittanbietercode verbessert.

Tag-Leistung beobachten

Mit der Monitoring API von Google Tag Manager können Sie Informationen zur Ausführungszeit eines bestimmten Tags abrufen. Diese Informationen werden an einen von Ihnen ausgewählten Endpunkt gemeldet.

Weitere Informationen finden Sie unter Google Tag Manager-Monitor erstellen.

Genehmigung für Containeränderungen verlangen

Eigener Code wird in der Regel vor der Bereitstellung geprüft und getestet. Behandeln Sie Ihre Tags gleich. Dazu können Sie die Bestätigung in zwei Schritten hinzufügen, für die bei Containeränderungen die Genehmigung eines Administrators erforderlich ist. Wenn Sie die Bestätigung in zwei Schritten nicht verlangen, aber Änderungen im Auge behalten möchten, können Sie Containerbenachrichtigungen einrichten, um E-Mail-Benachrichtigungen über Containerereignisse Ihrer Wahl zu erhalten.

Tag-Nutzung regelmäßig prüfen

Eine der Herausforderungen bei der Arbeit mit Tags besteht darin, dass sie sich im Laufe der Zeit ansammeln: Tags werden hinzugefügt, aber selten entfernt. Die regelmäßige Überprüfung der Tags ist eine Möglichkeit, diesem Trend entgegenzuwirken. Die ideale Häufigkeit hierfür hängt davon ab, wie oft die Tags Ihrer Website aktualisiert werden.

Wenn Sie jedes Tag so mit Labels versehen, dass der Inhaber klar erkennbar ist, können Sie einfacher erkennen, wer auf das Tag reagiert und ob es noch benötigt wird.

Denken Sie bei der Prüfung von Tags daran, auch die Trigger und Variablen zu bereinigen. Sie können auch leicht die Ursache für Leistungsprobleme sein.

Weitere Informationen finden Sie unter Drittanbieter-Skripts unter Kontrolle halten.