Veröffentlicht: 29. Juli 2021
Tags sind Snippets von Drittanbietercode, die in eine Website eingefügt werden, normalerweise mit einem Tag-Manager. Tags werden am häufigsten für Marketing und Analysen verwendet.
Die Auswirkungen von Tags und Tag-Managern auf die Leistung variieren von Website zu Website stark. Tag-Manager können mit einem Umschlag verglichen werden: Der Tag-Manager stellt ein Gefäß bereit, aber womit Sie es füllen und wie Sie es verwenden, liegt größtenteils bei Ihnen.
Hier werden Techniken zur Optimierung von Tags und Tag-Managern für die Leistung und die Core Web Vitals erläutert. In diesem Dokument wird zwar auf Google Tag Manager verwiesen, viele der beschriebenen Konzepte gelten jedoch auch für andere Tag-Manager.
Auswirkungen auf die Core Web Vitals
Tag-Manager können sich oft indirekt auf die Core Web Vitals auswirken, da sie Ressourcen verbrauchen, die erforderlich sind, um die Seite schnell zu laden und reaktionsschnell zu halten. 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 Auswertung und Ausführung von JavaScript im Tag Manager und in den Tags verwendet werden.
Largest Contentful Paint (LCP) ist während der kritischen Seitenladezeit anfällig für Bandbreitenkonflikte. Außerdem kann das Blockieren des Hauptthreads die LCP-Renderingzeit verzögern.
Der Cumulative Layout Shift (CLS) kann beeinträchtigt werden, wenn das Laden wichtiger Ressourcen vor dem ersten Rendering verzögert wird oder wenn Tag-Manager Inhalte in die Seite einfügen.
Interaction to Next Paint (INP) ist anfällig für CPU-Konflikte im Hauptthread. Wir haben einen Zusammenhang 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 benutzerdefinierten HTML-Tags. Anbieter-Tags variieren je nach den Funktionen, die sie ermöglichen.
Beachten Sie, dass die Verwendung eines Tags die Auswirkungen auf die Leistung stark beeinflusst. Pixel sind vor allem deshalb so leistungsstark, weil die Art dieses Tag-Typs strenge Einschränkungen für die Verwendung mit sich bringt. Benutzerdefinierte HTML-Tags sind nicht unbedingt immer schlecht für die Leistung, aber aufgrund der Freiheit, die sie Nutzern bieten, können sie leicht auf eine Weise missbraucht werden, die 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 sein, wenn Dutzende oder Hunderte von Tags auf derselben Seite verwendet werden.
Nicht alle Skripts sollten mit einem Tag-Manager geladen werden.
Tag-Manager sind in der Regel nicht die beste Methode, um Ressourcen zu laden, die unmittelbare visuelle oder funktionale Aspekte der Nutzererfahrung implementieren, z. B. Cookie-Hinweise, Hero-Bilder oder Websitefunktionen. Wenn Sie diese Ressourcen über einen Tag-Manager laden, verzögert sich in der Regel die Bereitstellung. Das ist nicht nutzerfreundlich und kann auch Messwerte wie LCP und CLS erhöhen.
Außerdem blockieren einige Nutzer Tag-Manager. Wenn Sie einen Tag-Manager verwenden, um UX-Funktionen zu implementieren, kann dies dazu führen, dass Ihre Website für einige Nutzer nicht richtig funktioniert.
Vorsicht bei benutzerdefinierten HTML-Tags
Benutzerdefinierte HTML-Tags gibt es schon seit vielen Jahren und sie werden auf den meisten Websites intensiv genutzt. Mit benutzerdefinierten HTML-Tags können Sie Ihren eigenen Code mit wenigen Einschränkungen eingeben. Trotz des Namens besteht der Hauptzweck dieses Tags darin, 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 erheblich. Wenn Sie die Leistung Ihrer Website messen, sollten Sie beachten, dass die meisten Tools die Leistungsauswirkungen eines benutzerdefinierten HTML-Tags dem Tag Manager zuordnen, der es 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.
- In den meisten Fällen muss der Browser, wenn ein Element in die Seite eingefügt wird, 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 auftritt, kann es zu Leistungsproblemen führen. Die Auswirkungen dieses Phänomens sind auf Geräten mit geringerer Leistung 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 einem Layout Shift führen. Dieses Phänomen ist nicht auf Tag-Manager beschränkt. 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 Vorgänge, die auch mit benutzerdefinierten HTML-Tags möglich sind. Sie basieren jedoch 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, ermöglichen sie es einem Poweruser, eine Vorlage zu erstellen, die auf Leistung ausgelegt ist. Weniger technisch versierte Nutzer können die Vorlage dann verwenden. Das ist oft sicherer, als vollen Zugriff auf benutzerdefiniertes HTML zu gewähren.
Aufgrund der strengeren Einschränkungen für benutzerdefinierte Vorlagen ist es viel unwahrscheinlicher, dass diese Tags Leistungs- oder Sicherheitsprobleme verursachen. Aus denselben Gründen sind benutzerdefinierte Vorlagen nicht für alle Anwendungsfälle geeignet.
Skripts richtig einfügen
Das Einfügen eines Scripts über einen Tag-Manager ist ein sehr häufiger Anwendungsfall. Am besten verwenden Sie dazu eine benutzerdefinierte Vorlage und die injectScript API.
Informationen zur Verwendung der injectScript API zum Konvertieren eines vorhandenen benutzerdefinierten HTML-Tags finden Sie unter Vorhandenes Tag konvertieren.
Wenn Sie ein benutzerdefiniertes HTML-Tag verwenden müssen, beachten Sie Folgendes:
- Bibliotheken und große Drittanbieterskripts sollten mit einem Skript-Tag (z. B.
<script src="external-scripts.js">) geladen werden, das eine externe Datei herunterlädt, anstatt den Inhalt des Skripts direkt in das Tag zu kopieren. Wenn Sie das<script>-Tag nicht verwenden, entfällt zwar ein separater Hin- und Rückflug zum Herunterladen des Skriptinhalts, aber die Containergröße erhöht sich und das Skript kann nicht separat vom Browser im Cache gespeichert werden. - Viele Anbieter empfehlen, ihr
<script>-Tag oben im<head>zu platzieren. Bei Skripts, die mit Tag Manager geladen werden, ist dies jedoch oft nicht erforderlich. In den meisten Fällen hat der Browser das Parsen des<head>bereits abgeschlossen, wenn der Tag-Manager ausgeführt wird.
Pixel verwenden
Manchmal können Drittanbieterskripte durch Bild- oder iFrame-Pixel ersetzt werden. Im Vergleich zu ihren skriptbasierten Gegenstücken unterstützen Pixel möglicherweise weniger Funktionen und werden daher oft als weniger bevorzugte Implementierung angesehen. Wenn Pixel jedoch in Tag-Managern verwendet werden, können sie dynamischer sein, da sie bei Triggern ausgelöst werden und verschiedene Variablen übergeben können.
Pixel sind die leistungsstärkste und sicherste Art von Tag, da nach dem Auslösen kein JavaScript ausgeführt wird. Pixel haben eine sehr kleine Ressourcengröße (weniger als 1 KB) und verursachen keine Layoutverschiebungen.
Weitere Informationen zur Unterstützung von Pixeln erhalten Sie von Ihrem Drittanbieter. Sie können auch versuchen, den Code auf ein <noscript>-Tag zu prüfen.
Wenn ein Anbieter Pixel unterstützt, fügt er das Pixel oft in das <noscript>-Tag ein.
Alternativen zu Pixeln
Pixel wurden vor allem deshalb so beliebt, weil sie früher eine der günstigsten und zuverlässigsten Methoden waren, um eine HTTP-Anfrage in Situationen zu stellen, 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 denselben Anwendungsfall konzipiert, aber wohl zuverlässiger als Pixel.
Es ist nichts dagegen einzuwenden, weiterhin Pixel zu verwenden. Sie werden gut unterstützt und haben nur minimale Auswirkungen auf die Leistung. Wenn Sie jedoch eigene Beacons erstellen, sollten Sie eine dieser APIs verwenden.
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: Es werden nur POST-Anfragen unterstützt und es können keine benutzerdefinierten Header festgelegt werden. Es 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. Sie wird verwendet, indem keepalive: true in die Parameter aufgenommen wird, 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 klingen, 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 benötigten Funktionen und die Browserunterstützung berücksichtigen. Die fetch() API ist wesentlich flexibler, allerdings wird keepalive von weniger Browsern unterstützt als sendBeacon().
Funktionsweise der Tags
Tags werden häufig gemäß den Anleitungen eines Drittanbieters erstellt. Wenn unklar ist, was der Code eines Anbieters bewirkt, fragen Sie jemanden, der sich damit auskennt. Eine zweite Meinung kann helfen, festzustellen, ob ein Tag das Potenzial hat, Leistungs- oder Sicherheitsprobleme zu verursachen.
Wir empfehlen, Tags im Tag Manager mit einem Inhaber zu kennzeichnen. Es kann leicht passieren, dass man vergisst, wer ein Tag besitzt. Das führt dann dazu, dass man sich nicht traut, es zu entfernen, weil man befürchtet, dass dadurch etwas kaputtgeht.
Trigger
Im Allgemeinen besteht die Optimierung von Tag-Triggern darin, Tags nicht öfter als nötig auszulösen 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. Die meisten Trigger sind zwar klein, aber die kumulative Wirkung kann sich summieren. Wenn Sie beispielsweise mehrere Klickereignisse oder Timer-Trigger haben, kann dies die Arbeitslast des Tag Managers erheblich erhöhen.
Geeignetes Triggerereignis auswählen
Die Auswirkungen eines Tags auf die Leistung können variieren. Im Allgemeinen gilt: Je früher ein Tag ausgelöst wird, desto stärker wirkt es sich auf die Leistung aus. Ressourcen sind beim ersten Seitenaufbau in der Regel eingeschränkt. Daher werden beim Laden oder Ausführen einer bestimmten Ressource (oder eines Tags) Ressourcen von anderen Elementen abgezogen.
Es ist zwar wichtig, für alle Tags geeignete Trigger auszuwählen, aber besonders wichtig ist dies für Tags, die große Ressourcen laden oder lange Scripts ausführen.
Tags können bei Seitenaufrufen (normalerweise Page load, bei DOM Ready, bei Window Loaded) oder basierend auf einem benutzerdefinierten Ereignis 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. In vielen Tags werden beispielsweise Seitenaufruf-Trigger verwendet. Die Zeit zwischen DOM Ready und Window Loaded kann jedoch lang sein, was es schwierig macht, den Zeitpunkt der Tag-Auslösung genau abzustimmen. Benutzerdefinierte Ereignisse können eine Lösung für dieses Problem sein.
Erstellen Sie zuerst einen benutzerdefinierten Ereignistrigger und aktualisieren Sie Ihre Tags, um diesen Trigger zu verwenden.
Wenn Sie den Trigger auslösen möchten, senden Sie das entsprechende Ereignis an die Datenschicht.
// Custom event trigger that fires after 2 seconds
setTimeout(() => {
dataLayer.push({
'event' : 'my-custom-event'
});
}, 2000);
Bestimmte Triggerbedingungen verwenden
Definieren Sie spezifische Triggerbedingungen, um zu vermeiden, dass Tags unnötig 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 eingebunden werden, um die Tag-Auslösung einzuschränken.
Tag Manager zum richtigen Zeitpunkt laden
Sie können die Leistung verbessern, indem Sie anpassen, wann der Tag Manager selbst geladen wird. Unabhängig von ihrer Konfiguration können Trigger erst ausgelöst werden, nachdem ein Tag Manager geladen wurde. Experimentieren Sie damit, wann Sie den Tag Manager laden, da dies eine ebenso große oder 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 in Tags selbst nützlich.
Wie Trigger fügen Variablen dem Tag Manager JavaScript-Code hinzu und können daher Leistungsprobleme verursachen. 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 benutzerdefiniertes JavaScript mit unbegrenzten Funktionen (und unbegrenzter Größe) enthalten.
Verwenden Sie Variablen so wenig wie möglich, da sie von Tag Manager kontinuierlich ausgewertet werden. Entfernen Sie alte Variablen, die nicht mehr verwendet werden, um sowohl die Größe des Tag Manager-Skripts als auch die Verarbeitungszeit zu reduzieren.
Tag-Verwaltung
Durch die effiziente Verwendung der Tags wird das Risiko von Leistungsproblemen verringert.
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 Datenschicht 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 zwar ohne die Datenschicht verwendet werden, wir empfehlen jedoch dringend, sie zu nutzen. In der Datenschicht werden die Daten, auf die Drittanbieterskripts zugreifen können, an einem einzigen Ort zusammengefasst. So erhalten Sie einen besseren Überblick über die Nutzung. Unter anderem können so redundante Variablenberechnungen und Skriptausführungen reduziert werden.
Mit einer Datenschicht können Sie steuern, auf welche Daten die Tags zugreifen, anstatt den vollständigen Zugriff auf JavaScript-Variablen oder das DOM zu gewähren.
Die Leistungsvorteile der Datenschicht sind möglicherweise nicht intuitiv, da die Aktualisierung der Datenschicht dazu führt, dass Google Tag Manager alle Containervariablen neu bewertet und möglicherweise Tags auslöst, was die Ausführung von JavaScript erfordert. Es ist zwar möglich, die Datenschicht falsch zu verwenden, aber wenn die Datenschicht die Ursache für Leistungsprobleme zu sein scheint, hat der Container selbst wahrscheinlich Leistungsprobleme. Die Datenebene macht diese Probleme deutlicher.
Doppelte und nicht verwendete Tags entfernen
Doppelte Tags können auftreten, wenn ein Tag im HTML-Markup einer Seite enthalten ist und zusätzlich über einen Tag-Manager eingefügt wird.
Nicht verwendete Tags sollten pausiert oder entfernt werden, anstatt sie über einen Ausnahmetrigger zu blockieren. 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, sollten Sie die Trigger und Variablen überprüfen, 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 Ablehnungslisten 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. Damit können Best Practices für die Leistung und andere Richtlinien durchgesetzt werden.
Zulassungs- und Ablehnungslisten werden über die Datenschicht konfiguriert.
window.dataLayer = [{
'gtm.allowlist': ['<id>', '<id>', ...],
'gtm.blocklist': ['customScripts']
}];
Sie können beispielsweise die Verwendung von benutzerdefinierten HTML-Tags, JavaScript-Variablen oder direktem DOM-Zugriff verhindern. Das bedeutet, dass nur Pixel und vordefinierte Tags mit Daten aus der Datenschicht verwendet werden können. Dies ist zwar restriktiv, kann aber zu einer leistungsfähigeren und sichereren Tag Manager-Implementierung führen.
Serverseitiges Tagging verwenden
Ein Wechsel zum serverseitigen Tagging ist besonders für größere Websites sinnvoll, die mehr Kontrolle über ihre Daten haben möchten. Beim serverseitigen Tagging wird der Anbietercode vom Client entfernt und die Verarbeitung vom Client auf den Server verlagert.
Wenn Sie beispielsweise clientseitiges Tagging verwenden, müssen Sie beim Senden von Daten an mehrere Analytics-Konten für jeden Endpunkt separate Anfragen initiieren. Beim serverseitigen Tagging wird vom Client eine einzelne Anfrage an den serverseitigen Container gesendet. Von dort werden die Daten an verschiedene Analytics-Konten weitergeleitet.
Serverseitiges Tagging funktioniert nur mit bestimmten Tags. Die Tag-Kompatibilität variiert je nach Anbieter.
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. In einem Tag Manager-Konto können mehrere Container verwaltet werden.
Verwenden Sie nur einen Container pro Seite.
Mehrere Container auf einer einzelnen Seite können zu erheblichen Leistungsproblemen führen, da sie zusätzlichen Aufwand und zusätzliche Skriptausführungen verursachen. Zumindest wird der Code des Kern-Tags selbst dupliziert. Da er als Teil des JavaScripts des Containers bereitgestellt wird, kann er nicht zwischen den Containern wiederverwendet werden.
Es ist selten, dass mehrere Container effektiv verwendet werden. Es gibt jedoch Fälle, in denen dies funktionieren kann, wenn es gut kontrolliert wird. Beispiel:
- Verwenden Sie einen kleineren Container, der früh geladen wird, und einen größeren Container, der später geladen wird, anstatt eines einzigen großen Containers.
- Verwendung eines eingeschränkten Containers für weniger technisch versierte Nutzer und eines weniger eingeschränkten, aber strenger kontrollierten Containers für komplexere Tags.
Wenn Sie mehrere Container pro Seite verwenden müssen, folgen Sie der Anleitung von Google Tag Manager 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 sich die Anzahl der verwendeten Container positiv oder negativ auf die Produktivität Ihres Workflows auswirken. Außerdem kann sie die Leistung beeinträchtigen.
Ein einzelner Container kann effektiv für mehrere Websites verwendet werden, wenn die Websites in Bezug auf Nutzung und Struktur ähnlich sind. Beispielsweise haben die mobilen Apps und Web-Apps einer Marke zwar ähnliche Funktionen, sind aber wahrscheinlich unterschiedlich strukturiert und werden daher effektiver über separate Container verwaltet.
Wenn Sie einen einzelnen Container zu oft wiederverwenden, kann das die Komplexität und Größe des Containers erhöhen, da komplexe Logik zum Verwalten von Tags und Triggern erforderlich ist.
Containergröße im Blick behalten
Die Größe eines Containers wird durch seine Tags, Trigger und Variablen bestimmt. Ein kleiner Container kann sich zwar immer noch negativ auf die Seitenleistung auswirken, bei einem großen Container ist dies jedoch 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 gepflegt und möglicherweise falsch verwendet wird.
In Google Tag Manager ist die Containergröße auf 300 KB beschränkt. Sie werden gewarnt, wenn die Containergröße 70 % des Größenlimits erreicht hat.
Die meisten Websites sollten versuchen, ihre Container kleiner als die Beschränkung zu halten. Zum Vergleich: Der durchschnittliche Website-Container ist etwa 50 KB groß. Die Google Tag Manager-Bibliothek ist komprimiert etwa 33 KB groß.
Containerversionen benennen
Eine Containerversion ist eine Momentaufnahme des Containerinhalts zu einem bestimmten Zeitpunkt. Ein aussagekräftiger Name und eine kurze Beschreibung der wichtigsten Änderungen können die Fehlerbehebung bei zukünftigen Leistungsproblemen erheblich erleichtern.
Workflows taggen
Es ist wichtig, Änderungen an Ihren Tags zu verwalten, damit sie sich nicht negativ auf die Seitenleistung auswirken.
Vor der Bereitstellung testen
Testen Sie Ihre Tags vor der Bereitstellung, um Probleme, Leistungsprobleme und andere Probleme zu erkennen, bevor sie ausgeliefert werden.
Beim Testen eines Tags sollten Sie Folgendes beachten:
- Funktioniert das Tag wie vorgesehen?
- Verursacht das Tag Layoutverschiebungen?
- Werden durch das Tag Ressourcen geladen? Wie groß sind diese Ressourcen?
- Löst das Tag ein Script mit langer Ausführungszeit aus?
Vorschaumodus
Im Vorschaumodus können Sie Tag-Änderungen auf Ihrer Website testen, ohne sie zuerst öffentlich bereitstellen zu müssen. Der Vorschaumodus enthält eine Debugging-Konsole, die Informationen zu Tags liefert.
Die Ausführungszeit von Google Tag Manager ist im Vorschaumodus etwas langsamer, da zusätzliche Informationen in der Debugging-Konsole angezeigt werden müssen. Daher wird davon abgeraten, die im Vorschaumodus erfassten Web Vitals-Messwerte mit den in der Produktion erfassten Messwerten zu vergleichen. Diese Abweichung sollte sich jedoch nicht auf das Ausführungsverhalten der Tags selbst auswirken.
Eigenständige Tests
Eine alternative Methode zum Testen von Tags besteht darin, eine leere Seite mit einem Container einzurichten, der nur ein Tag enthält – das Tag, das Sie testen möchten. Diese Testumgebung ist weniger realistisch und einige Probleme werden nicht erkannt (z. B. ob ein Tag Layoutverschiebungen verursacht). Es kann jedoch einfacher sein, die Auswirkungen des Tags auf die Skriptausführung zu isolieren und zu messen. Hier erfahren Sie, wie Telegraph diesen Isolationsansatz nutzt, um die Leistung von Drittanbietercode zu verbessern.
Tag-Leistung überwachen
Mit der Monitoring API von Google Tag Manager können Sie Informationen zur Ausführungszeit eines bestimmten Tags erfassen. Diese Informationen werden an einen Endpunkt Ihrer Wahl gemeldet.
Weitere Informationen finden Sie unter Google Tag Manager-Monitor erstellen.
Genehmigung für Containeränderungen anfordern
Eigener Code wird in der Regel vor der Bereitstellung überprüft und getestet. Behandeln Sie Ihre Tags gleich.
Eine Möglichkeit hierfür ist die Bestätigung in zwei Schritten, bei der Änderungen am Container von einem Administrator genehmigt werden müssen. Wenn Sie die Bestätigung in zwei Schritten nicht erzwingen, aber trotzdem über Änderungen informiert werden möchten, können Sie Containerbenachrichtigungen einrichten, um E-Mail-Benachrichtigungen zu ausgewählten Containerereignissen 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 Möglichkeit, diesen Trend umzukehren, ist die regelmäßige Überprüfung von Tags. Die ideale Häufigkeit hängt davon ab, wie oft die Tags Ihrer Website aktualisiert werden.
Wenn Sie jedes Tag so kennzeichnen, dass der Inhaber ersichtlich ist, können Sie leichter feststellen, wer für dieses Tag verantwortlich ist und ob es noch benötigt wird.
Denken Sie bei der Überprüfung von Tags daran, Trigger und Variablen zu bereinigen. Sie können auch die Ursache für Leistungsprobleme sein.
Weitere Informationen finden Sie unter Skripts von Drittanbietern im Griff behalten.