Publication : 29 juillet 2021
Les balises sont des extraits de code tiers insérés dans un site, généralement à l'aide d'un gestionnaire de balises. Les balises sont le plus souvent utilisées pour le marketing et l'analyse.
L'impact des balises et des gestionnaires de balises sur les performances varie considérablement d'un site à l'autre. Les gestionnaires de balises peuvent être comparés à une enveloppe : le gestionnaire de balises fournit un conteneur, mais c'est à vous de décider de ce que vous y mettez et de la façon dont vous l'utilisez.
Nous allons ici aborder les techniques d'optimisation des balises et des gestionnaires de balises pour les performances et les Core Web Vitals. Bien que ce document fasse référence à Google Tag Manager, de nombreuses idées abordées s'appliquent à d'autres gestionnaires de balises.
Impact sur les métriques Core Web Vitals
Les gestionnaires de balises peuvent souvent avoir un impact indirect sur vos Core Web Vitals en utilisant les ressources nécessaires pour charger rapidement votre page et la maintenir réactive. La bande passante peut être utilisée pour télécharger le code JavaScript du Tag Manager pour vos sites ou les appels ultérieurs qu'il effectue. Le temps CPU sur le thread principal peut être consacré à l'évaluation et à l'exécution du code JavaScript contenu dans le Tag Manager et les balises.
Le Largest Contentful Paint (LCP) est vulnérable aux conflits de bande passante pendant le temps de chargement critique de la page. De plus, le blocage du thread principal peut retarder le délai d'affichage du LCP.
Le Cumulative Layout Shift (CLS) peut être affecté, soit en retardant le chargement des ressources critiques avant le premier rendu, soit par l'injection de contenu dans la page par les gestionnaires de balises.
L'Interaction to Next Paint (INP) est susceptible d'entraîner des conflits de processeur sur le thread principal. Nous avons constaté une corrélation entre la taille des gestionnaires de balises et des scores INP plus faibles.
Choisir le bon type de balise
L'impact des balises sur les performances varie selon le type de balise. En règle générale, les balises d'image ("pixels") sont les plus performantes, suivies des modèles personnalisés et, enfin, des balises HTML personnalisées. Les balises de fournisseur varient en fonction des fonctionnalités qu'elles permettent d'utiliser.
N'oubliez pas que la façon dont vous utilisez une balise a une grande influence sur son impact sur les performances. Les "pixels" sont très performants, en grande partie parce que la nature de ce type de balise impose des restrictions strictes sur la façon dont ils peuvent être utilisés. Les balises HTML personnalisées ne sont pas nécessairement toujours mauvaises pour les performances, mais en raison du niveau de liberté qu'elles offrent aux utilisateurs, elles peuvent être facilement utilisées de manière incorrecte, ce qui nuit aux performances.
Lorsque vous réfléchissez aux balises, gardez à l'esprit l'échelle : l'impact d'une seule balise sur les performances peut être négligeable, mais il peut devenir important lorsque des dizaines ou des centaines de balises sont utilisées sur la même page.
Tous les scripts ne doivent pas être chargés avec un gestionnaire de balises
Les gestionnaires de balises ne sont généralement pas le meilleur moyen de charger des ressources qui implémentent des aspects visuels ou fonctionnels immédiats de l'expérience utilisateur, tels que les notifications de cookies, les images héros ou les fonctionnalités du site. L'utilisation d'un gestionnaire de balises pour charger ces ressources retarde généralement leur diffusion. Cela nuit à l'expérience utilisateur et peut également augmenter des métriques telles que le LCP et le CLS.
De plus, certains utilisateurs bloquent les gestionnaires de balises. L'utilisation d'un Tag Manager pour implémenter des fonctionnalités d'expérience utilisateur peut entraîner un dysfonctionnement de votre site Web pour certains de vos utilisateurs.
Faites attention aux balises HTML personnalisées
Les balises HTML personnalisées existent depuis de nombreuses années et sont largement utilisées sur la plupart des sites. Les balises HTML personnalisées vous permettent de saisir votre propre code avec peu de restrictions, car, malgré leur nom, l'utilisation principale de ces balises est d'ajouter des éléments <script> personnalisés à une page.
Les balises HTML personnalisées peuvent être utilisées de différentes manières, et leur impact sur les performances varie considérablement. Lorsque vous mesurez les performances de votre site, sachez que la plupart des outils attribuent l'impact d'une balise HTML personnalisée sur les performances au gestionnaire de balises qui l'a injectée, plutôt qu'à la balise elle-même.
Les balises HTML personnalisées peuvent insérer un élément dans la page environnante. L'insertion d'éléments dans la page peut être une source de problèmes de performances et, dans certains cas, entraîner des décalages de mise en page.
- Dans la plupart des cas, si un élément est inséré dans la page, le navigateur doit recalculer la taille et la position de chaque élément de la page. Ce processus est appelé mise en page. L'impact d'une seule mise en page sur les performances est minime, mais lorsqu'elle se produit de manière excessive, elle peut devenir une source de problèmes de performances. L'impact de ce phénomène est plus important sur les appareils bas de gamme et les pages comportant un grand nombre d'éléments DOM.
- Si un élément de page visible est inséré dans le DOM après que la zone environnante a déjà été affichée, cela peut entraîner un décalage de mise en page. Ce phénomène n'est pas propre aux Tag Managers. Toutefois, comme les balises se chargent généralement plus tard que les autres parties de la page, elles sont souvent insérées dans le DOM après l'affichage de la page environnante.
Utiliser des modèles personnalisés
Les modèles personnalisés sont compatibles avec certaines des opérations des balises HTML personnalisées, mais ils sont basés sur une version de JavaScript en bac à sable qui fournit des API pour les cas d'utilisation courants tels que l'injection de scripts et de pixels. Comme leur nom l'indique, ils permettent à un utilisateur expérimenté de créer un modèle en tenant compte des performances. Les utilisateurs moins techniques peuvent ensuite utiliser le modèle. Cette méthode est souvent plus sûre que de fournir un accès complet au code HTML personnalisé.
En raison des restrictions plus strictes imposées aux modèles personnalisés, ces balises sont beaucoup moins susceptibles de présenter des problèmes de performances ou de sécurité. Pour ces mêmes raisons, les modèles personnalisés ne fonctionnent pas pour tous les cas d'utilisation.
Injecter correctement les scripts
L'utilisation d'un Tag Manager pour injecter un script est un cas d'utilisation très courant. Pour ce faire, nous vous recommandons d'utiliser un modèle personnalisé et l'API injectScript.
Pour savoir comment utiliser l'API injectScript afin de convertir une balise HTML personnalisée existante, consultez Convertir une balise existante.
Si vous devez utiliser une balise HTML personnalisée, n'oubliez pas les points suivants :
- Les bibliothèques et les scripts tiers volumineux doivent être chargés avec un tag de script (par exemple,
<script src="external-scripts.js">) qui télécharge un fichier externe, plutôt que de copier-coller directement le contenu du script dans le tag. Bien que l'absence de la balise<script>élimine un aller-retour distinct pour télécharger le contenu du script, cette pratique augmente la taille du conteneur et empêche le navigateur de mettre en cache le script séparément. - De nombreux fournisseurs recommandent de placer leur balise
<script>en haut de la balise<head>. Toutefois, pour les scripts chargés avec Tag Manager, cela n'est souvent pas nécessaire. Dans la plupart des cas, le navigateur a déjà fini d'analyser le<head>au moment où le Tag Manager s'exécute.
Utiliser des pixels
Parfois, les scripts tiers peuvent être remplacés par des pixels d'image ou d'iFrame. Par rapport aux scripts, les pixels peuvent offrir moins de fonctionnalités. Ils sont donc souvent considérés comme une implémentation moins intéressante. Toutefois, lorsqu'ils sont utilisés dans des Tag Managers, les pixels peuvent être plus dynamiques, car ils peuvent se déclencher sur des déclencheurs et transmettre différentes variables.
Les pixels sont le type de balise le plus performant et le plus sécurisé, car aucune exécution JavaScript n'a lieu après leur déclenchement. Les pixels ont une taille de ressource très faible (moins de 1 Ko) et n'entraînent pas de décalage de mise en page.
Pour en savoir plus sur la compatibilité des pixels, contactez votre fournisseur tiers. Vous pouvez également essayer d'inspecter leur code pour trouver une balise <noscript>.
Si un fournisseur accepte les pixels, il les inclut souvent dans la balise <noscript>.
Alternatives aux pixels
Les pixels sont devenus populaires en grande partie parce qu'ils constituaient autrefois l'un des moyens les plus économiques et les plus fiables d'effectuer une requête HTTP dans les situations où la réponse du serveur n'est pas pertinente ( par exemple, lors de l'envoi de données à des fournisseurs d'analyse). Les API navigator.sendBeacon() et fetch() keepalive sont conçues pour répondre à ce même cas d'utilisation, mais elles sont sans doute plus fiables que les pixels.
Vous pouvez continuer à utiliser des pixels, car ils sont bien pris en charge et ont un impact minimal sur les performances. Toutefois, si vous créez vos propres balises, vous pouvez envisager d'utiliser l'une de ces API.
sendBeacon()
L'API navigator.sendBeacon() est conçue pour envoyer de petites quantités de données aux serveurs Web lorsque la réponse du serveur n'a pas d'importance.
const url = "https://example.com/analytics";
const data = JSON.stringify({
event: "checkout",
time: performance.now()
});
navigator.sendBeacon(url, data);
sendBeacon() dispose d'une API limitée : il n'est compatible qu'avec les requêtes POST et ne permet pas de définir des en-têtes personnalisés. Il est compatible avec tous les navigateurs récents.
API Fetch keepalive
keepalive est un indicateur qui permet d'utiliser l'API Fetch pour effectuer des requêtes non bloquantes, telles que des rapports d'événements et des analyses. Il est utilisé en incluant keepalive: true dans les paramètres transmis à fetch().
const url = "https://example.com/analytics";
const data = JSON.stringify({
event: "checkout",
time: performance.now()
});
fetch(url, {
method: 'POST',
body: data,
keepalive: true
});
Si fetch() keepalive et sendBeacon() semblent très similaires, c'est parce qu'ils le sont. En fait, dans les navigateurs Chromium, sendBeacon() est désormais basé sur fetch()
keepalive.
Lorsque vous choisissez entre fetch() keepalive et sendBeacon(), il est important de prendre en compte les fonctionnalités et la compatibilité avec les navigateurs dont vous avez besoin. L'API fetch() est beaucoup plus flexible. Toutefois, keepalive est compatible avec moins de navigateurs que sendBeacon().
Comprendre le rôle des balises
Les balises sont souvent créées en suivant les instructions fournies par un fournisseur tiers. Si vous ne savez pas à quoi sert le code d'un fournisseur, demandez à quelqu'un qui le sait. Obtenir un deuxième avis peut vous aider à déterminer si une balise est susceptible de créer des problèmes de performances ou de sécurité.
Nous vous recommandons d'ajouter un libellé aux balises avec un propriétaire dans le Tag Manager. Il est facile d'oublier qui est propriétaire d'une balise, ce qui peut faire craindre de la supprimer au cas où cela casserait quelque chose.
Déclencheurs
En règle générale, l'optimisation des déclencheurs de balises consiste à s'assurer de ne pas déclencher les balises plus que nécessaire et à choisir un déclencheur qui équilibre les besoins de l'entreprise et les coûts de performances.
Les déclencheurs sont du code JavaScript qui augmente la taille et le coût d'exécution du Tag Manager. Bien que la plupart des déclencheurs soient de petite taille, l'effet cumulé peut s'additionner. Par exemple, le fait d'avoir plusieurs événements de clic ou déclencheurs de minuteur peut augmenter considérablement la charge de travail du gestionnaire de balises.
Choisir un événement déclencheur approprié
L'impact d'une balise sur les performances peut varier. En général, plus une balise se déclenche tôt, plus elle a d'impact sur les performances. Les ressources sont généralement limitées lors du chargement de page initial. Par conséquent, le chargement ou l'exécution d'une ressource (ou d'une balise) particulière prive une autre ressource de ressources.
Bien qu'il soit important de choisir des déclencheurs appropriés pour toutes les balises, cela est particulièrement important pour les balises qui chargent des ressources volumineuses ou exécutent des scripts longs.
Les balises peuvent être déclenchées sur les pages vues (généralement Page load, sur DOM Ready, sur Window Loaded) ou en fonction d'un événement personnalisé. Pour éviter d'affecter le chargement de page, déclenchez les balises non essentielles après Window Loaded.
Utiliser des événements personnalisés
Utilisez des événements personnalisés pour activer des déclencheurs en réponse à des événements de page qui ne sont pas couverts par les déclencheurs intégrés de Google Tag Manager. Par exemple, de nombreuses balises utilisent des déclencheurs de vue de page. Toutefois, le délai entre DOM Ready et Window Loaded peut être long, ce qui complique l'ajustement du moment où une balise se déclenche. Les événements personnalisés peuvent être une solution à ce problème.
Commencez par créer un déclencheur d'événement personnalisé, puis mettez à jour vos balises pour qu'elles l'utilisent.
Pour déclencher le déclencheur, transmettez l'événement correspondant à la couche de données.
// Custom event trigger that fires after 2 seconds
setTimeout(() => {
dataLayer.push({
'event' : 'my-custom-event'
});
}, 2000);
Utiliser des conditions de déclenchement spécifiques
Définissez des conditions de déclenchement spécifiques pour éviter de déclencher des balises lorsque cela n'est pas nécessaire. L'un des moyens les plus simples et les plus efficaces d'y parvenir consiste à s'assurer qu'une balise ne se déclenche que sur les pages où elle est réellement utilisée.
Les variables intégrées peuvent être incorporées dans les conditions de déclenchement pour limiter le déclenchement des balises.
Charger votre Tag Manager au moment opportun
Vous pouvez améliorer les performances en ajustant le moment où le gestionnaire de balises se charge. Les déclencheurs, quelle que soit leur configuration, ne peuvent pas se déclencher tant qu'un gestionnaire de balises n'est pas chargé. Testez le moment où vous chargez le Tag Manager, car cela peut avoir un impact égal ou supérieur. Cette décision a un impact sur toutes les balises d'une page.
En chargeant le Tag Manager plus tard, vous pouvez éviter de futurs problèmes de performances, car cela empêche de charger une balise trop tôt par inadvertance.
Variables
Utilisez des variables pour lire les données de la page. Elles sont utiles dans les déclencheurs et dans les balises elles-mêmes.
Comme les déclencheurs, les variables ajoutent du code JavaScript au gestionnaire de balises et peuvent donc entraîner des problèmes de performances. Les variables peuvent être relativement petites, comme du code permettant de lire des parties de l'URL, des cookies, la couche de données ou le DOM. Ils peuvent également inclure du code JavaScript personnalisé, dont les capacités (et la taille) sont illimitées.
Limitez l'utilisation des variables au minimum, car elles sont continuellement évaluées par Tag Manager. Supprimez les anciennes variables qui ne sont plus utilisées afin de réduire la taille du script du Tag Manager et le temps de traitement qu'il utilise.
Gestion des balises
L'utilisation efficace des tags réduit le risque de problèmes de performances.
Utiliser la couche de données
La couche de données est un tableau d'objets JavaScript contenant des informations sur la page. Ces objets contiennent toutes les informations que vous souhaitez transmettre à Google Tag Manager.
La couche de données peut également être utilisée pour déclencher des balises.
// 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'});
Bien que Google Tag Manager puisse être utilisé sans la couche de données, nous vous recommandons vivement de l'utiliser. La couche de données regroupe les données accessibles par des scripts tiers en un seul endroit, ce qui permet de mieux voir comment elles sont utilisées. Cela peut notamment aider à réduire les calculs de variables et l'exécution de scripts redondants.
En utilisant une couche de données, vous pouvez contrôler les données auxquelles les balises ont accès, plutôt que de donner un accès complet aux variables JavaScript ou au DOM.
Les avantages de la couche de données en termes de performances ne sont pas forcément intuitifs, car la mise à jour de la couche de données entraîne la réévaluation de toutes les variables de conteneur par Google Tag Manager et peut déclencher des balises, ce qui implique l'exécution de JavaScript. Bien qu'il soit possible d'utiliser la couche de données de manière incorrecte, de manière générale, si la couche de données semble être à l'origine de problèmes de performances, le conteneur lui-même présente probablement des problèmes de performances. La couche de données rend ces problèmes plus apparents.
Supprimer les balises en double et inutilisées
Des balises en double peuvent se produire lorsqu'une balise est incluse dans le balisage HTML d'une page en plus d'être injectée via un gestionnaire de balises.
Les balises inutilisées doivent être mises en veille ou supprimées plutôt que bloquées à l'aide d'une exception de déclencheur. La mise en veille ou la suppression d'une balise supprime le code du conteneur, mais pas le blocage.
Une fois les balises inutilisées supprimées, examinez les déclencheurs et les variables pour déterminer s'ils peuvent également être supprimés.
Les balises mises en veille ont un impact sur la taille du conteneur, mais la charge utile totale est plus petite que lorsque les balises sont actives.
Utiliser des listes d'autorisation et de blocage
Utilisez des listes d'autorisation et de blocage pour configurer des restrictions très précises sur les balises, les déclencheurs et les variables autorisés sur une page. Cela peut être utilisé pour appliquer les bonnes pratiques de performances et d'autres règles.
Les listes d'autorisation et de refus sont configurées via la couche de données.
window.dataLayer = [{
'gtm.allowlist': ['<id>', '<id>', ...],
'gtm.blocklist': ['customScripts']
}];
Par exemple, vous pouvez empêcher l'utilisation de balises HTML personnalisées, de variables JavaScript ou d'un accès direct au DOM. Cela signifie que seuls les pixels et les balises prédéfinies peuvent être utilisés, avec les données de la couche de données. Bien que cela soit restrictif, cela peut permettre une implémentation plus performante et plus sécurisée du Tag Manager.
Envisager d'utiliser le taggage côté serveur
Il peut être intéressant de passer au taggage côté serveur, en particulier pour les sites plus importants qui souhaitent mieux contrôler leurs données. Le taggage côté serveur supprime le code du fournisseur du client et, par conséquent, décharge le traitement du client vers le serveur.
Par exemple, lorsque vous utilisez le taggage côté client, l'envoi de données à plusieurs comptes Analytics implique que le client lance des requêtes distinctes pour chaque point de terminaison. Avec le taggage côté serveur, le client envoie une seule requête au conteneur côté serveur, qui transmet ensuite ces données à différents comptes Analytics.
Sachez que le taggage côté serveur ne fonctionne qu'avec certaines balises. La compatibilité des tags varie selon le fournisseur.
Pour en savoir plus, consultez Présentation du taggage côté serveur.
Conteneurs
Les Tag Managers autorisent généralement plusieurs instances, souvent appelées conteneurs, dans leur configuration. Vous pouvez contrôler plusieurs conteneurs dans un même compte Tag Manager.
N'utilisez qu'un seul conteneur par page
La présence de plusieurs conteneurs sur une même page peut entraîner d'importants problèmes de performances, car cela entraîne une surcharge et une exécution de script supplémentaires. Au minimum, il duplique le code de la balise principale elle-même qui, étant fourni dans le code JavaScript du conteneur, ne peut pas être réutilisé entre les conteneurs.
Il est rare que plusieurs conteneurs soient utilisés efficacement. Toutefois, il existe des cas où cela peut fonctionner, si la situation est bien contrôlée. Exemple :
- Inclure un conteneur plus léger à "chargement anticipé" et un conteneur plus lourd à "chargement ultérieur", plutôt qu'un seul grand conteneur.
- Utiliser un conteneur restreint pour les utilisateurs moins techniques et un conteneur moins restreint, mais plus étroitement contrôlé, pour les balises plus complexes.
Si vous devez utiliser plusieurs conteneurs par page, suivez les instructions de Google Tag Manager pour configurer plusieurs conteneurs.
Utiliser des conteneurs distincts si nécessaire
Si vous utilisez un gestionnaire de balises pour plusieurs propriétés, comme une application Web et une application mobile, le nombre de conteneurs que vous utilisez peut améliorer ou nuire à la productivité de votre workflow. Cela peut également avoir un impact sur les performances.
Un même conteneur peut être utilisé efficacement sur plusieurs sites si ceux-ci sont similaires en termes d'utilisation et de structure. Par exemple, même si les applications Web et mobiles d'une marque peuvent remplir des fonctions similaires, il est probable qu'elles soient structurées différemment et qu'elles soient donc gérées plus efficacement via des conteneurs distincts.
La réutilisation d'un seul conteneur de manière trop large peut augmenter la complexité et la taille du conteneur en imposant une logique complexe pour gérer les balises et les déclencheurs.
Surveiller la taille des conteneurs
La taille d'un conteneur est déterminée par ses balises, ses déclencheurs et ses variables. Même si un petit conteneur peut avoir un impact négatif sur les performances de la page, un grand conteneur aura presque certainement un impact négatif.
La taille du conteneur ne doit pas être la métrique la plus importante lorsque vous optimisez l'utilisation de vos balises. Cependant, une taille de conteneur importante est souvent un signe d'avertissement indiquant qu'un conteneur n'est pas bien géré et qu'il est peut-être mal utilisé.
Google Tag Manager limite la taille des conteneurs à 300 Ko et vous avertit lorsque la taille du conteneur atteint 70 % de la limite.
La plupart des sites doivent s'efforcer de maintenir leurs conteneurs en dessous de cette limite. À titre de comparaison, la taille médiane d'un conteneur de site est d'environ 50 Ko. La bibliothèque Google Tag Manager fait environ 33 Ko une fois compressée.
Nommer les versions de vos conteneurs
Une version de conteneur est un instantané du contenu d'un conteneur à un moment précis. L'utilisation d'un nom explicite et l'inclusion d'une brève description des modifications importantes peuvent grandement faciliter le débogage des futurs problèmes de performances.
Ajouter des tags aux workflows
Il est important de gérer les modifications apportées à vos balises afin qu'elles n'aient pas d'impact négatif sur les performances de la page.
Tester avant le déploiement
Testez vos balises avant de les déployer pour détecter les problèmes, de performances ou autres, avant leur mise en production.
Voici quelques éléments à prendre en compte lorsque vous testez une balise :
- La balise fonctionne-t-elle correctement ?
- La balise entraîne-t-elle des décalages de mise en page ?
- La balise charge-t-elle des ressources ? Quelle est la taille de ces ressources ?
- La balise déclenche-t-elle un script de longue durée ?
Mode Aperçu
Le mode Aperçu vous permet de tester les modifications apportées aux balises sur votre site réel sans avoir à les déployer auprès du public au préalable. Le mode Aperçu inclut une console de débogage qui fournit des informations sur les balises.
Le temps d'exécution de Google Tag Manager est différent (légèrement plus lent) lorsqu'il est exécuté en mode Aperçu, en raison de la surcharge supplémentaire requise pour exposer les informations dans la console de débogage. Par conséquent, il n'est pas recommandé de comparer les mesures des signaux Web essentiels collectées en mode Aperçu à celles collectées en production. Toutefois, cet écart ne devrait pas affecter le comportement d'exécution des balises elles-mêmes.
Tests autonomes
Une autre approche pour tester les balises consiste à configurer une page vide contenant un conteneur avec une seule balise (celle que vous testez). Cette configuration de test est moins réaliste et ne détectera pas certains problèmes (par exemple, si une balise entraîne des décalages de mise en page). Toutefois, elle peut faciliter l'isolation et la mesure de l'impact de la balise sur des éléments tels que l'exécution du script. Découvrez comment Telegraph utilise cette approche d'isolation pour améliorer les performances du code tiers.
Surveiller les performances des balises
L'API Monitoring de Google Tag Manager permet de collecter des informations sur le temps d'exécution d'une balise spécifique. Ces informations sont transmises à un point de terminaison de votre choix.
Pour en savoir plus, consultez How to build a Google Tag Manager Monitor (Comment créer un outil de surveillance Google Tag Manager).
Exiger une approbation pour les modifications apportées au conteneur
Le code propriétaire est généralement examiné et testé avant d'être déployé. Faites de même pour vos balises.
Pour ce faire, vous pouvez ajouter la validation en deux étapes, qui nécessite l'approbation d'un administrateur pour les modifications apportées au conteneur. Si vous ne souhaitez pas exiger la validation en deux étapes, mais que vous voulez tout de même surveiller les modifications, vous pouvez configurer des notifications de conteneur pour recevoir des alertes par e-mail concernant les événements de conteneur de votre choix.
Auditer régulièrement l'utilisation des tags
L'un des défis liés à l'utilisation des tags est qu'ils ont tendance à s'accumuler au fil du temps : des tags sont ajoutés, mais ils sont rarement supprimés. Pour inverser cette tendance, vous pouvez auditer régulièrement les balises. La fréquence idéale dépend de la fréquence de mise à jour des balises de votre site.
L'ajout d'une étiquette à chaque tag pour que le propriétaire soit évident permet d'identifier plus facilement qui est responsable de ce tag et de déterminer s'il est toujours nécessaire.
Lorsque vous auditez des balises, n'oubliez pas de nettoyer les déclencheurs et les variables. Ils peuvent également être à l'origine de problèmes de performances.
Pour en savoir plus, consultez Garder le contrôle des scripts tiers.