Le guide des balises HTML personnalisées pour Google Tag Manager

L’une des fonctionnalités les plus importantes de Google Tag Manager depuis la nuit des temps (en fait, fin 2012) est la Balise HTML personnalisée. Ce petit morceau de magie permet à Google Tag Manager injecter un élément HTML à la page. Depuis des temps immémoriaux (toujours fin 2012), cela nous a permis de transformer Google Tag Manager d’un prisonnier en bac à sable des modèles de balises natives en une solution de gestion de contenu côté client sans restriction.

Dans cet article, nous verrons comment la balise HTML personnalisée travauxet pourquoi vous pourriez être tenté de l’utiliser.

La balise HTML personnalisée

Comme son nom l’indique, la balise HTML personnalisée vous permet d’ajouter Éléments HTML à la page.

Tout ce que vous saisissez dans la balise HTML personnalisée sera interprété comme HTML.

Ajouter du contenu à la balise

Créons une balise HTML personnalisée qui ressemble à ceci :

<script>   console.log('Hello!'); </script>  <div>   <span>Hello!</span> </div>

Cette balise ajoute Trois éléments à la page : un <script> bloc compilé et exécuté en tant que JavaScript, un div bloc, et un <span> intégré dans le <div>.

Lorsque vous publiez le conteneur et jetez un coup d’œil à la source minifiée du conteneur JavaScript (comme nous le faisons tous), voici à quoi cela ressemble :

La raison pour laquelle votre balise magnifiquement formatée ressemble à ceci est que le code HTML est encodé – une étape judicieuse à suivre avant que les chaînes ne soient évaluées en éléments HTML.

Vous pourriez vous demander ce que enableIframeMode et enableEditJsMacroBehavior les drapeaux sont – eh bien, ce sont des fonctionnalités héritées qui ne sont plus visibles dans l’interface utilisateur. Si vous connaissez vos affaires, vous pouvez les faire apparaître dans l’interface des balises HTML personnalisées, mais elles ne feront rien.

Ainsi, vous avez maintenant créé une balise HTML personnalisée et vous avez vu comment la balise est ajoutée à la bibliothèque de conteneurs. Mais comment cela se termine-t-il sur la page ? Et où?

L’injection

Lorsqu’il est temps pour Google Tag Manager de “lancer” la balise HTML personnalisée, il effectue les mouvements suivants :

1. Un mannequin <div> est créé auquel la chaîne encodée représentant votre balise HTML personnalisée est ajoutée à l’aide de la .innerHTML biens.
2. Cela oblige le navigateur à analyser la chaîne encodée en HTML, ce qui fait que les balises que vous avez ajoutées à la balise HTML personnalisée se transforment en éléments HTML.
3. Un par un, ces éléments sont retirés du mannequin <div> et passé pour injection.
4. Lors de l’injection, chaque élément est ajouté en tant que dernier enfant du document.body élément.

Il y a quelques nuances à ce processus, comme la façon dont Google Tag Manager gère le onHtmlSuccess et onHtmlFailure rappels dans le séquençage des balises, et comment <script> les éléments sont dépouillés de tous les attributs personnalisés avant l’injection. Mais dans l’ensemble, c’est le processus.

Maintenant, cela signifie essentiellement que tout ce que vous tapez dans une balise HTML personnalisée est ajouté à la fin de body, quoi qu’il en soit au moment de l’injection. Typiquement, cela se traduit par : “Le bas de la page”mais ce n’est pas évident avec les mises en page fluides d’aujourd’hui.

Un extrêmement important chose à garder à l’esprit est que lorsque vous ajoutez un nouvel élément à la page, vous forcez un refusion du contenu. Fondamentalement, le navigateur doit recalculer les dimensions, le positionnement, les dispositions et les attributs des éléments précédant, entourant et imbriqués dans l’élément injecté.

Ce n’est pas une opération sans douleur. Chaque élément que vous ajoutez des composés au problème, et sur applications d’une seule page qui pourrait ne pas réinitialiser le DOM entre les transitions, vous pourriez vous retrouver avec des centaines d’éléments injectés sur la page, chacun nuisant aux performances par incréments exponentiels.

Nous y reviendrons dans le résumé, mais juste pour préfigurer la conclusion :

Évitez d’utiliser des balises HTML personnalisées à moins que cela ne soit absolument nécessaire.

Oui, je reconnais l’ironie d’un tel avertissement sur cet article particulier.

Scénarios pour les balises HTML personnalisées

Pourquoi utiliser des balises HTML personnalisées ? Pourquoi utiliser une solution de gestion de balises pour l’injection d’éléments ?

Grande question ! Et un pour lequel je n’ai pas de réponse définitive. Je dirais qu’une abondance de balises HTML personnalisées dans un conteneur est symptomatique d’une (ou plusieurs) des choses suivantes :

