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. C’est pourquoi de plus en plus d’entreprises s’intéressent à l’optimisation des performances 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 inutilisées du Data Layer
Chaque propriété du Data Layer configurée dans les options de l’interface crée un peu 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. La suppression des variables inutilisées/anciennes permettra donc de rendre le fichier du Container un peu plus petit (et, en prime, d’améliorer aussi 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 de JavaScript, donc la suppression des variables internes permet de réduire la taille du fichier du Container. Cela peut se faire en supprimant les variables internes inutilisées et aussi en indiquant 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 réduire la taille du fichier du Container en refactorisant la fonctionnalité commune dans une variable interne ou dans 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 Tag de base permet de supprimer le JavaScript dupliqué.
Fractionner les grands fichiers du Container
De nombreux 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 diffusé sur la page de confirmation. Il peut donc être judicieux de diviser le Container en deux parties — une pour les pages catalogue et une pour les pages de tunnel de conversion. Ainsi, les deux Containers ont une taille plus réduite puisqu’ils ne contiennent que les Tags pertinents pour leur partie du site web.
Veillez également à n’implémenter des Tags dans <head> le Container que si nécessaire, car ces Tags ont généralement un impact plus important sur les performances onpage que les Tags dans le Container `<body>`.
Mettre en place une architecture hybride de Web Container
Une configuration hybride permet de transférer l’impact sur les performances onsite vers l’infrastructure server-side de Commanders Act.
Pour éviter tout impact négatif sur les performances de votre site web, un web container ne devrait jamais dépasser 500MB.
Rendre Commanders Act asynchrone
Charger le Container de manière asynchrone
De nombreux crawlers de vitesse de page onsite mesurent le temps jusqu’à l’événement du navigateur onload. Donc, si l’équipe IT charge le Web Container de manière asynchrone sur l’ onload événement, il est possible de rendre le fichier du Web Container invisible pour certains indicateurs de vitesse de page. Cela n’est généralement possible que pour <body> les Containers, car <head> les Containers doivent être exécutés de manière synchrone pour les Tags de test A/B et de personnalisation qui ont un impact sur le contenu visuel du site web.
Les Tags dans un <body> Container asynchrone qui utilisent document.write (par exemple certaines solutions publicitaires) casseront le site web si le Container est chargé de manière asynchrone. Ces Tags doivent être évités dans le cas où un Container est installé de manière asynchrone.
Charger les Tags de manière asynchrone
JavaScript est en grande partie un langage à thread unique, cela signifie qu’un JavaScript de longue durée (comme un long processus dans une boucle) peut bloquer d’autres parties du JavaScript qui devraient être exécutées immédiatement. Il est possible de mettre un JavaScript de longue durée dans un stack d’exécution ultérieure avec une priorité plus faible en l’enveloppant dans un setTimeout avec un délai de 0 ms.
Cela doit être testé avec chaque Tag individuel, car certains pourraient ne pas être compatibles avec cette approche.
Mis à jour
Ce contenu vous a-t-il été utile ?