⚡ GTM et vitesse de page : tests, résultats et 8 façons d'accélérer votre site

Les marketeurs répètent souvent: «Google Tag Manager accélère les sites web, les pages avec GTM se chargent plus vite.» Les développeurs rétorquent généralement: «GTM ne fait que ralentir les choses.» La vérité, comme souvent, se situe entre ces deux extrêmes.

Nous avons mené une série de tests avec différentes configurations GTM: un conteneur vide, un conteneur avec 8 codes de suivi, des balises codées en dur, différents moments de déclenchement, des dizaines de balises HTML personnalisées avec manipulations du DOM. Nous avons mesuré la vitesse via webpagetest.org et Lighthouse. Les résultats se sont avérés moins tranchés que ce qu’affirment les présentations GTM.

Voici ce que nous avons constaté: le conteneur GTM en lui-même ne ralentit quasiment rien, mais ce que vous y mettez peut ajouter 3 ou 10 secondes au chargement de la page. Et le point clé, c’est que vous pouvez maîtriser cela.

💡 Aperçu rapide:

Un conteneur GTM vide ajoute environ 100 millisecondes au chargement de la page
Huit balises de suivi via GTM ralentissent la page de 3 secondes en 3G rapide et jusqu’à 10 secondes sur des connexions lentes
Les 8 mêmes balises codées en dur directement dans le site ralentissent encore plus les choses
Plus les balises se déclenchent tard, moins leur impact est important: un délai de 1,5 seconde après Window Loaded réduit le temps de chargement de 6 secondes en 3G lente
Une configuration bien pensée des déclencheurs et un nettoyage du conteneur restaurent la vitesse sans perte de données

Comment nous avons testé

La méthodologie est simple mais rigoureuse. Nous avons exécuté chaque test au moins trois fois et calculé la moyenne.

Outils: webpagetest.org (serveur en Irlande, EC2, Chrome et Firefox pour le desktop, OnePlus 5 pour les tests mobiles) et l’audit Lighthouse intégré à Chrome DevTools. Dans Lighthouse, nous avons examiné à la fois les rapports mobile et desktop. Chrome a été lancé en mode navigation privée, sans extensions, performances de l’ordinateur portable au maximum.

Métriques mesurées:

Dans webpagetest.org: Document complete (secondes jusqu’au chargement du contenu statique, des images et des styles) et Fully loaded (le moment après onLoad où l’activité réseau se stabilise pendant 2 secondes). Dans Lighthouse: First Meaningful Paint, Time to Interactive, First CPU Idle et Max Potential First Input Delay (FID).

Codes de suivi dans les tests: Google Analytics (gtag.js), Facebook Pixel, Reddit Pixel, Quora Pixel, LinkedIn Insights, Twitter Universal Tag, Google Ads Remarketing (gtag.js), Hotjar. Huit scripts largement utilisés.

Scénarios comparés:

Page propre sans scripts tiers et sans GTM
Page avec 8 codes de suivi codés en dur directement avant </head>, sans GTM
Conteneur GTM vide sans balises
Les 8 balises via GTM, déclencheur All Pages (également appelé gtm.js)
Les mêmes 8 balises via GTM, déclencheur DOM Ready (gtm.dom)
Les mêmes 8 balises via GTM, déclencheur Window Loaded (gtm.load)
Les mêmes 8 balises, se déclenchant 1,5 seconde après Window Loaded
Conteneur GTM avec le mode aperçu et débogage activé
Conteneur GTM avec 100 balises HTML personnalisées ajoutant des éléments à la fin de <body>
Conteneur GTM avec 100 balises HTML personnalisées ajoutant des éléments à un endroit spécifique de la page (après le H2)
Conteneur GTM avec 100 balises HTML personnalisées recherchant tous les liens et insérant un élément après le 21e
Conteneur GTM avec 1976 variables constantes (rempli à pleine capacité, 200 Ko)

Ce que les tests ont montré

