Google Analytics est l’outil de mesure d’audience le plus répandu du web, et le script tiers que l’on trouve sur presque toutes les pages que nous auditons. Il est posé une fois, tôt dans la vie du site, souvent par quelqu’un qui n’y travaille plus, et il est rarement remis en question : c’est un outil gratuit, fourni par Google, dont le snippet officiel tient en huit lignes. Ces huit lignes cachent pourtant plusieurs centaines de kilooctets de JavaScript exécutés à chaque visite.
Un outil de mesure d’audience est un script qui collecte, dans le navigateur du visiteur, des événements de navigation, pages vues, clics, conversions, puis les envoie à un serveur de collecte. Google Analytics 4 le fait via la balise Google, gtag.js, servie depuis le domaine googletagmanager.com, le même que le conteneur Google Tag Manager, avec lequel on la confond souvent. La différence importe, parce que les deux ne se chargent pas, ne s’exécutent pas et ne s’optimisent pas de la même façon.
Cet article retrace d’où vient l’outil, mesure ce qu’il coûte réellement à une page, détaille cinq leviers pour réduire ce coût sans perdre une donnée, compare les alternatives légères chiffres à l’appui, et replace Google Analytics dans la famille plus large des scripts tiers. Que vaut la recommandation d’intégration de Google, inchangée depuis vingt ans, face aux Core Web Vitals que Google lui-même utilise pour classer vos pages ?
D’où vient Google Analytics ?
Google Analytics est né du rachat d’Urchin Software par Google en mars 2005. L’outil a traversé quatre générations, d’Urchin au tag classique, puis Universal Analytics en 2012, puis Google Analytics 4, devenu obligatoire à l’arrêt d’Universal Analytics le 1er juillet 2023. Chaque génération a alourdi le script embarqué, à mesure que la mesure s’est rapprochée de la publicité.
D’Urchin à Universal Analytics
Avant de s’appeler Google Analytics, l’outil s’appelait Urchin, et il analysait des fichiers journaux de serveur. Google a acquis Urchin Software Corporation en mars 2005 et a lancé Google Analytics quelques mois plus tard, avec une demande si forte que les inscriptions ont dû être suspendues temporairement. L’adoption a été massive : dès 2010, l’outil équipait environ la moitié des dix mille sites les plus populaires. En 2012, Universal Analytics a apporté un suivi multiplateforme et des capacités de personnalisation qui ont renforcé une position déjà dominante.
Google Analytics 4 et la balise Google
Au fil des années, Google a ajouté le suivi mobile, l’intégration avec Google Ads et la Search Console, les rapports d’objectifs et de conversion, ce qui a accéléré la croissance sur le e-commerce et rapproché l’outil de mesure de la régie publicitaire.
Google Analytics 4 a achevé ce mouvement : un modèle par événements, une intégration native avec Google Ads, et un script commun, la balise Google, qui sert aussi Ads et Floodlight. Malgré une migration largement décriée, l’outil domine toujours le marché, et le Web Almanac 2025 place google-analytics.com et googletagmanager.com parmi les dix domaines tiers les plus présents du web.
Cette histoire témoigne de la capacité de Google à identifier un besoin, à l’intégrer dans son écosystème et à le développer pour ses annonceurs autant que pour les webmasters. Elle explique aussi pourquoi le script a grossi : un outil qui ne mesurait que des pages vues est devenu le point d’entrée de toute la publicité Google, et il en porte le poids.
Google Analytics ralentit-il un site ?
Oui, mesurablement. Le tag gtag.js de Google Analytics 4 pèse environ 419 Ko décompressés, relevés en août 2026, et 135 Ko compressés selon les mesures de Plausible, contre 2,5 Ko pour ce dernier. Le coût réel se joue surtout à l’exécution : ce JavaScript doit être analysé, compilé et exécuté sur le thread principal, celui-là même qui affiche la page.
Un tag JavaScript, par choix
Depuis les premières versions, Google fournit un tag en JavaScript pour permettre le suivi, et cela semble logique : JavaScript fonctionne partout et permet des interactions complexes. En termes de performance, cette décision n’est pas sans conséquence. Jusqu’à Universal Analytics, le tag était un script d’injection dynamique, qui créait lui-même la balise <script> de la bibliothèque, ce qui empêchait toute priorisation par le navigateur : le scanner de préchargement ne voit pas ce que le JavaScript crée.
/* Ancien script d'injection asynchrone Google Analytics (Universal Analytics) */
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-XXXXXXXXXX', 'auto');
ga('send', 'pageview');Les choses ont changé avec Google Analytics 4, dont la documentation officielle fournit désormais une balise <script> HTML native. Le navigateur peut enfin la découvrir dès l’analyse du document. Mais elle conserve son attribut async, et l’instruction de placement n’a pas bougé : immédiatement après l’ouverture du <head>, sur chaque page.
Async n’est pas gratuit
Le tag officiel utilise un chargement asynchrone, ce qui signifie qu’il est téléchargé en parallèle de l’analyse du HTML, sans la bloquer, mais qu’il s’exécute dès qu’il est prêt, à un moment imprévisible. C’est là que le bât blesse : bien que le script soit chargé de façon asynchrone, son exécution interrompt le rendu de la page pendant plusieurs centaines de millisecondes sur un mobile d’entrée de gamme. Dans son implémentation par défaut, le tag Google Analytics retarde l’affichage de pages dans de multiples scénarios, en particulier quand il arrive avant l’image principale.
Google documente lui-même ce coût dans ses bonnes pratiques pour les tags et les tag managers, à propos de la métrique de réactivité des Core Web Vitals, l’INP.
L’Interaction to Next Paint est sensible à la contention du processeur sur le thread principal, et nous avons observé une corrélation entre la taille des tag managers et de moins bons scores d’INP.
Katie Hempenius et Barry Pollard, ingénieurs de l’équipe Chrome, dans le guide Best practices for tags and tag managers de web.dev, mis à jour le 24 août 2022
Google Tag Manager, une couche supplémentaire et distincte
Une confusion mérite d’être levée, parce qu’elle est dans presque tous les articles sur le sujet. La balise Google de GA4 est servie depuis googletagmanager.com, mais elle n’est pas un conteneur Google Tag Manager, et GA4 s’installe sans GTM, par le snippet manuel de la documentation.
Quand le site utilise en plus un conteneur, deux scripts distincts s’exécutent, gtm.js puis gtag.js, chacun avec sa propre initialisation. Le conteneur génère son propre temps de blocage, réévalue ses déclencheurs à chaque événement et retarde l’exécution du code de mesure. Les mesures du projet third-party-web, sur les audits Lighthouse de l’HTTP Archive, chiffrent ce cumul : le conteneur coûte environ dix fois l’outil de mesure qu’il déploie.
La recommandation problématique de Google
Google conseille de placer son tag immédiatement après l’ouverture du <head>, ce qui, du point de vue de la performance, est le pire emplacement possible. Le début du <head> est un territoire précieux, où devraient figurer les ressources essentielles au premier rendu : la feuille de style critique, la police principale, le préchargement de l’image LCP. Y placer un script tiers de 419 Ko, sans justification technique, c’est demander au navigateur de mesurer avant d’afficher.
Bien que Google Analytics offre des données précieuses sur le trafic et le comportement des visiteurs, sa mise en œuvre standard pose donc de sérieux problèmes de performance. Pour qui veut des pages rapides tout en conservant ces données, il convient de corriger la proposition de Google, et c’est ce que nous faisons en intervention.
Comment optimiser l’intégration de Google Analytics ?
Cinq leviers réduisent l’impact sans renoncer à la mesure : remplacer le snippet officiel par une balise script native en defer avec une priorité basse, la placer en pied de page, préparer la connexion sans la sur-solliciter, servir le script depuis votre propre domaine, et différer son exécution à la première interaction. Aucun ne dégrade la qualité des données collectées, le retard de collecte se comptant en centaines de millisecondes.
La mise en place d’un outil de mesure ne devrait pas se faire au détriment de la performance, et avec quelques gestes techniques il est possible d’en minimiser l’impact tout en conservant les avantages de l’outil. Les cinq leviers se cumulent, et les deux premiers suffisent déjà sur la plupart des sites :
- une balise
<script>native avecdeferetfetchpriority="low", à la place du snippet asynchrone officiel ; - un placement en toute fin de page, juste avant
</body>, avec tous les autres scripts tiers sauf la CMP ; - un
dns-prefetchvers les domaines de collecte, jamais une préconnexion vers tout ce qui passe ; - un service du script depuis votre propre domaine, via la passerelle de balises Google ou un proxy ;
- un report de l’exécution à la première interaction du visiteur, avec un délai plafond pour ceux qui n’interagissent pas.
Chacun de ces leviers a un effet mesurable et une contrepartie connue, détaillés ci-dessous dans l’ordre où nous les appliquons. La seule règle qui les précède tous est de mesurer avant et après, par blocage du domaine, comme l’explique notre guide sur le coût réel des scripts tiers : un gain non mesuré n’est pas un gain.
Une balise script native avec defer et fetchpriority
Plutôt que de s’en remettre à l’implémentation par défaut, utilisez une balise <script> native associée à l’attribut defer. Contrairement à async, defer exécute le script une fois le document HTML entièrement analysé, dans l’ordre des balises, et jamais au milieu du rendu. Pour le déprioriser davantage, l’attribut fetchpriority="low" indique au navigateur que ce fichier n’est pas critique et peut rester dans la file de téléchargement tant que les images et les polices du premier écran ne sont pas servies :
<!-- Google tag (gtag.js), version corrigee -->
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){ dataLayer.push(arguments); }
gtag('js', new Date());
gtag('config', 'G-XXXXXXXXXX');
</script>
<script src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX" defer fetchpriority="low"></script>L’ordre des deux balises est inversé par rapport au snippet officiel, et ce n’est pas un détail : la file dataLayer et la fonction gtag() doivent exister avant que la bibliothèque ne s’exécute, et comme celle-ci est différée, les commandes config poussées en amont sont simplement traitées à son arrivée. Aucun événement n’est perdu, ils attendent dans la file.
Charger le script en pied de page, avant la fermeture du body
Pour defer bien plus que pour async, l’ordre d’appel des scripts importe. Même différé, un script appelé dans le <head> s’exécute avant tous ceux qui le suivent dans le document, y compris vos propres scripts d’interface. Pour être certain de déprioriser Google Analytics, le code doit donc être placé en toute fin de page, juste avant </body>, accompagné de tous les autres scripts tiers. La seule exception est la CMP, qui conditionne les autres et l’expérience du visiteur : elle reste en haut, elle seule, comme le développe notre guide pour bien choisir sa CMP.
Employer les resource hints avec parcimonie
Pour anticiper la connexion vers les domaines de Google, les indices de ressources dns-prefetch et preconnect permettent au navigateur de résoudre un domaine, voire d’établir la connexion, avant que le script ne soit demandé. La règle a changé depuis nos premières recommandations : une préconnexion inutilisée est fermée au bout de dix secondes et concurrence les connexions du premier écran, et Lighthouse 13 a retiré son audit de préchargement pour risque de sur-recommandation. Pour un script différé en fin de page, un simple dns-prefetch suffit, et la préconnexion se réserve à la CMP :
<!-- Resolution DNS anticipee, sans ouvrir de connexion : cout nul -->
<link rel="dns-prefetch" href="https://www.googletagmanager.com">
<link rel="dns-prefetch" href="https://www.google-analytics.com">
<!-- Preconnexion : reservee a ce qui est charge tot et conditionne le reste -->
<link rel="preconnect" href="https://cmp.exemple.com" crossorigin>Servir le script depuis votre propre domaine
Une autre approche consiste à servir le script directement depuis votre domaine, ce qui économise tout ou partie des trois étapes de connexion à un domaine externe, résolution DNS, connexion TCP et négociation TLS, soit couramment plusieurs centaines de millisecondes sur une connexion mobile.
Google propose désormais une voie officielle, la passerelle de balises Google pour les annonceurs, qui permet de déployer la balise depuis votre propre infrastructure de première partie, via votre CDN, votre répartiteur de charge ou votre serveur web. Dans l’écosystème WordPress, plusieurs extensions proposent une mise en cache locale du script, avec le risque de servir une version périmée si le rafraîchissement n’est pas maîtrisé.
Reporter l’exécution à la première interaction
Si vos besoins le permettent, la solution la plus efficace consiste à retarder l’exécution du script jusqu’à ce que le visiteur interagisse avec le site, par un clic, une touche ou un pointeur, avec un délai plafond pour ceux qui ne le font jamais. Les ressources du navigateur sont alors intégralement dédiées au rendu de la page, et la collecte s’effectue dans une seconde fenêtre. Ce comportement s’active en quelques clics sous WordPress avec WP Rocket, Perfmatters ou FlyingPress, et nécessite un code spécifique ailleurs :
// Report de Google Analytics a la premiere interaction, avec plafond de 5 s
(function () {
var done = false;
function load() {
if (done) { return; }
done = true;
var s = document.createElement('script');
s.src = 'https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX';
s.defer = true; s.fetchPriority = 'low';
document.body.appendChild(s);
}
['pointerdown', 'keydown', 'touchstart'].forEach(function (ev) {
addEventListener(ev, load, { once: true, passive: true });
});
setTimeout(load, 5000); // les visiteurs qui n'interagissent pas sont quand meme mesures
})();Le défilement est volontairement absent des déclencheurs. Charger un script de plusieurs centaines de kilooctets au premier scroll déplace son exécution exactement dans la fenêtre où l’INP se mesure, ce qui échange un gain de laboratoire contre une perte de terrain. Le clic, lui, est une interaction où le visiteur attend explicitement quelque chose. Si tout cela vous semble trop complexe, la concurrence a peut-être une réponse plus simple.
Votre site est-il aussi rapide que vos visiteurs l’espèrent ?
Quelle alternative à Google Analytics choisir ?
Trois alternatives sérieuses se partagent le marché : Plausible, le plus léger avec 2,8 Ko de script décompressé ; Fathom Analytics, à 6,9 Ko ; et Matomo, le plus complet, à 84 Ko mais auto-hébergeable. Toutes trois fonctionnent sans cookie, ce qui supprime aussi le bandeau de consentement pour la mesure d’audience, et les pertes de données liées aux refus.
| Solution | Poids du script | Cookies | Hébergement |
|---|---|---|---|
| Google Analytics 4 | 419 Ko | Oui | |
| Matomo | 84 Ko | Optionnels | Cloud ou auto-hébergé |
| Fathom Analytics | 6,9 Ko | Non | Cloud |
| Umami | 4,7 Ko | Non | Cloud ou auto-hébergé |
| Plausible | 2,8 Ko | Non | Cloud ou auto-hébergé |
Ces poids sont ceux des scripts décompressés, relevés auprès de chaque éditeur en août 2026. Plausible publie de son côté une comparaison en poids compressé : 135 Ko pour le script Google Analytics contre 2,5 Ko pour le sien, soit 54 fois moins, et plus de 285 Ko au total quand s’ajoutent Google Tag Manager et un bandeau de consentement. L’écart le plus parlant tient entre les deux extrêmes : le tag de Google pèse 150 fois celui de Plausible, pour un besoin qui, sur un site vitrine ou éditorial, se limite le plus souvent aux pages vues et aux sources de trafic.
Le poids n’est que la partie visible. Un script léger est aussi un script qui exécute peu de code, ne pose pas de cookie et n’entraîne donc ni bandeau de consentement pour la mesure ni perte de données liée aux refus. Sur un site où la moitié des visiteurs refuse le dépôt de cookies, une solution sans cookie mesure paradoxalement mieux que Google Analytics, qui ne voit plus que l’autre moitié, ou des signaux anonymisés en mode consentement avancé.
Pourquoi ces alternatives sont-elles payantes ?
Les coûts de collecte, de traitement et de stockage des données de suivi sont réels. Prendre en charge des millions de requêtes par jour demande une infrastructure robuste et évolutive. Contrairement à Google, qui monétise ses services en exploitant les données à des fins publicitaires, ces acteurs optent pour un modèle directement payant afin de financer leur infrastructure sans revendre l’audience, ce qui est aussi la condition de leur conformité au RGPD sans consentement.
Matomo et Plausible, deux philosophies
Anciennement Piwik, Matomo est une plateforme open source qui offre une alternative sérieuse et complète, jusqu’aux entonnoirs et aux heatmaps, avec un accent sur la maîtrise des données, en auto-hébergement ou en cloud. Son script reste conséquent, et ses fonctionnalités comportementales ont un coût comparable à celui des outils qu’elles remplacent. Plausible fait le choix inverse : un tag de quelques kilooctets, un tableau de bord unique, pas de cookie, et un impact sur le TBT et l’INP si faible qu’il en devient difficile à mesurer.
Vous ne l’avez probablement pas remarqué, mais la page que vous lisez charge Plausible, et obtient un score PageSpeed Insights mobile de 100. Ce n’est pas le script qui fait le score, c’est l’ensemble des choix dont il fait partie ; mais c’est un script qui n’a jamais eu besoin d’être différé, et c’est le meilleur compliment qu’on puisse faire à un tiers.
Vie privée et réglementation
L’autre avantage majeur de ces solutions est réglementaire. Sans cookie ni collecte de données personnelles, la mesure d’audience peut, sous conditions, se passer du consentement, ce qui retire un bandeau, ou au moins une finalité du bandeau, et la perte de données qui va avec. Les CMP sont non seulement lourdes, elles génèrent du temps de blocage sur le chemin critique, comme le montre notre comparatif. Supprimer le besoin d’une CMP pour la mesure est donc un gain de performance en soi, et Google Analytics n’est qu’un exemple parmi d’autres de ce que la mesure coûte.
Quel est l’impact des scripts tiers sur la performance ?
Chaque script tiers réclame la même chose : être chargé en priorité. Comme ils ne peuvent pas tous l’être, la question n’est pas de savoir si l’un d’eux ralentit le site, mais lesquels méritent de passer avant le contenu. La réponse est courte : aucun script tiers ne mérite de précéder la page elle-même, à l’exception de celui qui autorise les autres.
Une demande universelle de priorité
Google Analytics n’est que la pointe de l’iceberg. Publicité, analyse comportementale, consentement, A/B testing, chat, avis clients : ces scripts s’accumulent, et la plupart de leurs fournisseurs recommandent de poser leur tag aussi tôt que possible dans la page, pour des raisons d’efficacité de suivi qui sont légitimes de leur point de vue. Le point de vue du visiteur est différent : le cœur de tout site est la page elle-même, et les scripts de première partie qui font fonctionner l’interface, menus, formulaires, panier, devraient être les seuls à passer avant le contenu.
Retarder pour prioriser
L’astuce consiste donc à reprioriser les scripts de première partie en retardant l’exécution des tiers, ce qui améliore directement le FCP et le LCP, et libère le thread principal pendant la fenêtre où l’INP se mesure. Le gain sur l’affichage compense largement le retard que ces scripts subissent, dont la fourchette est généralement de 500 millisecondes au maximum. Aucune donnée n’est perdue, elle est décalée : la vue de page part quelques dixièmes de seconde plus tard, ce qui ne change ni le comptage ni l’attribution.
Ce point de doctrine vaut pour toute la famille, et chaque outil aura son guide sur ce blog, du prix de l’anti-flicker en A/B testing au coût des widgets de chat et d’avis. Une seule famille fait exception, l’A/B testing, qui doit rester prioritaire sous peine de fausser ses tests, et c’est précisément pour cela qu’il coûte si cher.
Comment concilier mesure d’audience et performance ?
En traitant chaque outil de mesure comme une dépense budgétée, pas comme un ajout gratuit. Chiffrez son poids et son coût d’exécution avant l’installation, par blocage de domaine, puis vérifiez son effet réel sur les Core Web Vitals de terrain dans la Search Console. Un outil non mesuré finit toujours par coûter plus cher que ce qu’il rapporte, parce que personne ne sait ce qu’il rapporte.
La facilité d’intégration et la variété des outils disponibles rendent tentant de superposer fonctionnalité sur fonctionnalité : un tag pour le suivi comportemental, un autre pour la publicité ciblée, un troisième pour une campagne. Chaque ajout, aussi séduisant soit-il, doit être envisagé en termes d’impact : du temps de chargement, des latences réseau, de la consommation processeur chez le visiteur. La question à poser n’est pas seulement de savoir si un outil apporte une valeur, mais s’il justifie son coût de performance, chiffre contre chiffre.
Dans le tumulte des opérations quotidiennes, des outils autrefois essentiels deviennent obsolètes ou dupliqués. Les équipes techniques ne sont pas toujours informées des changements de priorités du marketing ou du SEO, et des scripts inutilisés persistent pendant des années. Un suivi rigoureux, avec des métriques de performance détaillées, met ces déséquilibres en lumière et produit des gains immédiats à la suppression d’outils redondants. C’est une problématique que nous abordons systématiquement dans nos prestations de monitoring de la performance, où le nombre de domaines tiers est suivi comme une métrique à part entière.
Il ne suffit pas de penser à l’ajout de nouvelles fonctionnalités, il faut planifier leur maintenance et leur retrait, ce qui suppose une collaboration entre développement, marketing et SEO, et une date de fin inscrite à la pose de chaque tag. Cette réflexion anticipée prévient les problèmes avant qu’ils ne surviennent, et garantit que le site reste rapide et aligné avec ses objectifs.
Chiffrer ce que coûte chaque outil de mesure et le rapporter à ce qu’il apporte, c’est le point de départ d’un audit de performance web ; reposer le tag, le différer ou le remplacer relève ensuite d’une optimisation de performance. Dans ce jeu délicat, la performance et la mesure ne sont pas des ennemies, mais des partenaires qui exigent d’être arbitrées, et l’arbitrage commence par un chiffre.
