Oui, Google Tag Manager ralentit votre site. On lit partout que l’outil est léger et que seules les balises qu’on y ajoute pèsent. La seconde moitié de la phrase est vraie. La première ne l’est plus.
Ce que pèse Google Tag Manager avant la première balise
Tag Manager est un conteneur. Votre équipe marketing ou votre agence y range ses outils (Google Analytics, pixels publicitaires, carte de chaleur, clavardage) sans demander une modification au développeur à chaque campagne. C’est pratique, et c’est pour ça que nous le configurons sur les sites que nous livrons.
Ce conteneur est un fichier JavaScript que chaque visiteur télécharge. Nous avons mesuré son poids tel que les serveurs de Google l’envoient, à côté de quelques scripts qu’on y charge souvent :
| Fichier | Transféré (compressé) | Code à exécuter |
|---|---|---|
| Conteneur Tag Manager vide, sans aucune balise | 90 Ko | 245 Ko |
| Conteneurs de quatre sites québécois connus | 145 à 195 Ko | 440 à 615 Ko |
| Google Analytics 4 (gtag.js) | 155 Ko | 445 Ko |
| Pixel Meta, avant sa configuration | 115 Ko | 435 Ko |
| Tout le JavaScript de notre site, avant consentement | 35 Ko | 115 Ko |
En 2022, un guide de web.dev, le site où Google documente la performance web, estimait la bibliothèque à environ 33 Ko compressés. Elle a presque triplé depuis. Un conteneur vide pèse aujourd’hui plus de deux fois tout le JavaScript de notre site.
Le transfert n’est que la moitié du coût. Le navigateur doit ensuite lire et exécuter ce code. Sur un ordinateur récent, personne ne le remarque. Sur un téléphone d’entrée de gamme, 600 Ko de JavaScript, ça se sent.
Les balises coûtent plus cher que le conteneur
Chaque balise ajoutée dans Tag Manager télécharge son propre script. Additionnez un conteneur réel, Google Analytics 4 et le pixel Meta : plus de 400 Ko compressés, avant la moindre carte de chaleur ou fenêtre de clavardage. Douze fois notre site.
Le pire n’est pas le chargement. Ces scripts occupent le processeur du téléphone au moment où le visiteur essaie de toucher un menu ou un bouton, et la page tarde à réagir. Google mesure ce délai avec l’INP (Interaction to Next Paint), l’un des trois Core Web Vitals. Les auteurs du guide de web.dev disent avoir observé un lien entre la taille des conteneurs et de moins bons scores d’INP.
Et un conteneur ne maigrit jamais tout seul. Il finit comme la petite boîte à l’entrée de la maison : tout le monde y dépose quelque chose, personne ne fait le tri. Le pixel d’une campagne terminée il y a deux ans. L’outil d’une agence qui ne travaille plus avec vous. Une balise d’essai que personne n’a retirée. Le même guide le constate : les balises s’ajoutent, elles se suppriment rarement.
Le consentement accélère aussi votre site
La Loi 25 demande d’informer le visiteur avant d’utiliser une technologie qui permet de l’identifier ou de le profiler, et de lui offrir les moyens d’activer ces fonctions (article 8.1 de la Loi sur la protection des renseignements personnels dans le secteur privé). Sur les sites que nous livrons, rien ne part avant son choix : ni Google Analytics, ni les pixels publicitaires.
Effet secondaire bienvenu : le visiteur qui refuse reçoit un site plus léger. Celui qui accepte télécharge les scripts après son clic, quand la page est déjà affichée.
Méfiez-vous du mode de consentement de Google (Consent Mode). En mode « avancé », la documentation de Google indique que les balises se chargent dès l’arrivée du visiteur, puis envoient des mesures sans témoins tant qu’il n’a pas accepté. Le mode « de base » attend son choix. Certains outils de consentement chargent même le script de Google avant le choix dès qu’on active leur option Consent Mode. Nous l’avons constaté sur notre propre site, et nous l’avons désactivée.
Ce réglage change aussi ce que vous mesurez. Un test PageSpeed ne clique jamais sur « Accepter ». Sur un site conforme, il mesure donc la page sans vos balises, alors que vos visiteurs qui acceptent les chargent. Les données réelles de Chrome, dans le rapport Core Web Vitals de la Search Console, mêlent les deux.
Comment alléger Google Tag Manager sans perdre vos données
Pas besoin de tout débrancher. Voici ce que nous faisons, dans l’ordre, quand un conteneur alourdit un site :
- Faire l’inventaire. Chaque balise a un responsable et une raison d’exister. Celles qui n’en ont plus sont supprimées, pas seulement mises en pause.
- Déclencher au bon moment. Plus une balise part tôt, plus elle pèse sur l’affichage. Une balise qui n’est pas essentielle attend la fin du chargement de la page (le déclencheur « Fenêtre chargée »).
- Déclencher au bon endroit. La balise de conversion d’une campagne n’a rien à faire sur l’accueil : elle part sur la page de remerciement, et nulle part ailleurs.
- Préférer les modèles aux balises HTML personnalisées. Un modèle, de la galerie ou maison, tourne dans un cadre limité, avec des permissions déclarées. Une balise HTML personnalisée exécute n’importe quel code, souvent copié d’une documentation sans que personne le relise.
- Sortir du conteneur ce qui fait partie du site. Le bandeau de consentement, une police ou un élément visible de la page se chargent avec le site. Passés par Tag Manager, ils arrivent en retard et font sauter la mise en page.
Reste le marquage côté serveur (server-side tagging). Une partie du travail quitte le navigateur pour un serveur, que vous payez chaque mois. Il se défend pour un site qui dépense beaucoup en publicité. Pour un site vitrine, nous le recommandons rarement.
Mesurez avant et après chaque ménage. Notre test de vitesse gratuit donne le score d’une page en quelques secondes, et le rapport Core Web Vitals de la Search Console montre l’effet sur vos vrais visiteurs, avec quelques semaines de décalage. Le tri des scripts tiers fait partie de nos mandats d’optimisation de la vitesse.
Faut-il garder Google Tag Manager?
Oui. Une équipe marketing ou une agence qui lance des campagnes ajoute ses balises sans attendre de développeur. Ce temps épargné à chaque campagne justifie le poids du conteneur, et le consentement tient ses balises à l’écart des visiteurs qui refusent.
Retirer Tag Manager pour coller les mêmes balises dans le code du site ne règle rien. Les scripts pèsent autant, vous économisez seulement le conteneur, et chaque changement de campagne repasse par un développeur. Le problème, c’est rarement l’outil. C’est ce qu’on a laissé s’accumuler dedans.
Un dernier point, qui n’a rien à voir avec la vitesse. Toute personne qui a accès à votre conteneur peut ajouter du code sur toutes les pages de votre site, sans passer par votre développeur. Le compte Tag Manager doit être à votre nom, et la liste des accès, courte. Si vous ne savez pas qui a accès au vôtre, commencez par là. Un audit de site fait cet inventaire en même temps que celui des scripts.
