Améliorer la vitesse de chargement d'un site web grâce à Google Tag Manager côté serveur

L'optimisation de la vitesse de chargement des sites web était l'un des principaux avantages perçus par les spécialistes du marketing et les développeurs web lors du lancement de la première version de Google Tag Manager côté serveur. L'amélioration devait découler du fait que les scripts de suivi ne seraient plus codés en dur, mais ajoutés via Google Tag Manager. 

Dans cet article, nous vous montrerons en quoi déplacer vos balises du conteneur web GTM vers un conteneur serveur influence votre score GTM PageSpeed, ce que révèlent concrètement les données et quelle approche est la plus pertinente selon votre configuration.

Dès 2016, Google a établi que le temps de chargement idéal d'un site web est de 3 secondes. Pourtant, il faut en moyenne 22 secondes pour charger complètement une page sur mobile. 

Nous vivons à une époque où l'on utilise davantage les téléphones que les ordinateurs, et où les smartphones représentent plus de 50 % de l'ensemble du trafic Internet. Cependant, selon Google, les taux de conversion sur mobile restent inférieurs à ceux sur ordinateur. C'est pourquoi la vitesse de chargement d'un site web joue un rôle déterminant pour respecter les standards de performance.

Ce n'est un secret pour personne : les internautes s'attendent à une expérience rapide sur un site. Si la page de destination est trop lente, ils la fermeront ou abandonneront leur panier pour aller sur le site d'un concurrent. Aujourd'hui, dans un monde axé sur le mobile, créer des sites rapides à charger est capital. Les utilisateurs veulent pouvoir ouvrir rapidement n'importe quel blog pour lire des articles, acheter de nouveaux vêtements, consulter des avis d'hôtels, et bien plus encore.

D'après les recherches d'Amazon, un délai d'une seconde dans la réponse d'une page entraîne une baisse de 1 % des conversions. Pour l'entreprise, cela représente un manque à gagner annuel de 1,6 milliard de dollars.

Comme vous pouvez le constater, attendre le chargement de pages trop lourdes peut coûter très cher à n'importe quelle entreprise. 

Chaque balise ajoutée via Google Tag Manager s'exécute sous forme de JavaScript dans le navigateur de l'internaute. Chaque script doit être téléchargé, analysé et exécuté avant ou après le chargement de la page, ce qui prend du temps.

Toutes les configurations GTM ne se comportent pas de la même manière, et c'est de là que provient l'essentiel de la confusion. La façon dont le conteneur est déployé — web ou serveur — détermine si GTM alourdit le travail du navigateur ou s'il l'allège. Dans le conteneur web, chaque balise ajoutée (outils d'analyse, pixels publicitaires, widgets de chat, cartes de chaleur) correspond à un script qui se charge et s'exécute directement dans le navigateur du visiteur.

Chacun d'eux entre en concurrence pour les mêmes ressources limitées : le thread principal, la bande passante et le temps de rendu. Plus vous empilez les balises, plus l'impact de Google Tag Manager sur les performances s'aggrave, même si GTM est en soi un conteneur léger.

Le GTM côté serveur modifie l'endroit où s'exécutent les balises. Au lieu d'avoir des dizaines de scripts tiers s'exécutant côté client, votre conteneur serveur reçoit les données et les transmet depuis le cloud à vos plateformes de marketing et d'analyse. Le navigateur n'a plus qu'à communiquer avec votre propre serveur, et non avec une dizaine de domaines tiers différents. C'est la raison principale pour laquelle l'écart de PageSpeed avec Google Tag Manager entre une configuration web et serveur a tendance à être si important.

En 2020, Google a lancé un conteneur serveur pour Google Tag Manager et Tag Manager 360. Il permet aux annonceurs de déplacer les balises tierces de leur site vers un nouveau conteneur serveur hébergé sur des serveurs cloud. De cette manière, le site web se charge plus rapidement, le suivi gagne en précision et les données sont mieux sécurisées. Déplacer les balises vers le conteneur serveur peut aider à résoudre cette erreur Google PageSpeed : "Réduire l'impact du code tiers — Le code tiers a bloqué le thread principal pendant 550 ms".

Si vous déplacez les balises du conteneur web vers le conteneur serveur, elles seront chargées directement dans le conteneur serveur et non plus dans les navigateurs. La page se chargera ainsi plus vite, ce qui améliorera l'expérience utilisateur. Comme vous pouvez le constater, cela permet de réduire le temps de chargement, de renforcer la sécurité des données de vos clients et d'offrir davantage d'outils de gestion des données. C'est l'un des exemples les plus évidents de la manière dont Google Tag Manager côté serveur peut améliorer les performances d'un site web sans nuire à la précision du suivi.

Les balises présentes dans le conteneur serveur ont uniquement accès aux informations transmises au serveur. Elles ne peuvent pas accéder aux autres données que les internautes saisissent sur le site. Et comme ces balises se trouvent dans votre conteneur serveur, vous pouvez identifier quelles balises collectent des données et où ces informations sont envoyées.

Toutes les balises n'ont pas le même impact sur la vitesse des pages, et c'est une nuance essentielle à garder à l'esprit avant de supposer qu'une migration résoudra tous vos problèmes de performance. Un extrait de code d'analyse léger et un pixel lourd de reciblage publicitaire n'ont pas le même coût en temps de chargement, même si tous deux ne sont « qu'une simple balise ». Les balises ayant l'empreinte la plus importante sont généralement celles qui déclenchent plusieurs requêtes réseau, chargent des scripts supplémentaires ou s'exécutent à chaque chargement de page plutôt que lors d'événements spécifiques.

Le moyen le plus fiable de vous en rendre compte par vous-même est de consulter votre rapport PageSpeed Insights pour Google Tag Manager avant et après une migration, en comparant directement la section consacrée au code tiers.

Pour cette expérience, j'ai utilisé un site de démonstration et comparé les résultats de Google PageSpeed lorsque les balises étaient ajoutées via le conteneur web GTM par rapport au conteneur serveur GTM. Toutes les balises n'ont pas le même impact sur Google PageSpeed. Dans le cadre de ce test, j'ai choisi les balises les plus populaires utilisées par mon client et pouvant être déplacées vers le conteneur serveur : Facebook, Bing et Active Campaign.

Le conteneur serveur GTM dispose de balises natives pour GA4. Vous trouverez ici des informations détaillées sur la configuration du suivi GA4 à l'aide d'un conteneur GTM côté serveur. Nous avons également créé un modèle personnalisé pour vous aider à migrer le pixel Facebook vers l'environnement serveur. 

Voici ci-dessous les résultats du Google Speed Test. Google PageSpeed a affiché un score de 95 points sur mobile et de 100 sur ordinateur. 

Nous avons ces balises installées sur le conteneur serveur : GA4, Facebook (suivi de base et des conversions), Hubspot et la balise Klaviyo.

Lorsque nous avons déplacé le pixel vers le conteneur Web, les résultats Google PageSpeed ont diminué à 56 points. 

Si vous déplacez des balises vers le conteneur serveur de Google Tag Manager, cela accélérera votre site. L'ampleur de cet impact dépendra des balises que vous utilisez. Dans ce test, les balises les plus populaires auprès des clients (GA4, Facebook et Active Campaign ) ont montré une différence nette et mesurable une fois passées côté serveur.