Mesurer la durée de l’événement Google Tag Manager

Google Tag Manager est un excellent outil. Oui, vous êtes venu jusqu’à cet article pour lire ce truisme. Il fonctionne également très bien, se chargeant à un rythme doux et rapide, même sur une connexion lente, grâce aux temps de réponse assez décents des serveurs Google. En plus de cela, la bibliothèque elle-même charge de manière asynchronece qui signifie que le téléchargement du conteneur n’interrompt pas le navigateur alors qu’il essaie de donner un sens à votre code HTML désordonné.

Cependant, une fois le conteneur téléchargé, le reste dépend de vous. Les déclencheurs que vous attachez aux balises, les variables que vous résolvez à la fois dans les balises et les déclencheurs, et toutes sortes de choses comme la priorité de déclenchement des balises peuvent potentiellement enliser votre site simplement parce qu’ils représentent tous des opérations JavaScript complexes. Le simple fait que le code soit exécuté dans le conteneur Google Tag Manager ne garantit pas des performances rapides. Le navigateur doit toujours l’exécuter ligne par ligne, en utilisant des requêtes asynchrones lorsque cela est possible (comme lorsqu’un appel est effectué vers le point de terminaison Google Analytics), mais également en s’appuyant sur des opérations assez coûteuses telles que l’insertion DOM.

Quoi qu’il en soit, étant l’expérimentateur que j’aspire à être (comment est-ce pour une déclaration circulaire), je voulais mesurer le temps qu’il faut pour que les événements GTM se résolvent. Voici le résultat :

Des trucs intéressants! Parmi les plus grands échantillons de synchronisation, c’est le plus basique des événements, gtm.js, qui prend le plus de temps à terminer ! 2,5 secondes en moyenne, ouf ! Voici les Tags de mon site qui se déclenchent gtm.js:

Il y a une balise de configuration de tracker, une petite surprise de code Konami, ainsi qu’un code pour mesurer le temps de rebond SERP sur mon site. Chacun d’eux a quelques dataLayer.push() méthodes exécutées, et la configuration du tracker charge le analytics.js bibliothèque, donc ce n’est pas comme si c’était un truc léger. Mais quand même, 2,5 secondes ? C’est toute une vie dans le temps d’Internet !

Quoi qu’il en soit, cette mesure a été assez révélatrice. C’est une bonne idée d’être conscient de ce qui se passe dans les coulisses. Même les opérations asynchrones peuvent nuire aux performances de la page, surtout si elles sont nombreuses à s’exécuter les unes après les autres. La raison en est que le load événement pour le window L’objet est retardé jusqu’à ce que la page et toutes ses ressources associées (par exemple, les scripts et les images) soient complètement chargées. Cela pourrait entraîner des problèmes avec des frameworks comme React, où de nombreuses opérations ne sont exécutées qu’après la window.onload l’événement a été envoyé dans le navigateur.

Permettez-moi de vous expliquer rapidement comment j’ai configuré cette mesure. Ce n’est pas une promenade dans le parc, et si vous voulez l’essayer vous-même, je exhorter à vous de le tester d’abord dans un environnement de mise en scène !

Hackons la couche de données

Pour que cela fonctionne, nous devons pirater la couche de données.

File d’attente musique inquiétante.

C’est vrai, nous devons faire ce que Google Tag Manager a déjà fait et détourner le dataLayer.push méthode pour l’écraser avec la nôtre.

Ainsi, le code suivant doit se retrouver sur votre modèle de page avant l’extrait de conteneur Google Tag Manager :

<script>   window.dataLayer = window.dataLayer || [];   var oldPush = window.dataLayer.push;   window.dataLayer.push = function() {     var e = [].slice.call(arguments, 0);     if (e[0].event &&          e[0].event !== "perfTime" &&         ["gtm.linkClick","gtm.formSubmit","gtm.timer"].indexOf(e[0].event) === -1 &&         document.readyState !== "complete") {       var t = (new Date).getTime(),           a = e[0].event;       e[0].eventStartTime = t,       e[0].eventCallback = function(c){         window.dataLayer.push(           {             event : "perfTime",             "perfEvent.event" : a,             "perfEvent.totalTime" : (new Date).getTime() - t,             "perfEvent.containerId" : c           }         )       }     }          oldPush.apply(window.dataLayer, e);    } </script>

Ouah. C’est une bête. Je ne vais pas vous expliquer cela ligne par ligne, mais voici comment cela fonctionne :

• Lorsqu’un dataLayer.push() arrive, ce code est d’abord exécuté.