Asynchrone ne signifie pas «sans conséquences»

Les scripts asynchrones ne bloquent pas directement le rendu. Mais ils ont tout de même besoin de ressources CPU, ce qui signifie que les scripts principaux du site s’exécutent plus lentement. En pratique: l’événement Document Complete sur une page propre s’est produit après 4 secondes. Avec huit balises, après 7,7 secondes. Une différence de 3,7 secondes simplement parce que le processeur est occupé par des scripts tiers.

Comparaison du temps Document Complete sans tags et avec tags

Même un conteneur GTM vide a légèrement augmenté le temps de chargement, d’environ 100 millisecondes.

Impact d'un conteneur GTM vide sur le temps de chargement

Ce n’est pas GTM le problème, mais ce que vous y mettez

Un conteneur GTM vide ajoute environ 100 millisecondes au chargement de la page, parfois il n’y a aucun délai. Les problèmes commencent lorsque vous remplissez le conteneur de balises. Mais même là, les choses ne sont pas linéaires.

Huit balises de suivi ont ralenti la page d’environ 3 secondes sur une connexion 3G rapide et de 10 secondes sur des connexions lentes. Chaque balise tire son propre script, et le navigateur passe du temps à les exécuter.

Document Complete sans tags et avec 8 tags dans GTM

Mais un conteneur rempli de 1976 variables constantes (200 Ko, la limite de GTM) n’a ajouté que 0,1 à 0,3 seconde. Les variables ne chargent pas de scripts externes et ne manipulent pas le DOM, leur impact est donc minime.

Conclusion: ce qui compte, ce n’est pas la taille du conteneur, mais les actions que ses éléments effectuent.

Les balises codées en dur ralentissent plus que les mêmes balises via GTM

Lorsque nous avons ajouté 8 scripts de suivi directement dans le code du site, la page a ralenti de manière encore plus notable. En 3G rapide, les balises codées en dur ont ajouté environ 600 millisecondes de délai supplémentaire par rapport aux mêmes balises lancées via GTM.

Comparaison des tags codés en dur et des tags via GTM

Sur le deuxième graphique, le même constat sous un autre angle: les scripts codés en dur perdent systématiquement face à GTM en termes de temps de Document Complete.

Document Complete tags codés en dur versus GTM

GTM aide vraiment les pages à se charger légèrement plus vite que lorsque les scripts sont ajoutés directement dans le code. Mais ce n’est pas une règle universelle. Il existe des scénarios où lancer du JS sans GTM peut être implémenté de manière plus efficace, et Simo Ahava, l’un des principaux experts GTM, est d’accord avec cela.

Le moment du déclenchement des balises est important

Plus une balise se déclenche tard, moins elle affecte le chargement initial de la page. Nous avons testé quatre moments:

Page View (gtm.js), immédiatement au chargement du conteneur
DOM Ready (gtm.dom), lorsque le DOM est construit
Window Loaded (gtm.load), lorsque toutes les ressources sont chargées
afterLoad, 1,5 seconde après Window Loaded (déclencheur personnalisé)

Code du déclencheur personnalisé afterLoad:

1 <script>
2   (function() {
3     try {
4       window.setTimeout(function(){
5         dataLayer.push({
6           'event': 'afterLoad'
7         });
8       }, 1500);
9     } catch (err) {}
10   })();
11 </script>

Résultat: les déclencheurs DOM Ready et Window Loaded ont apporté une légère amélioration. Mais le gain le plus significatif est venu de afterLoad. En 3G lente, le délai a été réduit de 6 secondes par rapport au déclencheur Page View. En 3G rapide, de 600 millisecondes.

Comparaison du Fully Loaded selon différents moments de déclenchement des tags

Pourquoi cela fonctionne-t-il? La page peut contenir des éléments qui se chargent dynamiquement seulement après que toutes les ressources sont entièrement chargées. Si les tags ralentissent le chargement initial, ces éléments apparaissent également plus tard. En différant les tags non critiques, vous laissez le contenu principal se charger sans interférence.