1. Vous avez des cas d’utilisation beaucoup trop compliqué pour les balises natives de GTM ou les modèles personnalisés à gérer.
2. Vous avez trop peu de connaissances sur GTM (ou JavaScript) pour savoir que certaines de vos balises HTML personnalisées pourraient être remplacées par des balises natives ou des modèles personnalisés.
3. Tu as un organisation rigideoù demander aux développeurs Web d’ajouter vos personnalisations directement aux modèles de page (ou à un autre code de site) n’est pas une option.
4. Vous avez trouvé un chose cool en ligne, et vous souhaitez rapidement en faire la preuve de concept avant de le transmettre aux développeurs Web pour une mise en œuvre appropriée.
5. Vous êtes ivre de pouvoir sur ce que vous pouvez faire sur votre site avec Google Tag Manager, et aucun mec chauve de Finlande ne vous empêchera de le faire.

C’est votre conteneur – vous êtes bien sûr libre de l’utiliser comme vous le souhaitez. Mais si les scénarios (2) et (3) vous disent quelque chose, je vous exhorte fortement à chercher à modifier le statu quo. Ignorer les subtilités de GTM et JavaScript peut être contre-productif pour les effets bénéfiques que ces technologies permettent. De même, travailler contre les contraintes définies par votre organisation entraînera plus de frictions à long terme et peut conduire à des structures de communication enflammées, un site de merde et une collecte de données instable.

Cela dit, explorons quelques-uns des scénarios où vous pourriez être tenté d’utiliser une balise HTML personnalisée !

Ajouter un élément à une position particulière sur la page

L’inconvénient de la balise HTML personnalisée est qu’elle injecte l’élément à la fin de <body>. Mais à quoi ça sert ? Si l’élément est un composant visuel (quelque chose qui devrait être affiché à l’écran), alors très probablement la fin de <body> est ne pas où vous voulez qu’il finisse.

Pour remédier à cela, vous devez utiliser Javascript et ses méthodes de manipulation DOM.

L’astuce consiste à trouver un élément qui est déjà sur la page, puis positionnez le nouvel élément relatif pour que.

Par exemple, disons que je veux ajouter un peu Sous-titre à cette page actuelle, de sorte qu’elle finit par ressembler à ceci :

Maintenant, si je crée une balise HTML personnalisée avec juste ceci :

<h3>It's really cool - I promise!</h3>

L’élément serait ajouté à la fin de <body> et n’aurait pas l’air très bien.

Donc, à la place, je dois créer un nouvel élément avec JavaScriptet alors positionner ce nouvel élément par rapport au titre de la page.

