Veröffentlicht: 29. Juli 2021
Tags sind Code-Snippets von Drittanbietern, die in eine Website eingefügt werden, in der Regel mit einem Tag-Manager. Tags werden am häufigsten für Marketing- und Analysezwecke verwendet.
Die Auswirkungen von Tags und Tag-Managern auf die Leistung variieren stark je nach Website. Tag Manager lässt sich mit einem Umschlag vergleichen: Der Tag Manager stellt ein Gefäß bereit, aber was Sie hineinfüllen und wie Sie es verwenden, liegt größtenteils in Ihrer Hand.
Hier erfahren Sie, wie Sie Tags und Tag-Manager für Leistung und Core Web Vitals optimieren. Dieses Dokument bezieht sich zwar auf Google Tag Manager, viele der hier vorgestellten Ideen sind aber auch auf andere Tag-Manager anwendbar.
Auswirkungen auf Core Web Vitals
Tag-Manager können sich oft indirekt auf Ihre Core Web Vitals auswirken, indem sie Ressourcen verbrauchen, die zum schnellen Laden und zur reaktionsschnellen Darstellung Ihrer Seite erforderlich sind. Die Bandbreite kann für das Herunterladen des Tag Manager-JavaScripts für Ihre Websites oder für die nachfolgenden Aufrufe verwendet werden. Die CPU-Zeit im Hauptthread kann für die Bewertung und Ausführung des im Tag Manager und in den Tags enthaltenen JavaScript-Codes aufgewendet werden.
Der Largest Contentful Paint (LCP) ist während der kritischen Seitenladezeit anfällig für Bandbreitenkonflikte. Außerdem kann das Blockieren des Hauptthreads die Renderingzeit des LCP verzögern.
Der Cumulative Layout Shift (CLS) kann beeinträchtigt werden, entweder durch das verzögerte Laden wichtiger Ressourcen vor dem ersten Rendern oder durch Tag-Manager, die Inhalte auf die Seite einschleusen.
Der Wert Interaction to Next Paint (INP) ist anfällig für CPU-Konkurrenz im Haupt-Thread. Wir haben eine Korrelation zwischen der Größe von Tag-Managern und schlechteren INP-Werten festgestellt.
Den richtigen Tag-Typ auswählen
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 den zulässigen Funktionen.
Die Art und Weise, wie Sie ein Tag verwenden, hat großen Einfluss auf die Leistungsauswirkung. "Pixel" sind vor allem deshalb sehr leistungsfähig, weil die Verwendung dieses Tag-Typs mit strengen Einschränkungen verbunden ist. Benutzerdefinierte HTML-Tags bringen nicht zwangsläufig eine schlechte Leistung mit sich. Aufgrund der Freiheit, die sie Nutzern bieten, können sie jedoch leicht missbraucht werden, was sich negativ auf die Leistung auswirkt.
Denken Sie bei Tags immer an die Skalierung: Die Leistungsauswirkung eines einzelnen Tags ist möglicherweise vernachlässigbar, kann aber erheblich werden, wenn auf derselben Seite Dutzende oder Hunderte von Tags verwendet werden.
Nicht alle Scripts sollten über ein Tag-Management-System geladen werden
Tag-Manager sind in der Regel nicht die beste Lösung, um Ressourcen zu laden, die unmittelbare visuelle oder funktionale Aspekte der Nutzererfahrung implementieren, z. B. Cookie-Benachrichtigungen, Hero-Bilder oder Websitefunktionen. Wenn Sie diese Ressourcen über einen Tag-Manager laden, wird die Auslieferung in der Regel verzögert. Das ist nicht nutzerfreundlich und kann auch Messwerte wie LCP und CLS erhöhen.
Außerdem blockieren einige Nutzer Tag-Manager. Wenn Sie UX-Funktionen mit einem Tag-Manager implementieren, kann das bei einigen Nutzern zu einer nicht funktionierenden 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 können Sie Ihren eigenen Code mit wenigen Einschränkungen eingeben. Trotz des Namens dient dieses Tag hauptsächlich dazu, einer Seite benutzerdefinierte <script>
-Elemente hinzuzufügen.
Benutzerdefinierte HTML-Tags können auf vielfältige Weise verwendet werden und ihre Auswirkungen auf die Leistung variieren stark. Beachten Sie beim Messen der Leistung Ihrer Website, dass die meisten Tools die Auswirkungen 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 können Sie ein Element in die umgebende Seite einfügen. Das Einfügen von Elementen auf der Seite kann zu Leistungsproblemen und in einigen Fällen auch zu Layoutänderungen führen.
- Wenn ein Element in die Seite eingefügt wird, muss der Browser in den meisten Fällen 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 sie jedoch übermäßig auftreten, kann dies zu Leistungsproblemen werden. Dieses Phänomen wirkt sich bei Low-End-Geräten und Seiten mit einer hohen Anzahl von DOM-Elementen noch stärker aus.
- 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 ist nicht nur bei Tag-Managern zu beobachten. Da Tags jedoch in der Regel später als andere Seitenelemente 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 derselben Vorgänge wie benutzerdefinierte HTML-Tags, basieren aber auf einer Sandbox-Version von JavaScript, die APIs für gängige Anwendungsfälle wie Script- und Pixel-Injection bietet. Wie der Name schon sagt, können damit Vorlagen von Powerusern erstellt werden, die diese mit Blick auf die Leistung erstellen. Weniger technisch orientierte Nutzer können die Vorlage dann verwenden. Das ist oft sicherer als der vollständige Zugriff auf benutzerdefinierte HTML-Inhalte.
Aufgrund der strengeren Einschränkungen für benutzerdefinierte Vorlagen treten bei diesen Tags viel seltener Leistungs- oder Sicherheitsprobleme auf. Aus denselben Gründen funktionieren benutzerdefinierte Vorlagen nicht für alle Anwendungsfälle.
Skripts korrekt einfügen
Die Verwendung eines Tag-Managers zum Einschleusen eines Scripts ist ein sehr häufiger Anwendungsfall. Dazu wird empfohlen, eine benutzerdefinierte Vorlage und die injectScript
API zu verwenden.
Informationen zur Verwendung der injectScript API zum Konvertieren eines vorhandenen benutzerdefinierten HTML-Tags finden Sie in diesem Artikel.
Wenn Sie ein benutzerdefiniertes HTML-Tag verwenden müssen, beachten Sie Folgendes:
- Bibliotheken und große Drittanbieterscripts sollten mit einem Script-Tag (z. B.
<script src="external-scripts.js">
) geladen werden, über das eine externe Datei heruntergeladen wird, anstatt den Inhalt des Scripts direkt in das Tag zu kopieren und einzufügen. Wenn Sie das<script>
-Tag nicht verwenden, wird zwar ein separater Rück- und Vorlauf zum Herunterladen des Inhalts des Scripts vermieden, die Containergröße wird dadurch jedoch erhöht und das Script kann nicht separat vom Browser im Cache gespeichert werden. - Viele Anbieter empfehlen, das
<script>
-Tag oben im<head>
zu platzieren. Bei Scripts, die mit dem Tag Manager geladen werden, ist dies jedoch oft nicht erforderlich. In den meisten Fällen hat der Browser das<head>
bereits geparst, wenn der Tag Manager ausgeführt wird.
Pixel verwenden
Manchmal können Drittanbieter-Scripts durch Bild- oder iFrame-Pixel ersetzt werden. Im Vergleich zu skriptbasierten Gegenstücken unterstützen Pixel möglicherweise weniger Funktionen und werden daher oft als weniger bevorzugte Implementierung angesehen. In Tag Manager können Pixel jedoch dynamischer sein, da sie bei Triggern ausgelöst und verschiedene Variablen übergeben werden können.
Pixel sind die leistungsstärkste und sicherste Art von Tag, da nach dem Auslösen keine JavaScript-Ausführung erfolgt. Pixel haben eine sehr geringe Ressourcengröße (weniger als 1 KB) und verursachen keine Layoutverschiebungen.
Weitere Informationen zur Pixelunterstützung erhalten Sie vom Drittanbieter. Sie können außerdem versuchen, den Code auf ein <noscript>
-Tag zu prüfen.
Wenn ein Anbieter Pixel unterstützt, fügt er sie oft in das <noscript>
-Tag ein.
Alternativen zu Pixeln
Pixels wurden vor allem deshalb populär, weil sie eine der günstigsten und zuverlässigsten Methoden waren, eine HTTP-Anfrage in Situationen zu senden, in denen die Serverantwort nicht relevant ist (z. B. beim Senden von Daten an Analyseanbieter). Die APIs navigator.sendBeacon()
und fetch() keepalive
sind für diesen Anwendungsfall konzipiert, aber wohl zuverlässiger als Pixel.
Sie können Pixel weiterhin verwenden. Sie werden gut unterstützt und haben nur minimale Auswirkungen auf die Leistung. Wenn Sie jedoch eigene Beacons erstellen, sollten Sie die Verwendung einer dieser APIs in Betracht ziehen.
sendBeacon()
Die navigator.sendBeacon()
API ist für das Senden kleiner Datenmengen an Webserver in Situationen konzipiert, in denen die Serverantwort keine Rolle spielt.
const url = "https://example.com/analytics";
const data = JSON.stringify({
event: "checkout",
time: performance.now()
});
navigator.sendBeacon(url, data);
sendBeacon()
hat eine eingeschränkte API: Sie unterstützt nur POST-Anfragen und das Festlegen benutzerdefinierter Header ist nicht möglich. Sie wird von allen modernen Browsern unterstützt.
Fetch API 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 an fetch()
übergebenen Parameter eingefügt.
const url = "https://example.com/analytics";
const data = JSON.stringify({
event: "checkout",
time: performance.now()
});
fetch(url, {
method: 'POST',
body: data,
keepalive: true
});
fetch() keepalive
und sendBeacon()
sind sich sehr ähnlich. In Chromium-Browsern basiert sendBeacon()
jetzt sogar auf fetch()
keepalive
.
Bei der Auswahl zwischen fetch() keepalive
und sendBeacon()
ist es wichtig, die Funktionen und die Browserunterstützung zu berücksichtigen, die Sie benötigen. Die fetch() API ist deutlich flexibler. Allerdings wird keepalive
von weniger Browsern unterstützt als sendBeacon()
.
Funktionsweise der Tags
Tags werden häufig anhand der Anleitung eines Drittanbieters erstellt. Wenn Sie nicht sicher sind, welche Funktion der Code eines Anbieters hat, fragen Sie jemanden, der sich damit auskennt. Mit einer zweiten Meinung können Sie feststellen, ob ein Tag Leistungs- oder Sicherheitsprobleme verursachen kann.
Wir empfehlen, Tags im Tag Manager mit einem Inhaber zu versehen. Man vergisst leicht, wem ein Tag gehört, was zu Angst vor der Entfernung führt, falls etwas kaputt geht!
Trigger
Im Allgemeinen besteht die Optimierung von Tag-Triggern darin, dafür zu sorgen, dass Tags nicht mehr als nötig ausgelöst werden, und einen Trigger auszuwählen, der die Geschäftsanforderungen mit den Leistungskosten in Einklang bringt.
Trigger sind JavaScript-Code, der die Größe und die Ausführungskosten des Tag Managers erhöht. Obwohl die meisten Auslöser klein sind, kann sich der kumulative Effekt summieren. Beispielsweise können mehrere Klickereignisse oder Timer-Trigger die Arbeitslast des Tag Managers erheblich erhöhen.
Geeignetes Triggerereignis auswählen
Die Auswirkungen eines Tags auf die Leistung können variieren. Je früher ein Tag ausgelöst wird, desto stärker wirkt es sich auf die Leistung aus. Ressourcen sind beim ersten Laden der Seite in der Regel knapp. Das Laden oder Ausführen einer bestimmten Ressource (oder eines bestimmten Tags) beansprucht daher Ressourcen, die für andere Zwecke benötigt werden.
Es ist zwar wichtig, für alle Tags geeignete Trigger auszuwählen, aber das ist besonders wichtig für Tags, die große Ressourcen laden oder lange Scripts ausführen.
Tags können durch Seitenaufrufe (normalerweise Page load
, am DOM Ready
oder Window Loaded
) oder auf Grundlage eines benutzerdefinierten Ereignisses ausgelöst werden. Lösen Sie unwichtige Tags nach Window Loaded
aus, um einen Einfluss auf den Seitenaufbau zu vermeiden.
Benutzerdefinierte Ereignisse verwenden
Mit benutzerdefinierten Ereignissen können Sie Trigger als Reaktion auf Seitenereignisse auslösen, die nicht von den integrierten Triggern in Google Tag Manager abgedeckt werden. So werden beispielsweise in vielen Tags Trigger für Seitenaufrufe verwendet. Die Zeit zwischen DOM Ready
und Window Loaded
kann jedoch lang sein, was die Feinabstimmung des Zeitpunkts der Tag-Auslösung erschwert. Dieses Problem kann durch benutzerdefinierte Ereignisse gelöst werden.
Erstellen Sie zuerst einen benutzerdefinierten Ereignistrigger und aktualisieren Sie Ihre Tags, damit 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
Legen Sie spezifische Triggerbedingungen fest, um zu verhindern, dass unnötige Tags ausgelöst werden. Eine der einfachsten und effektivsten Methoden besteht darin, dafür zu sorgen, dass ein Tag nur auf Seiten ausgelöst wird, auf denen es tatsächlich verwendet wird.
Integrierte Variablen können in Triggerbedingungen eingefügt werden, um das Auslösen von Tags einzuschränken.
Tag Manager zum richtigen Zeitpunkt laden
Sie können die Leistung verbessern, indem Sie anpassen, wann der Tag Manager geladen wird. Trigger können unabhängig von ihrer Konfiguration erst ausgelöst werden, nachdem ein Tag Manager geladen wurde. Testen Sie, wann Sie den Tag Manager laden, da dies eine ähnliche oder sogar größere Auswirkung haben kann. Diese Entscheidung wirkt sich auf alle Tags auf einer Seite aus.
Wenn Sie den Tag-Manager später laden, können Sie zukünftige Leistungsprobleme vermeiden, da so verhindert wird, dass ein Tag versehentlich zu früh geladen wird.
Variablen
Verwenden Sie Variablen, um Daten von der Seite zu lesen. Sie sind in Triggern und Tags selbst nützlich.
Ebenso wie bei Triggern fügen auch Variablen dem Tag-Manager JavaScript-Code hinzu. Dies kann zu Leistungsproblemen führen. Variablen können relativ klein sein, z. B. Code zum Lesen von Teilen der URL, Cookies, der Datenschicht oder des DOM. Sie können auch benutzerdefinierten JavaScript-Code enthalten, der unbegrenzte Funktionen (und Größe) hat.
Verwenden Sie Variablen möglichst sparsam, da sie vom Tag Manager kontinuierlich ausgewertet werden. Entfernen Sie alte Variablen, die nicht mehr verwendet werden, um sowohl die Größe des Tag Manager-Scripts als auch die Verarbeitungszeit zu reduzieren.
Tag-Verwaltung
Wenn Sie die Tags effizient verwenden, verringern Sie das Risiko von Leistungsproblemen.
Datenschicht verwenden
Die Datenschicht ist ein JavaScript-Array von Objekten, die Informationen zur Seite enthalten. Diese Objekte enthalten alle Informationen, die Sie an Google Tag Manager übergeben möchten.
Die Datenebene 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. In der Datenebene werden die Daten an einem Ort konsolidiert, auf die Drittanbieter-Scripts zugreifen können. So erhalten Sie einen besseren Überblick über die Nutzung. So lassen sich unter anderem redundante Variablenberechnungen und Scriptausführungen reduzieren.
Mit einer Datenschicht können Sie steuern, auf welche Daten die Tags zugreifen, anstatt ihnen vollen Zugriff auf JavaScript-Variablen oder das DOM zu gewähren.
Die Leistungsvorteile der Datenschicht sind möglicherweise nicht intuitiv, da durch die Aktualisierung der Datenschicht alle Containervariablen in Google Tag Manager neu bewertet und möglicherweise Tags ausgelöst werden, was die Ausführung von JavaScript erfordert. Es ist zwar möglich, die Datenebene zu missbrauchen, aber im Allgemeinen gilt: Wenn die Datenebene die Ursache für Leistungsprobleme zu sein scheint, liegen wahrscheinlich Leistungsprobleme am Container selbst vor. In der Datenebene werden diese Probleme deutlicher.
Doppelte und nicht verwendete Tags entfernen
Doppelte Tags können auftreten, wenn ein Tag nicht nur über einen Tag-Manager, 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. Beim Blockieren ist das nicht der Fall.
Wenn nicht verwendete Tags entfernt werden, prüfen Sie die Trigger und Variablen, um festzustellen, ob sie ebenfalls entfernt werden können.
Pausierte Tags wirken sich auf die Containergröße aus. Die Gesamtnutzlast ist jedoch kleiner als bei aktiven Tags.
Zulassungs- und Sperrlisten verwenden
Mit Zulassungs- und Ausschlusslisten können Sie sehr detaillierte Einschränkungen für die auf einer Seite zulässigen Tags, Trigger und Variablen konfigurieren. So können Sie Best Practices für die Leistung und andere Richtlinien durchsetzen.
Zulassen- und Ablehnenlisten werden über die Datenebene konfiguriert.
window.dataLayer = [{
'gtm.allowlist': ['<id>', '<id>', ...],
'gtm.blocklist': ['customScripts']
}];
Sie können beispielsweise die Verwendung benutzerdefinierter HTML-Tags, JavaScript-Variablen oder den direkten DOM-Zugriff verhindern. Das bedeutet, dass nur Pixel und vordefinierte Tags mit Daten aus der Datenschicht verwendet werden können. Das ist zwar einschränkend, kann aber zu einer leistungsstärkeren und sichereren Tag Manager-Implementierung führen.
Serverseitiges Tagging verwenden
Vor allem für größere Websites, die mehr Kontrolle über ihre Daten haben möchten, ist ein Wechsel zum serverseitigen Tagging empfehlenswert. Beim serverseitigen Tagging wird der Anbietercode vom Client entfernt und die Verarbeitung wird vom Client auf den Server verlagert.
Wenn Sie beispielsweise clientseitiges Tagging verwenden, werden Daten an mehrere Analysekonten gesendet, was bedeutet, dass der Client für jeden Endpunkt separate Anfragen initiiert. Beim serverseitigen Tagging sendet der Client eine einzelne Anfrage an den serverseitigen Container. Von dort werden die Daten an verschiedene Analytics-Konten weitergeleitet.
Das serverseitige Tagging funktioniert nur mit bestimmten Tags. Die Tag-Kompatibilität hängt vom Anbieter ab.
Weitere Informationen finden Sie unter Einführung in das serverseitige Tagging.
Container
Tag-Manager ermöglichen in der Regel mehrere Instanzen, die oft als Container bezeichnet werden. Mehrere Container können in einem Tag Manager-Konto verwaltet werden.
Verwenden Sie nur einen Container pro Seite
Mehrere Container auf einer einzelnen Seite können zu erheblichen Leistungsproblemen führen, da zusätzlicher Overhead und eine zusätzliche Scriptausführung erforderlich sind. Mindestens wird der Code des Core-Tags dupliziert, der nicht zwischen den Containern wiederverwendet werden kann, da er als Teil des JavaScript-Codes des Containers gesendet wird.
Es ist selten, dass mehrere Container effektiv genutzt werden. Es gibt jedoch Fälle, in denen dies funktionieren kann, wenn es gut kontrolliert wird. Beispiel:
- Sie verwenden einen leichteren Container für die Vorab- und einen schwereren Container für die spätere Ladung, anstatt einen großen Container.
- Verwenden Sie einen eingeschränkten Container für weniger technische Nutzer und einen weniger eingeschränkten, aber streng kontrollierten Container für komplexere Tags.
Wenn Sie mehrere Container pro Seite verwenden müssen, folgen Sie der Anleitung in Google Tag Manager zum Einrichten mehrerer Container.
Bei Bedarf separate Container verwenden
Wenn Sie einen Tag Manager für mehrere Properties verwenden, z. B. für eine Webanwendung und eine mobile App, kann die Anzahl der verwendeten Container die Produktivität Ihres Workflows beeinträchtigen oder verbessern. Außerdem kann sich das auf die Leistung auswirken.
Ein einzelner Container kann effektiv für mehrere Standorte verwendet werden, wenn die Standorte in Verwendung und Struktur ähnlich sind. Auch wenn die mobilen und Web-Apps einer Marke beispielsweise ähnliche Funktionen haben, sind sie wahrscheinlich unterschiedlich strukturiert und können daher über separate Container effizienter verwaltet werden.
Wenn Sie einen einzelnen Container zu breit verwenden, kann das die Komplexität und Größe des Containers erhöhen, da zum Verwalten von Tags und Triggern eine komplexe Logik erforderlich ist.
Containergröße im Blick behalten
Die Größe eines Containers wird durch seine Tags, Trigger und Variablen bestimmt. Auch wenn ein kleiner Container die Seitenleistung beeinträchtigen kann, ist das bei einem großen Container fast sicher der Fall.
Die Containergröße sollte nicht der wichtigste Messwert bei der Optimierung der Tag-Nutzung sein. Eine große Containergröße ist jedoch oft ein Warnzeichen dafür, dass ein Container nicht gut gewartet und möglicherweise missbraucht wird.
In Google Tag Manager ist die Containergröße auf 300 KB begrenzt. Wenn 70 % des Größenlimits erreicht sind, werden Sie über die Containergröße gewarnt.
Die meisten Websites sollten ihre Container kleiner als die Beschränkung halten. Zum Vergleich: Der Medianwert für Website-Container liegt bei etwa 50 KB. Die Google Tag Manager-Bibliothek allein ist um etwa 33 KB komprimiert.
Containerversionen benennen
Eine Containerversion ist ein Snapshot des Inhalts eines Containers zu einem bestimmten Zeitpunkt. Wenn Sie einen aussagekräftigen Namen verwenden und eine kurze Beschreibung der wesentlichen Änderungen hinzufügen, können Sie zukünftige Leistungsprobleme leichter beheben.
Tag-Workflows
Sie sollten Änderungen an Ihren Tags unbedingt verwalten, damit sie keine negativen Auswirkungen auf die Seitenleistung haben.
Vor der Bereitstellung testen
Testen Sie Ihre Tags vor der Bereitstellung, um Probleme, Leistungseinbußen und andere Fehler zu erkennen, bevor sie veröffentlicht werden.
Beim Testen eines Tags sollten Sie Folgendes beachten:
- Funktioniert das Tag richtig?
- Führt das Tag zu Layoutverschiebungen?
- Werden über das Tag Ressourcen geladen? Wie groß sind diese Ressourcen?
- Löst das Tag ein lang andauerndes Script aus?
Vorschaumodus
Im Vorschaumodus können Sie Tag-Änderungen auf Ihrer Website testen, ohne sie zuerst für die Öffentlichkeit freigeben zu müssen. Der Vorschaumodus umfasst eine Debugging-Konsole mit Informationen zu Tags.
Die Ausführungszeit von Google Tag Manager ist im Vorschaumodus aufgrund des zusätzlichen Overheads, der für die Anzeige von Informationen in der Debug-Konsole erforderlich ist, etwas länger. Daher wird der Vergleich von Web Vitals-Messwerten, die im Vorschaumodus erfasst wurden, mit denen aus der Produktionsumgebung nicht empfohlen. Diese Abweichung sollte jedoch keine Auswirkungen auf das Ausführungsverhalten der Tags selbst haben.
Eigenständige Tests
Ein alternativer Ansatz zum Testen von Tags besteht darin, eine leere Seite einzurichten, die einen Container mit einem einzigen Tag enthält – dem Tag, das Sie testen. Diese Testeinrichtung ist weniger realistisch und einige Probleme werden nicht erkannt (z. B. ob ein Tag zu Layoutverschiebungen führt). Sie kann jedoch die Auswirkungen des Tags auf Dinge wie die Scriptausführung leichter isolieren und messen. Sehen Sie sich an, wie Telegraph diesen Isolationsansatz einsetzt, um die Leistung von Drittanbietercode zu verbessern.
Tag-Leistung beobachten
Mit der Monitoring API von Google Tag Manager können Sie Informationen zum Ausführungszeitraum eines bestimmten Tags erfassen. Diese Informationen werden an einen Endpunkt Ihrer Wahl gesendet.
Weitere Informationen finden Sie unter Google Tag Manager-Monitor erstellen.
Genehmigung für Containeränderungen anfordern
Eigener Code wird vor der Bereitstellung in der Regel überprüft und getestet. Behandeln Sie Ihre Tags gleich.
Eine Möglichkeit besteht darin, die 2-Faktor-Authentifizierung hinzuzufügen, für die Containeränderungen die Genehmigung eines Administrators erfordern. Wenn Sie die Bestätigung in zwei Schritten nicht erzwingen, aber trotzdem Änderungen im Blick behalten möchten, können Sie Containerbenachrichtigungen einrichten, um E-Mail-Benachrichtigungen zu Containerereignissen 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. Eine regelmäßige Überprüfung der Tags ist eine Möglichkeit, diesen Trend umzukehren. Die ideale Häufigkeit hängt davon ab, wie oft die Tags Ihrer Website aktualisiert werden.
Wenn Sie jedes Tag so beschriften, dass der Inhaber offensichtlich ist, können Sie leichter feststellen, wer für dieses Tag ansprecht und ob es noch benötigt wird.
Denken Sie beim Prüfen von Tags daran, Trigger und Variablen zu bereinigen. Sie können auch oft die Ursache für Leistungsprobleme sein.
Weitere Informationen finden Sie unter Drittanbieter-Scripts im Blick behalten.