Mais il y a une réserve: si vous différez des tags dont la précision dépend de (Google Analytics), certains visiteurs peuvent quitter la page avant que le compteur ne se déclenche. Vos rapports perdront alors des données. La décision de différer des tags doit être prise avec l'équipe, et non unilatéralement par un développeur ou un marketeur.

Les tags de suivi ne sont pas les seuls fautifs

Un autre groupe de tags «lourds» sont ceux qui manipulent le DOM. Par exemple, les tags HTML personnalisés qui ajoutent ou modifient des éléments sur la page.

Nous avons testé plusieurs variantes:

100 tags HTML personnalisés ajoutant des éléments à la fin de <body>. Chaque tag exécutait un script simple console.log('hello') et créait un <div>Hello!</div>. Sans spécifier d'emplacement d'insertion particulier. L'impact sur la vitesse de chargement de la page s'est avéré minime, les éléments étaient simplement ajoutés à la fin.

100 tags HTML personnalisés ajoutant des éléments à un endroit spécifique de la page. Chaque tag cherchait le premier h2 et insérait un h3 après lui. Script:

1 <script>
2   (function() {
3     var h3 = document.createElement('h3');
4     h3.innerText = "An additional element";
5     var title = document.querySelector('h2');
6     if (title) {
7       title.parentElement.insertBefore(h3, title.nextSibling);
8     }
9   })();
10 </script>

Cela a ajouté plusieurs centaines de millisecondes au chargement de la page. Bien que le script soit primitif, la recherche d'un élément et son insertion nécessitent des ressources.

Impact de 100 tags avec manipulations DOM sur le Fully Loaded

100 tags HTML personnalisés qui recherchent tous les liens sur la page et insèrent un élément après le 21e. Script:

1 <script>
2   (function() {
3     var h3 = document.createElement('h3');
4     h3.innerText = "An additional element";
5     var element = document.querySelectorAll('a')[20];
6     if (element) {
7       element.parentElement.insertBefore(h3, element.nextSibling);
8     }
9   })();
10 </script>

Différence par rapport à l'expérience précédente: querySelectorAll parcourt tous les éléments de la page, vérifie chacun d'eux, ce qui est plus coûteux. Dans webpagetest.org, la différence était faible (100-200 ms), mais Lighthouse a montré une augmentation de 2 à 3 secondes du Time to Interactive. Cela signifie que pendant le chargement de la page, le navigateur est tellement occupé à insérer des éléments qu'il ne répond pas aux actions de l'utilisateur.

Time to Interactive avec lourdes manipulations DOM

Oui, 100 scripts identiques, c'est excessif. Mais l'idée est que même quelques tags complexes manipulant le DOM peuvent produire un effet similaire.

Comment réduire l’impact de GTM sur la vitesse: 8 techniques

Nettoyez régulièrement le conteneur des balises abandonnées

Les audits le montrent: jusqu’à un tiers des codes de suivi présents sur les sites appartiennent à des outils que l’entreprise n’utilise plus. Vous êtes passé de l’outil d’analytics X à Z, mais les codes de X se chargent encore sur chaque page et la ralentissent.

Ce qu’il faut faire:

Demandez à un développeur de fournir la liste de toutes les requêtes HTTP et de tous les scripts présents sur la page
Recherchez sur Google les domaines de ces requêtes, identifiez à quels outils ils appartiennent
Demandez à vos collègues des différents services quels outils sont encore utilisés
Repérez les scripts «orphelins» qui ne figurent pas dans la liste des outils utilisés
Si un script est implémenté via GTM, mettez-le en pause pendant un mois; si personne ne réclame, supprimez-le définitivement
Si un script est codé en dur, demandez au développeur de le commenter temporairement, puis de le supprimer après un mois

Conteneur GTM avant audit des tags abandonnés

Différez les balises non critiques