<script>   (function() {     // Create a new H3 element     var h3 = document.createElement('h3');          // Add the text content     h3.innerText = "It's really cool - I promise!";          // Get the reference to the current heading     var title = document.querySelector('h1');          // Inject the new element right after the H1     if (title) {       title.parentElement.insertBefore(h3, title.nextSibling);     }   })(); </script>

Le résultat final ? Vous pouvez le voir dans la capture d’écran ci-dessus.

Il y a une ironie subtile ici – vous utilisez une balise HTML personnalisée pour créer un élément (les <script>) que crée un élément (les <h3>). Oui, ce serait cool si vous pouviez spécifier dans une balise HTML personnalisée où l’élément est inséré. En fait, ce serait encore plus cool s’il y avait un modèle personnalisé qui vous permet de créer des éléments avec des options de positionnement. De cette façon, vous n’auriez pas du tout besoin de l’injection invasive de script de fin de corps !

Mais je m’égare.

Ajouter un script « aussi haut » que possible dans

Ceci est quelque peu lié au scénario précédent, mais il mérite son propre traitement en raison de la fréquence à laquelle le scénario émerge.

Parfois, un fournisseur vous demande de “Placez notre script comme HIGH UP dans <head> que possible ».

Ceci est indiqué car le fournisseur souhaite que son script se déclenche dès que possible sur la page. Plus un élément est élevé dans <head>plus tôt le navigateur l’analyse dans le cadre du rendu de la page.

Cependant, cet avantage est en grande partie perdu lors de l’utilisation de Google Tag Manager. Lorsque la bibliothèque Google Tag Manager est chargée, il est courant que l’analyse de <head> a déjà terminé, et le navigateur est bien en train de rendre le <body>. Pour cette raison, essayer d’injecter un script aussi haut dans <head> que possible n’a aucun sens, et est en fait préjudiciable au résultat final recherché.

Pourquoi? Parce que lorsque vous créez une balise HTML personnalisée qui crée ensuite un élément et l’injecte dans <head>le navigateur doit d’abord injecter la balise HTML personnalisée (atteinte des performances), puis il doit créer le nouvel élément (une autre atteinte des performances), et enfin il doit injecter le nouvel élément dans <head> (coup de performance).

Au lieu de cela – tout ce que vous avez à faire est d’ajouter le <script> directement à la balise HTML personnalisée. De cette façon, il sera inséré à la fin de <body>et le navigateur l’exécutera dès que possible.

Charger le JavaScript du fournisseur

En fait, poursuivons l’expérience de pensée du scénario précédent. Disons que vous faire avez un fournisseur dont vous souhaitez charger le JavaScript sur le site, et vous avez établi que tout ce que vous avez à faire est d’ajouter le <script> élément à la page avec une balise HTML personnalisée.

Mon ami. N’utilisez pas du tout de balise HTML personnalisée.

Au lieu de cela, créez un modèle de balise personnalisé qui utilise le injectScript API pour charger la bibliothèque.

Les modèles personnalisés sont optimisés pour injecter et charger le JavaScript, et ils introduisent un modèle d’autorisations et de politiques pour une injection sûre (r).

À l’avenir, ce sera la meilleure façon de procéder avec <script> injection. Cela ne vous aidera pas avec certains des autres scénarios, car le bac à sable JavaScript des modèles est extrêmement restrictif. Ainsi, si vous souhaitez ajouter des écouteurs d’événements personnalisés, par exemple, vous aurez toujours besoin de votre ancienne balise HTML personnalisée.

Modifier l’expérience utilisateur

L’une des choses que vous pourriez être tenté de faire avec les balises HTML personnalisées de Google Tag Manager est modifier l’expérience utilisateur. Cela pourrait être d’ajouter quelque chose comme un bannière de biscuitsou peut-être modifier le modes sur la page, ou peut-être en ajoutant un <iframe> qui charge un widget sophistiqué sur votre site de commerce électronique.

Je voudrais vous avertir des dangers de faire ces choses avec Google Tag Manager.

D’abord, Gestionnaire de balises Google peut être bloqué par les navigateurs (par exemple Brave) et par les bloqueurs de publicité/contenu. Il s’agit d’une tendance à la hausse (les protections de suivi des navigateurs réduisant le besoin de bloqueurs de publicités distincts).

La deuxième raison est que vous séparez la fonctionnalité et/ou l’expérience du site lui-même. Vous comptez très probablement sur le positionnement et la sélection d’éléments HTML spécifiques pour ancrer votre code personnalisé. Cependant, Google Tag Manager est découplé à partir des builds de votre site, et il est extrêmement périlleux de présumer que le site restera inchangé.

Ainsi, si même un seul sélecteur dans votre querySelector() changements d’argument sur le site, votre code personnalisé peut cesser de fonctionner ou, pire encore, casser quelque chose d’autre sur le site.

En plus de cela, il y a les raisons liées aux performances que j’ai mentionnées plus haut dans cet article. Chaque injection d’élément dynamique dégradera de manière exponentielle les performances de la page, entraînant des éléments gênants tels que le scintillement de vos éléments personnalisés, une dégradation de la qualité des données (lorsqu’un iframe que vous modifiez dynamiquement a le temps de se charger avant d’apporter les modifications), jusqu’à le bégaiement des pages, la lenteur qui décime l’expérience utilisateur, en particulier sur les applications d’une seule page.

Alors, s’il vous plaît, considérez ne pas utiliser Google Tag Manager comme système de gestion de contenu.

Résumé

Ce fut une brève incursion dans le monde magique des balises HTML personnalisées.

Si je pouvais parler au moi de 2012, je lui dirais de commencer à considérer les inconvénients des balises HTML personnalisées plus tôt, et d’arrêter de s’enivrer de la capacité infinie de Google Tag Manager pour l’injection de script et de penser plutôt à l’ensemble de l’organisation, à l’ensemble du site, et tout le contexte de l’environnement dans lequel GTM s’exécute, avant de prendre des décisions hasardeuses juste parce que.

Cela étant dit, les balises HTML personnalisées ont leurs cas d’utilisation aujourd’hui. En fait, la création d’un écouteur de clic avec une balise HTML personnalisée (document.addEventListener()) peut en fait être meilleur que de déclencher un code personnalisé avec les déclencheurs de clic de Google Tag Manager.

En effet, un déclencheur de clic déclenche la balise encore et encore (en l’injectant encore et encore) chaque fois que le déclencheur de clic est un succès. Alors que si vous créez votre propre petit écouteur de clic dans une balise HTML personnalisée et gérez la tâche répétitive dans le rappel, vous éviterez le chaos de l’injection.

Je garantis également fortement l’utilité des balises HTML personnalisées pour la construction de preuves de concepts. Vous pouvez rapidement essayer différentes expériences et conceptions, et vous pouvez publier les modifications pour un échantillon de vos visiteurs. Si vous êtes satisfait des résultats, vous pouvez alors proposer ces modifications à ajouter au code du site proprement dit.

Néanmoins, peut-être qu’un jour, j’espère, les modèles personnalisés rendront les balises HTML personnalisées obsolètes.

En tant que mots d’adieu, lors de l’utilisation de balises HTML personnalisées surtout pour injecter du code que vous avez trouvé en ligne, un célèbre proverbe russe n’est pas déplacé :

Faites confiance, mais vérifiez.

Si vous ne comprenez pas ce que fait le code, consultez votre sympathique développeur Web local et demandez-lui.