Mesurer est indispensable : sans analytics, on ne sait pas d’où viennent les visiteurs, ce qu’ils font, quelles campagnes fonctionnent ni où le parcours d’achat se rompt. Mais les outils de mesure ne sont pas gratuits pour ceux qui visitent le site. Chaque script d’analyse, chaque pixel publicitaire, chaque outil d’enregistrement de sessions ajoute du code à télécharger et à exécuter, des connexions vers d’autres domaines et du travail pour le processeur de l’appareil. Sur beaucoup de sites, la somme de ces outils pèse plus lourd que le site lui-même.
Le paradoxe saute aux yeux : les outils qu’on utilise pour comprendre pourquoi les utilisateurs partent peuvent être l’une des raisons pour lesquelles ils partent. Dans cet article, nous voyons ce que coûte vraiment le suivi, comment gouverner un tag manager, ce que change le suivi côté serveur, quand les outils d’analyse plus légers ont du sens et comment mesurer l’impact des outils de mesure.
Le coût du suivi
Un script d’analytics moderne pèse plusieurs dizaines de kilo-octets compressés, souvent plus de cent, et son coût ne s’arrête pas au téléchargement : il doit être analysé et exécuté, il enregistre des gestionnaires pour les événements de la page, il envoie des requêtes réseau à chaque interaction significative. Multiplié par le nombre d’outils présents (analytics, publicité, pixels sociaux, heatmaps, tests A/B), le total atteint facilement un demi-mégaoctet de JavaScript, comme nous l’avons vu dans l’article sur les scripts tiers.
L’effet sur les Core Web Vitals est de deux ordres. Pendant le chargement, les scripts se disputent la bande passante et le thread principal avec les ressources de la page, et peuvent retarder le LCP. Après le chargement, beaucoup d’outils écoutent les clics, les défilements et les mouvements de souris pour les enregistrer : chaque interaction de l’utilisateur déclenche aussi leur code, et l’INP en souffre. Les outils d’enregistrement de sessions, qui reconstituent chaque modification de la page, sont en général les plus lourds de ce point de vue.
Gouverner le tag manager
Le tag manager est l’outil qui permet au marketing d’ajouter et de modifier des codes de suivi sans passer par les développeurs. C’est pratique, et c’est pourquoi il devient souvent l’endroit où le poids s’accumule : des tags ajoutés pour une campagne et jamais retirés, des outils essayés pendant un mois puis oubliés, le même outil installé deux fois, une fois dans le tag manager et une fois par un plugin du CMS.
Une revue périodique du conteneur remet de l’ordre. Pour chaque tag, il est utile de savoir qui l’a demandé, à quoi il sert, si les données qu’il collecte sont réellement utilisées et jusqu’à quand il est nécessaire. Les tags sans réponse à ces questions peuvent être mis en pause puis, après quelques semaines pendant lesquelles personne ne les regrette, supprimés. La configuration compte aussi : beaucoup de tags peuvent se déclencher quand la page a fini de charger, ou après quelques secondes, plutôt qu’au début, sans perdre de données significatives.
- Analytics principal : au chargement, car il doit mesurer même ceux qui repartent aussitôt.
- Pixels de conversion publicitaires : sur les pages de conversion, pas sur toutes les pages s’ils ne servent pas au remarketing.
- Heatmaps et enregistrements : seulement sur un pourcentage de sessions et sur les pages analysées, le temps nécessaire.
- Chat et widgets : à la première interaction ou après quelques secondes, comme dans la technique du report du JavaScript.
Tests A/B et écran blanc
Un cas particulier mérite l’attention : les outils de test A/B qui modifient la page dans le navigateur. Pour éviter que l’utilisateur voie la version d’origine un instant avant la variante, beaucoup proposent un extrait de code qui masque toute la page jusqu’à ce que le script du test soit chargé et ait appliqué ses modifications. Si le script arrive en retard, la page reste invisible, pendant un délai maximal qui peut atteindre quelques secondes. L’effet sur le LCP est direct et souvent lourd, et il touche tous les visiteurs, pas seulement ceux du test. Les alternatives : limiter l’extrait aux pages testées, réduire le délai maximal, ou exécuter les tests côté serveur, où la variante est décidée avant l’envoi de la page.
Le suivi côté serveur
Le suivi côté serveur déplace une partie du travail du navigateur vers un serveur contrôlé par le site. Au lieu de charger dans le navigateur les scripts de chaque fournisseur, la page envoie les événements à un point d’accès unique, en général un sous-domaine du site, où un conteneur côté serveur les reçoit, les traite et les transmet aux différents services d’analytics et de publicité.
Les bénéfices en matière de performance sont concrets : moins de scripts dans le navigateur, moins de connexions vers des domaines externes, moins de travail sur l’appareil de l’utilisateur. Il y a aussi des bénéfices de maîtrise, car le site décide quelles données transmettre à chaque fournisseur. Les coûts sont l’infrastructure du serveur de suivi, qu’il faut héberger et maintenir, et une configuration plus complexe. Surtout, le suivi côté serveur n’est pas un moyen de contourner le consentement : les règles de confidentialité s’appliquent de la même façon, et les données ne doivent être transmises que si l’utilisateur a donné son consentement pour cette finalité, comme l’explique l’article sur les bandeaux de consentement.
Les outils d’analytics légers
Pour beaucoup de sites, surtout les sites éditoriaux, institutionnels et de services, les besoins de mesure sont simples : les visites, les pages les plus consultées, les sources de trafic, quelques objectifs de conversion. Pour ces cas, il existe des outils d’analytics conçus pour être légers et respectueux de la vie privée, avec des scripts de quelques kilo-octets, souvent sans cookies, certains pouvant être auto-hébergés. Ils offrent moins de fonctionnalités que les outils les plus répandus, mais pour beaucoup de sites ils suffisent, et ils simplifient aussi la gestion du consentement.
Le choix n’a pas à être radical. Beaucoup de sites gardent l’outil principal pour les besoins de marketing et de publicité, en allégeant sa configuration, et ajoutent leurs propres mesures, comme un système de Real User Monitoring, pour la performance. Le critère est toujours le même : chaque donnée collectée doit valoir le coût qu’elle impose aux visiteurs.
Interactions et INP
Le suivi des événements, comme les clics sur les boutons, les envois de formulaires et le défilement de la page, ajoute du travail à chaque interaction. Quelques précautions limitent l’impact. Les données doivent être envoyées avec des méthodes non bloquantes, comme navigator.sendBeacon, et une fois que l’interface a répondu à l’utilisateur. Les événements très fréquents, comme le défilement, doivent être regroupés plutôt qu’envoyés un par un. Et le suivi automatique qui écoute chaque clic de la page ne doit être activé que si les données sont vraiment nécessaires.
pulsante.addEventListener( 'click', () => {
aggiornaInterfaccia(); // 1. d’abord, répondre à l’utilisateur
requestAnimationFrame( () => setTimeout( () => {
navigator.sendBeacon( '/eventi', JSON.stringify( { evento: 'aggiunta_carrello' } ) );
}, 0 ) ); // 2. ensuite le suivi, après le rendu
} );Le moment où l’on charge le script d’analytics principal mérite aussi l’attention. L’insérer de façon asynchrone, après les ressources critiques et sans l’anticiper par un preload qui le mettrait en concurrence avec le CSS et l’image principale, permet de mesurer presque toutes les visites sans toucher au premier rendu. Les rares visites qui se terminent avant que le script démarre sont, en règle générale, un prix acceptable au regard du bénéfice pour toutes les autres.
Le cas de WordPress
Sur les sites WordPress, le suivi vient souvent de plusieurs sources à la fois : un plugin d’analytics, le tag manager inséré par le thème, un plugin publicitaire avec son propre pixel, un plugin e-commerce qui ajoute ses propres événements. La première étape consiste à faire l’inventaire, en regardant dans le panneau Network des DevTools toutes les requêtes vers les domaines d’analytics et de publicité, et en remontant à ce qui les génère. Les doublons et les outils oubliés sont très fréquents. La deuxième étape consiste à centraliser : un seul point d’insertion, en général le tag manager, au lieu de codes dispersés entre le thème et les plugins.
Mesurer le coût des outils de mesure
Le coût du suivi se mesure en comparant la page avec et sans les scripts. Dans les DevTools de Chrome, on peut bloquer des domaines un par un depuis le panneau Network et recharger ; des outils comme WebPageTest permettent de le faire de façon reproductible, en comparant le LCP, le Total Blocking Time et le poids de la page. Le panneau Performance, pendant une interaction, montre quelle part du travail revient aux scripts de suivi. Sur le terrain, comparer les métriques avant et après la suppression ou le report d’un tag, par exemple avec les données quotidiennes d’un système de monitoring, donne la mesure la plus fiable.
Une règle pour les nouveaux tags
Nettoyer le tag manager une fois est utile ; l’empêcher de se remplir à nouveau est plus important. Quelques règles simples, convenues entre marketing et développement, fonctionnent bien. Chaque nouveau tag a un responsable, un objectif écrit et une date de revue. Avant l’activation, on mesure son poids et son effet sur une page de test. Les tags temporaires, comme ceux des campagnes, ont une date d’expiration. Et le nombre total d’outils actifs reste dans une limite convenue, comme dans un budget de performance : pour en ajouter un, on envisage d’en retirer un autre. Pas besoin de procédures complexes, seulement un tableau partagé et l’habitude de le consulter.
Moins d’outils, de meilleures données
Il y a un bénéfice secondaire qui surprend souvent : réduire les outils améliore aussi la qualité des données. Deux outils d’analytics qui mesurent la même chose donnent des chiffres différents et alimentent des discussions inutiles ; les tags en double gonflent les conversions ; les scripts qui se chargent tard manquent les visites les plus courtes, celles des personnes qui repartent aussitôt. Une configuration essentielle et bien documentée produit des chiffres plus cohérents et plus faciles à interpréter, et libère du temps pour analyser les données au lieu de les réconcilier.
Un exemple
Un site de formation en ligne a un tag manager avec 34 tags actifs, accumulés au fil de cinq ans de campagnes. L’inventaire révèle l’outil d’analytics installé deux fois, six pixels de plateformes publicitaires qui ne sont plus utilisées, un outil de heatmaps actif sur toutes les pages et toutes les sessions, et un extrait de test A/B qui masque la page jusqu’à quatre secondes, alors qu’aucun test n’est en cours depuis des mois. Après le nettoyage, il reste 11 tags : l’analytics principal au chargement, les pixels des campagnes actives uniquement sur les pages d’inscription, les heatmaps sur dix pour cent des sessions et seulement sur les pages de cours, le chat à la première interaction. Le JavaScript tiers diminue des deux tiers, le LCP mobile gagne presque une seconde grâce à la suppression de l’extrait de test A/B, et les chiffres de conversion, auparavant gonflés par les tags en double, redeviennent cohérents avec ceux du système de gestion.
En bref
Les analytics, les pixels et les outils d’analyse du comportement sont nécessaires, mais ils pèsent sur le chargement et sur les interactions, souvent plus que le site lui-même. Les gouverner, c’est faire l’inventaire des tags, retirer ceux qui ne servent plus et les doublons, déclencher au bon moment ceux qui ne sont pas nécessaires tout de suite, limiter les heatmaps et les enregistrements à une part des sessions, et empêcher les tests A/B de masquer la page.
Le suivi côté serveur réduit le travail dans le navigateur, au prix d’une infrastructure supplémentaire et sans changer les obligations de consentement ; les outils d’analytics légers sont un choix raisonnable pour beaucoup de sites aux besoins simples. Dans tous les cas, le coût des outils de mesure doit lui-même être mesuré : c’est le seul moyen de décider quelles données valent le temps qu’elles font attendre les visiteurs.