Moins il y a de balises sur le déclencheur All Pages, plus le chargement initial est rapide. Toutes les balises ne peuvent pas être différées, mais si vous appliquez cette approche à au moins certaines d’entre elles, l’amélioration sera sensible.

Comment mettre en œuvre le différé (méthode de Pavel Brechik):

Étape 1. Créez une balise HTML personnalisée avec le code:

1 <script>
2   (function() {
3    try {
4      window.setTimeout(
5       function(){
6        dataLayer.push({'event': 'afterLoad'});
7       }, 1500);
8     } catch (err) {}
9   })();
10 </script>

Étape 2. Lancez cette balise sur le déclencheur Window Loaded.

Configuration du déclencheur Window Loaded pour tag HTML personnalisé

Étape 3. Créez un déclencheur personnalisé pour l’événement afterLoad.

Créer un déclencheur afterLoad personnalisé dans GTM

Étape 4. Attribuez ce déclencheur aux balises qui peuvent être différées.

Résultat en 3G lente: délai réduit de 6 secondes, en 3G rapide, de 600 millisecondes.

Fully Loaded selon différents moments de déclenchement des tags

Quelles balises peuvent être différées et lesquelles ne le peuvent pas doit être décidé avec l’équipe. Les développeurs supprimeraient idéalement tout pour la vitesse, les marketeurs ajouteraient tout pour la précision des données. La vérité est au milieu.

Utilisez les balises uniquement sur les pages nécessaires

Chaque balise n’a pas besoin de se déclencher sur l’ensemble du site. Un pixel de remarketing Google Ads peut ne se lancer que sur les pages d’atterrissage des campagnes, pas sur tout le site. LinkedIn Insights, uniquement sur les pages où arrive du trafic LinkedIn. Configurez des exclusions dans les déclencheurs, cela réduira le nombre de scripts qui s’exécutent sur une page type.

Configuration d'un déclencheur pour pages spécifiques uniquement dans GTM

Évitez les manipulations lourdes du DOM

Si vous avez besoin d’une balise HTML personnalisée qui ajoute quelque chose à la page, essayez de le faire de la manière la plus légère possible. Évitez querySelectorAll avec itération sur tous les éléments. N’insérez pas des dizaines d’éléments identiques à différents endroits de la page. Chaque manipulation du DOM consomme des ressources du navigateur à un moment où il est déjà occupé à afficher la page.

Exemple de tag HTML personnalisé optimisé dans GTM

Ne mesurez pas la vitesse avec le mode aperçu activé

Le mode Aperçu et débogage de GTM ajoute une charge supplémentaire sur le navigateur que les vrais visiteurs ne subissent pas. Si vous mesurez la vitesse avec l’aperçu activé, les résultats seront moins bons que la réalité. Avant un audit de vitesse, désactivez toujours le mode débogage.

Désactiver le mode aperçu de GTM pour les tests de vitesse

Testez la vitesse après chaque modification du conteneur

Vous avez ajouté une nouvelle balise ou modifié un déclencheur, vérifiez immédiatement la vitesse de la page via webpagetest.org ou Lighthouse. Prenez des mesures avant et après. Cela vous permettra de repérer immédiatement une balise problématique, plutôt que de vous demander plus tard pourquoi le site a commencé à se charger 2 secondes plus lentement.

Gardez le conteneur léger

Supprimez les balises, déclencheurs et variables inutilisés. Il s’agit moins de vitesse (comme l’a montré le test avec 1976 variables) que de maintenabilité. Dans un conteneur qui compte une centaine de balises, il est facile de perdre de vue un script problématique. Dans un conteneur qui en compte deux douzaines, chaque élément est visible.

Séparez le bon grain de l’ivraie: ce qui fait vraiment gagner du temps de chargement

Tirons les conclusions des expériences. Voici ce qui apporte le plus d’effet, par ordre décroissant:

Tableau récapitulatif de l'impact de différents facteurs sur la vitesse de chargement

