Google Tag Manager centralise les scripts marketing. Le snippet que Google fait coller dans la page charge gtm.js avec un attribut async : il ne bloque pas l’analyse du HTML comme un script synchrone mis à la main dans le head. Le ralentissement, quand il existe, vient presque toujours de ce que le conteneur déclenche ensuite.
Une balise de chat, une carte, un test A/B ou un outil de session peut peser plus lourd que le conteneur lui-même. Ajouter GTM « vide » change peu la page. Y empiler vingt balises au déclencheur « All Pages » change le premier affichage et le fil d’exécution JavaScript.
Ce qui part vraiment au chargement
Ouvrez l’aperçu GTM (mode prévisualisation) sur la page d’accueil et sur un modèle intérieur. Notez les balises dont le déclencheur est « All Pages », « Consent Initialization », « Initialization » ou « DOM Ready », pas celles qui partent sur un clic.
| Balise | Effet fréquent sur la page |
|---|---|
| Mesure d’audience seule | Script supplémentaire, en général supportable |
| Test A/B qui masque le body | Écran blanc jusqu’à la décision du test |
| Chat, carte, vidéo | Gros JavaScript, parfois dès l’accueil |
| HTML personnalisé | Tout est possible, y compris un script bloquant |
| Plusieurs outils publicitaires | Files longues sur le fil principal |
Le masquage anti-scintillement d’un test A/B est le cas le plus net : la page est cachée exprès tant que le test n’a pas choisi une variante. Le visiteur voit un FCP tardif. Si le test ne porte que sur une landing, ne chargez pas ce masquage sur tout le site.
Les balises HTML personnalisées méritent une lecture humaine. Cherchez document.write, un <script> sans async ni defer, ou un appel qui injecte une autre bibliothèque. C’est l’équivalent d’un JavaScript bloquant introduit sans passer par le code du thème.
Alléger sans perdre la mesure utile
Gardez au chargement ce qui doit voir la page entière : en pratique, la mesure d’audience et, si vous y êtes tenu, le bandeau de consentement. Le reste peut attendre un déclencheur plus tardif.
- Listez les balises « All Pages » et écrivez, pour chacune, la question à laquelle elle répond. Sans question, elle n’a pas de raison de partir partout.
- Passez le chat, les cartes et les pixels secondaires sur un déclencheur après le chargement, ou au premier clic sur le widget. Vous perdrez un peu de mesure sur les visites très courtes, vous gagnerez l’affichage.
- Limitez les balises à la page concernée (déclencheur d’URL) au lieu de tout le nom d’hôte.
- Supprimez les doublons : deux balises qui envoient la même page vue, un ancien outil laissé « au cas où », un conteneur collé deux fois dans le thème.
- Republiez le conteneur. L’aperçu ne modifie pas le site public tant que la version n’est pas publiée. Vérifiez aussi que la préproduction n’utilise pas le conteneur de production, ou vous mesurerez les tests internes.
Le consentement se règle dans le conteneur : les balises qui ne doivent pas partir avant un choix ne partent pas « en attendant que le bandeau charge ». Un bandeau lent qui débloque ensuite quinze scripts d’un coup crée une longue tâche JavaScript au pire moment. Le lien avec la réactivité est traité du côté de l’INP ; ici, l’action est de réduire le nombre de scripts libérés ensemble.
Après la publication
Comparez une mesure de laboratoire avant et après, sur la même URL, en navigation privée, avec le même profil de consentement. Un test « tout refusé » et un test « tout accepté » ne racontent pas la même page : jugez les deux si vos visiteurs se répartissent entre les deux.
Sur le terrain, le conteneur publié un jeudi peut dégrader les visites du week-end sans qu’aucun déploiement de thème n’apparaisse dans le journal technique. Quand une page ralentit sans changement de code, le conteneur de balises est l’endroit suivant à ouvrir. Le cadre de lecture des métriques reste le guide des Core Web Vitals.