Optimisation des performances
Stratégies pour améliorer les performances onsite de TagCommander.
La performance onsite d'un site web est l'un des KPI les plus importants pour le SEO. Par conséquent, de plus en plus d'entreprises s'intéressent à l'optimisation de la performance onsite via TagCommander. Cet article rassemble des sujets pour rendre TagCommander lui-même plus performant.
Réduire la taille des fichiers des Web Containers Commanders Act
Supprimer les propriétés Data Layer inutilisées
Chaque propriété Data Layer configurée dans les options de l'interface crée un petit bout de code JavaScript dans le Container pour initialiser la variable au cas où elle n'était pas présente dans le Data Layer onsite tc_vars. Supprimer les variables inutilisées/anciennes permettra donc de réduire un peu la taille du fichier Container (et, en bonus, d'améliorer la transparence de la configuration du Container).
Supprimer les variables internes inutilisées
Chaque variable interne configurée dans les options de l'interface est un extrait JavaScript, donc supprimer des variables internes permet de réduire la taille du fichier Container. Cela peut se faire en supprimant les variables internes inutilisées et aussi en spécifiant quelles variables sont utilisées dans quel Container. C'est particulièrement important pour les clients avec un <head> et <body> Container et les clients qui ont plusieurs Containers pour différents sites web.
Ne vous répétez pas
Parfois, la même fonctionnalité d'un Tag est dupliquée dans plusieurs Tags. Dans ces cas, il est possible d'économiser une bonne quantité de code JavaScript et de taille de fichier Container en refactorisant la fonctionnalité commune en une variable interne ou en un Tag commun. Par exemple, de nombreux Tags se composent de deux parties. Une partie charge une bibliothèque JavaScript externe du fournisseur et une partie envoie l'événement réel au fournisseur. Par défaut, le code qui charge la bibliothèque JavaScript est souvent dupliqué dans chaque événement. Donc extraire la première partie dans un base Tag permet de supprimer le JavaScript dupliqué.
Scinder les gros fichiers Container
Beaucoup de Tags sont déployés sur chaque page d'un site web même s'ils ne sont pas déclenchés. Par exemple, de nombreux fournisseurs ont des Tags séparés pour collecter des informations et un seul Tag qui est joué sur la page de confirmation. Par conséquent, il peut être judicieux de scinder le Container en deux parties — une pour les pages catalogue et une pour les pages entonnoir. Ainsi, les deux Containers ont une taille plus petite car ils n'incluent que les Tags pertinents pour leur partie du site.
Assurez-vous également d'implémenter des Tags uniquement dans le <head> Container si nécessaire car ces Tags ont généralement un impact plus important sur la performance onpage que les Tags dans le `<body>` Container.
Implémenter une configuration Hybrid Web Container
Une configuration hybride permet de déplacer l'impact sur la performance onsite vers l'infrastructure Server-Side Commanders Act.
Pour éviter tout impact négatif sur vos performances web, un web container ne doit jamais dépasser 500MB.
Rendre Commanders Act asynchrone
Charger le Container de façon asynchrone
De nombreux crawlers de vitesse de page onsite mesurent le temps jusqu'à l'événement navigateur onload. Donc dans le cas où l'équipe IT charge le Web Container de façon asynchrone sur l'événement onload il est possible de rendre le fichier Web Container invisible pour certaines métriques de vitesse de page. Ceci est généralement possible seulement pour <body> Containers car <head> Containers doivent être exécutés de façon synchrone pour les Tags A/B testing et personalization qui ont un impact sur le contenu visuel du site.
Les Tags dans des <body> Container qui utilisent le document.write (par ex. certaines solutions publicitaires) casseront le site si le Container est chargé de façon asynchrone. Ces Tags doivent être évités si un Container est installé de façon asynchrone.
Charger les Tags de façon asynchrone
JavaScript est pour la plupart un langage mono-thread, cela signifie que du JavaScript long à s'exécuter (comme un long processus dans une boucle) peut bloquer d'autres parties du JavaScript qui devraient s'exécuter immédiatement. Il est possible de placer du JavaScript long à s'exécuter sur un execute later with a lower priority stack en l'encapsulant dans un setTimeout avec un délai de 0 ms.
Cela doit être testé pour chaque Tag individuellement car certains pourraient ne pas être compatibles avec cette approche.
Mis à jour
Ce contenu vous a-t-il été utile ?