D’après nos mesures, l’amélioration la plus significative vient du différé des balises via afterLoad, jusqu’à 6 secondes sur les connexions lentes. En deuxième position, la suppression des codes de suivi abandonnés. En troisième position, la limitation de la portée des balises à des pages spécifiques.

⁉️🤔 Questions fréquentes

Un GTM vide ralentit-il un site?

Pratiquement pas. Dans nos tests, un conteneur vide a ajouté environ 100 millisecondes au chargement de la page. Parfois, il n’y avait aucun délai. C’est une marge d’erreur, imperceptible pour les utilisateurs comme pour les moteurs de recherche.

Qu’est-ce qui ralentit le plus: GTM ou les scripts codés en dur?

Les scripts codés en dur ralentissent un peu plus. Dans notre test, 8 balises de suivi ajoutées directement dans le code ont ralenti la page d’environ 600 millisecondes de plus que les mêmes balises via GTM. Mais ce n’est pas une règle universelle, un JS personnalisé bien écrit peut être plus efficace que GTM.

Peut-on différer toutes les balises?

Techniquement, oui. Mais vous perdrez des données: certains visiteurs quitteront la page avant que les compteurs ne se déclenchent. Google Analytics et les outils similaires sous-estimeront le trafic. Ne différez que les balises qui n’exigent pas une grande précision, par exemple les widgets de chat ou les pixels de remarketing. Il vaut mieux laisser l’analytics sur Page View.

Comment vérifier quelles balises dans GTM ralentissent vraiment les choses?

Lancez un audit Lighthouse avec l’onglet Réseau ouvert. Observez quels scripts se chargent le plus longtemps et lesquels bloquent le rendu. Faites correspondre les domaines de ces scripts avec les balises du conteneur. Ou faites un test A/B: désactivez temporairement les balises suspectes une par une et mesurez la vitesse.

Qu’en est-il du GTM côté serveur?

Le GTM côté serveur déplace le traitement des balises du navigateur de l’utilisateur vers votre serveur. Le navigateur ne reçoit qu’un seul conteneur au lieu d’une douzaine de scripts tiers. Cela réduit radicalement la charge côté client. Si vous avez des dizaines de balises de suivi, le GTM côté serveur mérite d’être envisagé. La technologie est disponible depuis 2020, et d’ici 2026 sa mise en œuvre est devenue nettement plus simple.

En résumé: GTM accélère-t-il ou ralentit-il?

Ni l’un ni l’autre sous leur forme pure. GTM est un répartiteur: en lui-même, il est presque sans poids, et la vitesse de la page est déterminée par les balises que vous lancez à travers lui, ainsi que leur quantité.

Huit balises de suivi standard via GTM ajoutent 3 à 10 secondes au chargement de la page. Mais ces mêmes balises codées en dur ralentissent encore davantage les choses. Un lancement différé via afterLoad permet de regagner jusqu’à 6 secondes. Supprimer les balises abandonnées, encore quelques secondes. Au total, avec une configuration intelligente, GTM peut surpasser les scripts codés en dur, et sans configuration, perdre complètement face à une page vide.

La règle principale est simple: ce n’est pas GTM qui fait le site, mais vous-même. Auditez le conteneur, supprimez ce qui est inutile, différez les balises non critiques, paramétrez les exclusions de pages, et la vitesse de votre site vous remerciera.

1	<script>
2	(function() {
3	try {
4	window.setTimeout(function(){
5	dataLayer.push({
6	'event': 'afterLoad'
7	});
8	}, 1500);
9	} catch (err) {}
10	})();
11	</script>

1	<script>
2	(function() {
3	var h3 = document.createElement('h3');
4	h3.innerText = "An additional element";
5	var title = document.querySelector('h2');
6	if (title) {
7	title.parentElement.insertBefore(h3, title.nextSibling);
8	}
9	})();
10	</script>

Tout pour WordPress, le développement web — et plus encore

🚀 Google Tag Manager et vitesse de site : ce que disent les tests