• Il prend l’objet qui a été poussé, et s’il contient un 'event' key et si elle correspond à d’autres conditions, le code suivant est alors exécuté :

  • Une minuterie est démarrée (l’heure à laquelle l’exécution de l’événement a commencé) et stockée dans la clé eventStartTime

  • Les [eventCallback](/gtm-tips/hitcallback-eventcallback/) de cet objet est défini sur une fonction, qui pousse essentiellement une autre dataLayer objet, où une nouvelle minuterie calcule la différence entre les heures de début et de fin d’exécution de l’événement

  • Enfin, tout ce qui a été traité par ce script (que ce soit l’objet modifié ou le nouvel objet “perfTime”) est renvoyé à l’original dataLayer.push méthode, afin que GTM puisse le récupérer

Ah, c’est une bête. C’est peut-être plus facile si je vous montre un exemple. Lorsque ce code est en cours d’exécution (c’est-à-dire avant que la page ne soit complètement chargée), un simple dataLayer.push() comme ça:

window.dataLayer.push({   'event' : 'testing',   'someVar' : 'someVal' }); 

… est automatiquement transformé en :

window.dataLayer.push({   'event' : 'testing',   'someVar' : 'someVal',   'eventStartTime' : 1464890512708,   'eventCallback' : function(e) {...} }); 

Et quand toutes les balises qui se déclenchent 'event' : 'testing' ont terminé leur exécution, ce qui suit est, à nouveau, automatiquement poussé dans dataLayer:

window.dataLayer.push({   event : 'perfTime',   'perfEvent.event' : 'testing',   'perfEvent.totalTime' : 421,   'perfEvent.containerId' : 'GTM-W92WQQ' }); 

Alors mon petit hack mesure automatiquement le temps 'event' prend pour se terminer, tant que cela se produit avant le chargement de la page (car c’est la seule performance qui m’intéresse).

Au fait, vous n’avez pas vraiment besoin d’ajouter le eventStartTime dans l’objet, car vous avez déjà une variable de portée locale t qui stocke l’heure de début dans une fermeture. Cependant, je préfère le garder là au cas où je voudrais faire un débogage supplémentaire, car avec l’heure de début, je peux également créer un modèle de cascade à partir des temps de performance, pour voir dans quelle mesure l’exécution de ces différents événements de préchargement se chevauche.

REMARQUE!! Le script exclut automatiquement gtm.linkClick, gtm.timer et gtm.formSoumettrecar ceux-ci ont leurs propres utilisations pour eventCallback (les Attendre les balises option). De même, si vous utilisez déjà eventCallback avec certains événements, assurez-vous de les ajouter au tableau des événements exclus, sinon vous risquez de casser votre site !

N’oubliez pas de tester d’abord, s’il vous plaît!

La configuration dans GTM nécessite les éléments suivants :

1. UN Variable de couche de données nommé DLV – perfEvent.événementpointant vers le nom de la variable perfEvent.event

2. UN Variable de couche de données nommé DLV – perfEvent.totalTimepointant vers le nom de la variable perfEvent.totalTime

3. UN Déclencheur d’événement personnalisé nommé Événement – perfTimeavec le nom de l’événement défini sur perfTime

4. UN Balise d’analyse universelle de type Horaire (voir ci-dessous)

Voici la balise :

Et cette balise enverra vos hits en tant que User Timings, après quoi vous trouverez le rapport dans Google Analytics, sous Comportement -> Vitesse du site -> Timings utilisateur.

J’ai déjà donné une raclée à User Timings, car ils sont vraiment inutiles pour chronométrer TOUS les hits sur le site. Mais si vous êtes d’accord avec juste un échantillon, comme dans ce cas, ils fonctionnent très bien.

Résumé

Rappelez-vous les enfants, une bonne performance est bonne. De mauvaises performances peuvent tuer… l’expérience utilisateur de votre site, et d’autres choses aussi !

Peu importe comment vous voulez le faire, c’est une bonne idée de garder un œil sur les processus qui se déroulent avant la window objet a complètement chargé sur votre site. Vous pouvez utiliser User Timings pour mesurer toutes sortes de jalons importants, tels que le temps qu’il faut pour télécharger cette impressionnante bibliothèque de polices que vous avez payée des centaines de dollars. Ou combien de temps votre framework JavaScript préféré (rime avec “brasserie lay”) entrave les temps de chargement de vos pages. Ou combien de temps il vous faut pour atteindre la fin de mes articles. Eh bien, le dernier pourrait nécessiter un peu de créativité, mais je le laisse entre vos mains compétentes !