Get best of the week

Guide des balises HTML personnalisées pour Google Tag Manager par Simo Ahava

Fin janvier, Simo Ahava a publié sur son blog un avis sur la possibilité d'utiliser des balises HTML personnalisées dans Google Tag Manager. Les balises HTML personnalisées offrent de nombreuses possibilités de modifier le contenu du site, mais vous devez être très prudent - les fonctionnalités des balises et leur traitement comportent de grands risques. Timur Ledenyov, analyste chez MediaGuru, a traduit cette critique utile pour vous.

Pendant un certain temps (depuis la fin de 2012), l'une des options GTM les plus importantes a été la balise HTML personnalisée. Cet outil magique permet à GTM d'ajouter un élément HTML à une page de site Web. Depuis 2012, Google Tag Manager est passé d'un environnement isolé avec des modèles de balises personnalisés à une solution de gestion de contenu côté client illimitée.

Dans l'article, nous examinerons les principes de la balise HTML personnalisée et les possibilités de son application.

Remplissage de balise HTML personnalisé


Comme son nom l'indique, la balise HTML personnalisée vous permet de placer des éléments HTML sur la page du site. Créons-le:



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

<div>
  <span>Hello!</span>
</div>

Cette balise ajoute trois éléments à la page:

  • <script>, qui est compilé et exécuté en JavaScript;
  • bloc div;
  • <span>inclus dans <div>

Lorsque vous publiez un conteneur et regardez la source minimisée du conteneur JavaScript, cela ressemble à ceci:



votre balise magnifiquement formée ressemble à ceci parce que le HTML est codé, et c'est une étape intelligente avant de définir des chaînes comme éléments HTML.

Les indicateurs enableIframeMode et enableEditJsMacroBehavior sont les anciennes fonctionnalités qui ne sont plus visibles dans l'interface utilisateur. Vous pouvez les rendre visibles dans l'interface de balise HTML personnalisée si vous savez comment. Mais cela n'affectera rien.

Vous avez donc créé une balise HTML personnalisée et vu comment elle est ajoutée au conteneur. Mais que se passe-t-il alors sur la page, et où exactement?

Injection


Lorsque la balise HTML personnalisée se déclenche dans Google Tag Manager, le mécanisme suivant démarre:

  1. Un mannequin est créé <div>, auquel, à l'aide de l'attribut .innerHTML, une chaîne codée est ajoutée représentant votre balise HTML personnalisée.
  2. Cela oblige le navigateur à traiter la chaîne encodée en HTML, de sorte que les balises ajoutées au HTML personnalisé sont converties en éléments HTML.
  3. Un par un, ces éléments sont retirés de <div>et injectés.
  4. Ensuite, chaque élément est ajouté en tant que dernier élément enfant document.body.

Il y a quelques nuances dans ce processus:

  • Comment Google Tag Manager interagit avec onHtmlSuccess et onHtmlFailure dans la file d'attente
  • comment les éléments <script>sont effacés de tous les attributs utilisateur avant l'injection.

Qu'est-ce que ça veut dire? Tout ce que vous entrez dans la balise HTML personnalisée est ajouté à la fin du corps, quel qu'il soit au moment de l'injection. Habituellement, ils signifient le pied de page, mais ce n'est pas nécessaire, compte tenu des mises en page modernes.



Important: lorsque vous ajoutez un nouvel élément à la page, vous commencez à réorganiser le contenu. En règle générale, le navigateur doit recalculer les tailles, le positionnement, la disposition et les attributs des éléments; précédant, entourant ou imbriqué dans un élément incorporé.

Ce n'est pas si facile. Chaque élément que vous ajoutez aggrave le problème. Et dans les applications d'une seule page, qui peuvent ne pas réinitialiser le DOM entre les transitions, vous pouvez observer des centaines de ces éléments sur une seule page, chacun détériorant de plus en plus les performances. Nous y reviendrons en conclusion, mais avant la conclusion, je dirai:

Évitez d'utiliser des balises HTML personnalisées sans besoin évident.

J'avoue, un tel avertissement pour l'article n'est pas sans ironie.

Scripts de script HTML personnalisés


Pourquoi utiliser ces balises et appliquer une solution de gestion de balises pour injecter un élément? Une excellente question pour laquelle je n'ai pas de réponse rapide et définitive.

Je peux dire qu'un grand nombre de HTML personnalisé dans le conteneur peut parler de l'une des situations suivantes:

  1. Vous êtes confronté à un cas trop compliqué pour lequel les balises GTM standard ou les modèles personnalisés ne conviennent pas.
  2. Vous êtes nouveau sur GTM (ou JavaScript) et vous ne comprenez pas que vos balises HTML personnalisées peuvent être remplacées par des balises standard ou des modèles personnalisés.
  3. , -, .
  4. , - .
  5. , Google Tag Manager, .

Ceci est votre conteneur, et bien sûr, vous avez le droit de l'utiliser comme bon vous semble. Mais si les scénarios 2 et 3 apparaissent, je vous recommande fortement d'apporter des modifications au statu quo. Ignorer la complexité de GTM et JavaScript peut interférer avec les effets positifs que ces technologies ouvrent. Un travail contraire aux restrictions établies dans votre entreprise à long terme entraînera également des désaccords et entraînera une communication perturbée, un site terrible et un stockage non fiable des informations.

Examinons quelques scénarios dans lesquels vous voudrez probablement essayer des balises HTML personnalisées.

Ajout d'un élément à un emplacement spécifique sur la page


L'inconvénient de la balise HTML personnalisée est qu'elle incorpore l'élément à la fin <body>. Pourquoi? Si l'élément est un composant visuel (c'est-à-dire qu'il devrait être affiché à l'écran), il est fort probable que la fin <body>ne soit pas l'endroit où vous aimeriez le voir. Pour contourner ce problème, 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 et à placer un nouvel élément par rapport à celle-ci.

Par exemple, je veux ajouter une petite sous - rubrique de la page pour la faire ressembler à ceci:



Maintenant, si vous créez un HTML personnalisé comme suit: <h3> It's really cool - I promise!</h3>, l'élément est ajouté à la fin <body>et ne sera pas l' air très bien.

Au lieu de cela, j'ai besoinCréez un nouvel élément à l'aide de JavaScript , puis positionnez-le par rapport au titre de la page.

<script>
  (function() {
    //    <h3> 
    var h3 = document.createElement('h3');
    
    //  
    h3.innerText = "It's really cool - I promise!";
    
    //     <h1>
    var title = document.querySelector('h1');
    
    //      <h1>
    if (title) {
      title.parentElement.insertBefore(h3, title.nextSibling);
    }
  })();
</script>

Le résultat final que vous voyez dans la capture d'écran ci-dessus.

C'est une ironie subtile - vous utilisez un HTML personnalisé pour créer un élément ( <script>) qui créera un autre élément ( <h3>). Oui, ce serait formidable si vous pouviez définir en HTML personnalisé où l'élément sera situé. En fait, ce serait encore plus cool s'il y avait un modèle personnalisé qui vous permet de créer un élément avec la possibilité de sélectionner un emplacement pour l'élément. Ainsi, vous n'avez pas du tout besoin d'injecter le script à la fin du code! Mais nous étions distraits.

Placer le script le <head>plus haut possible


Cela est en partie dû au scénario précédent, mais il mérite une attention particulière en fonction de la fréquence à laquelle cette situation se produit. Parfois, on vous demande: "Placez le script COMME AU-DESSUS <head>."

Vous avez donc besoin que le script s'exécute sur la page le plus tôt possible. Plus l'élément est élevé <head>, plus le navigateur le traitera rapidement dans le cadre de la page affichée.

Mais cet avantage est perdu lors de l'utilisation de Google Tag Manager. Habituellement, lorsque la bibliothèque GTM est chargée, le traitement <head>est déjà terminé et le navigateur effectue un rendu avec might et main <body>. Pour cette raison, essayer d'ajouter un script <head>aussi haut que possible n'a aucun sens et ne fait que nuire au résultat final.

Pourquoi? Lorsque vous avez créé du HTML personnalisé, il forme un élément et l'intègre dans<head>. Tout d'abord, le navigateur doit ajouter du HTML personnalisé (hit de performance), puis créer un nouvel élément (un autre hit de performance) et enfin ajouter un nouvel élément à <head>(hit de performance).


Au lieu de cela, vous devez ajouter du <script>HTML directement à Custom. Avec cette méthode, il sera ajouté à la fin <body>et le navigateur l'exécutera le plus rapidement possible.

Téléchargement de code JavaScript tiers


Continuons l'expérience du scénario précédent. Supposons que vous ayez un développeur tiers dont vous souhaitez télécharger le code JavaScript sur le site. Et vous vous êtes rendu compte que vous n'avez qu'à ajouter un élément <script>à la page en utilisant du HTML personnalisé.

Dans ce cas, vous n'avez pas du tout besoin d'utiliser du HTML personnalisé.

À la place, créez un modèle personnalisé qui utilise l'API injectScript pour charger la bibliothèque.

Les modèles personnalisés sont optimisés pour l'injection et le chargement JavaScript, et ils offrent une autorisation et un modèle de stratégie pour une injection sûre (plus sécurisée).



À l'avenir, ce sera le meilleur moyen de mettre en œuvre<script>. Cela ne vous aidera pas avec d'autres scripts, car l'ensemble standard de modèles JavaScript est assez limité. Par conséquent, si vous souhaitez ajouter, par exemple, un écouteur d'événements personnalisé, vous aurez besoin d'une balise HTML personnalisée.

Changer ux


L'une des choses que vous voudrez faire avec le HTML personnalisé est la modification de l'UX (expérience utilisateur). Pour ce faire, vous pouvez utiliser quelque chose comme une bannière de cookie, il est possible de modifier les styles sur la page ou de l'ajouter <iframe>, ce qui charge un widget pratique pour votre site de commerce électronique.

Je voudrais vous mettre en garde contre les risques liés à tout cela avec Google Tag Manager.

  1. (, Brave) / GTM. ( , ).
  2. / , . , HTML . Google Tag Manager , , , . querySelector() , – - .
  3. À tout cela s'ajoutent les raisons liées aux performances que j'ai mentionnées ci-dessus. L'ajout de chaque élément dynamique dans l'ordre croissant dégradera les performances de la page, ce qui entraînera des choses ennuyeuses: vos éléments personnalisés commenceront à apparaître et à disparaître; la qualité des données se détériorera (lorsque l'iframe, que vous modifiez dynamiquement, a le temps avant d'apporter des modifications) jusqu'à des retards et des blocages de pages, en particulier sur les sites d'une seule page.

Par conséquent, veuillez ne pas considérer l'utilisation de Google Tag Manager comme système de gestion de contenu.

résultats


Il s'agissait d'un bref aperçu des fonctionnalités des balises HTML personnalisées.

Si je pouvais me parler en 2012, je me conseillerais de considérer les défauts des balises HTML personnalisées le plus tôt possible et de cesser de me faire des illusions sur les possibilités infinies de Google Tag Manager pour ajouter des scripts. Mais plutôt, réfléchir de manière complexe - sur l'organisation, sur le site dans son ensemble et sur le contexte de l'environnement dans lequel GTM travaille - avant de prendre des décisions risquées.

Cependant, il existe aujourd'hui des applications pour HTML personnalisé. La création d'un écouteur de clics à l'aide de la balise HTML personnalisée (document.addEventListener ()) peut être plus avantageuse que l'exécution d'un type de code personnalisé à l'aide de déclencheurs GTM.


Cela est dû au fait que le déclencheur de clic exécutera la balise encore et encore (l'injectant encore et encore) chaque fois qu'il se déclenche. Si vous créez votre écouteur de clics dans une balise HTML personnalisée et traitez une tâche répétitive avec celle-ci, vous éviterez toute confusion lors de l'implémentation.

Je garantis également vigoureusement la commodité du HTML personnalisé dans la prise en charge des hypothèses. Vous pouvez rapidement essayer une nouvelle conception ou fonctionnalité en publiant des modifications sur un échantillon spécifique de visiteurs. Si les résultats sont satisfaisants, il sera possible de proposer ces modifications pour inclusion dans le code du site principal.

Cependant, j'espère qu'un jour les modèles personnalisés remplaceront les balises HTML personnalisées.

En guise de mot d'adieu pour ceux qui utilisent des balises HTML personnalisées, en particulier pour ceux qui veulent ajouter du code trouvé sur le réseau, le célèbre proverbe russe est pratique: faites
confiance, mais vérifiez.

Si vous ne savez pas ce que fait le code, consultez un développeur Web familier.

More articles:


All Articles