Pourquoi limiter les scripts d'analyse et de suivi

Pourquoi limiter les scripts d'analyse et de suivi

Je passe une grande partie de mon temps à auditer des sites web, et dans environ 90 % de ces audits, je trouve des scripts de suivi inutilisés. Des scripts que personne ne se souvient avoir ajoutés, des scripts qui suivent des données que personne ne lit, des scripts qui n'étaient "qu'un pixel de plus" ajoutés par le marketing il y a deux ans. Chacun semblait inoffensif à l'époque. Ensemble, ils ajoutent des secondes à chaque chargement de page.

Selon le rapport 2024 de Kaspersky sur le suivi web, un site web moyen compte aujourd'hui 48 trackers. Le Web Almanac 2025 montre que plus de 90 % des pages web incluent au moins un script tiers, et les 1 000 sites les plus visités déclenchent une médiane de 129 requêtes tierces sur ordinateur. Ce n'est pas une stratégie de suivi. C'est un problème de performance.

Dernière révision par Arjen Karel en mars 2026

Pourquoi les sites utilisent des scripts d'analyse et de suivi

Les scripts d'analyse et de suivi ont une véritable utilité. Google Analytics vous indique d'où viennent vos visiteurs. Le pixel Facebook suit les conversions publicitaires. Hotjar vous montre où les gens cliquent. Sans ces données, vous naviguez à l'aveugle.

Le problème n'est pas l'existence de ces outils. Le problème est que la plupart des sites chargent beaucoup plus de suivi que nécessaire. Des outils populaires comme Google Analytics, le pixel Facebook et les analyses Cloudflare ajoutent tous du JavaScript, des cookies et des requêtes HTTP. Et ils sont rarement le seul suivi sur la page.

Fait : Dans environ 90 % de tous les audits, je trouve des scripts de suivi inutilisés. Généralement, ces scripts sont injectés tardivement via un gestionnaire de balises ou un autre script tiers.

Quel est le poids de ces scripts ?

Tous les scripts de suivi ne se valent pas. Voici ce que les plus courants vous coûtent réellement :

• Google Analytics 4 (gtag.js) : 134 Ko compressé, 371 Ko non compressé. Chargé de manière asynchrone, il ne bloque donc pas le rendu, mais le JavaScript doit tout de même être analysé et exécuté sur le fil d'exécution principal.
• Google Tag Manager : ~33 Ko compressé pour la bibliothèque elle-même, plus tous les tags que vous y placez. Le conteneur médian fait environ 50 Ko. Un conteneur GTM vide ajoute environ 100 ms de délai. Huit balises de suivi à l'intérieur de GTM ajoutent environ 3 secondes en 3G rapide et 10 secondes en 3G lente.
• Pixel Facebook/Meta : 340 Ko non compressé (95 Ko compressé). C'est 7 fois plus volumineux que Google Analytics. Il effectue 4 requêtes HTTP avant de se terminer et ajoute 1,3 à 1,5 seconde à chaque chargement de page.
• Plateformes de gestion du consentement : OneTrust peut ajouter de 124 à 347 Ko selon la configuration. Dans un cas, une bannière de consentement est devenue l'élément LCP, faisant passer le LCP de 1,43 s à 3,61 s.

Empilez GA4 + GTM + le pixel Facebook + une bannière de consentement et vous obtenez environ 400 à 600 Ko de JavaScript de suivi avant même que votre propre code ne s'exécute. C'est souvent plus que le contenu entier de la page lui-même.

Comment les scripts de suivi affectent les Core Web Vitals

Largest Contentful Paint

Chaque script entre en compétition pour la bande passante réseau et le temps CPU lors du chargement de la page. Même les scripts asynchrones consomment de la bande passante qui pourrait être utilisée pour l'image LCP ou le CSS critique. Lorsque vous chargez 8 scripts de suivi aux côtés de votre image hero, vous forcez le navigateur à partager sa bande passante mobile limitée entre eux tous.

C'est particulièrement néfaste sur les réseaux mobiles. Le Web Almanac 2025 rapporte un temps de blocage total médian sur mobile de 1 916 ms (en hausse de 58 % par rapport à 2024). Une grande partie de ce blocage provient du JavaScript tiers. Vous pouvez différer vos scripts, mais ils continuent de concourir pour les ressources une fois qu'ils commencent à se charger.

Interaction to Next Paint

L'Interaction to Next Paint (INP) est là où les scripts de suivi font le plus de dégâts. Le Web Almanac 2024 a révélé que le délai de présentation (presentation delay) est le principal responsable d'un mauvais INP, et les scripts qui en sont la cause sont les outils de suivi du comportement, les fournisseurs de consentement et les pixels publicitaires.

De nombreux scripts de suivi continuent de fonctionner bien après le chargement de la page. Google Analytics peut être configuré pour suivre chaque clic. Les outils de cartes de chaleur (heatmap) comme Hotjar écoutent chaque mouvement de souris. Chacun de ces écouteurs d'événements ajoute du temps de traitement aux interactions de l'utilisateur. Lorsqu'un visiteur clique sur un bouton et que votre code prend 50 ms pour le gérer, mais que trois scripts de suivi déclenchent également des écouteurs d'événements qui ajoutent 150 ms supplémentaires, l'interaction semble lente.

Les chiffres parlent d'eux-mêmes : 77 % de toutes les pages mobiles réussissent l'INP, mais seulement 53 % des 1 000 sites web les plus visités le font. Ces sites de premier plan ont un JavaScript plus complexe et davantage de scripts tiers. Si vous voulez garder vos pages réactives, les scripts de suivi sont le premier élément à examiner.

Time to First Byte et surcharge des cookies

Chaque script de suivi peut placer ses propres cookies. Les cookies individuels sont petits (une médiane de 40 octets selon le chapitre sur les cookies du Web Almanac 2025) mais leur impact collectif s'additionne car les données des cookies sont envoyées avec chaque requête HTTP. Si votre site définit 4 Ko de cookies et charge 39 ressources, cela représente 156 Ko de données d'envoi supplémentaires à travers ces requêtes.

Lorsque le total des données des cookies dépasse environ 1 500 octets, les en-têtes de requête ne tiennent plus dans un seul paquet TCP. Cela force des allers-retours supplémentaires, augmentant directement votre Time to First Byte lors des navigations ultérieures et des chargements de ressources statiques.

Cumulative Layout Shift

Les bannières de consentement sont les pires coupables ici. Lorsqu'une bannière de consentement aux cookies s'affiche tardivement et pousse le contenu de la page vers le bas, elle provoque un layout shift (décalage de mise en page). Certaines plateformes de consentement injectent de grands arbres DOM (plus de 200 nœuds) qui entraînent un reflow de la page. Dans un cas documenté, une bannière de consentement était l'élément LCP pour 50 % des pages vues car elle s'affichait par-dessus le contenu réel.

Stratégies pour un suivi plus intelligent

Auditez ce que vous utilisez réellement

Ouvrez votre gestionnaire de balises et examinez chaque balise. Pour chacune, demandez-vous : qui lit ces données ? Quand ont-elles été vérifiées pour la dernière fois ? Si personne ne peut répondre, supprimez-la. Je trouve régulièrement des balises pour des outils de test A/B provenant de campagnes terminées il y a des mois, des pixels pour des plateformes publicitaires que l'entreprise n'utilise plus, et des implémentations d'analyse en double (à la fois GA4 via GTM et un gtag.js codé en dur).

Retardez les scripts non essentiels

Tout n'a pas besoin de se charger à l'affichage de la page. Personne n'a jamais été déçu qu'un script de carte de chaleur prenne 3 secondes pour commencer à enregistrer. Déclenchez les balises d'analyse et de suivi sur l'événement Window Loaded ou, encore mieux, différez-les jusqu'à ce que l'utilisateur interagisse avec la page. Les tests d'AnalyticsMania ont montré que retarder le déclenchement des balises de 1,5 seconde après le chargement de la page a permis d'économiser 6 secondes en 3G lente.

// Load analytics only after first user interaction
const events = ['click', 'scroll', 'mousemove', 'touchstart'];
const loadAnalytics = () => {
    events.forEach(e => document.removeEventListener(e, loadAnalytics));
    // Load your analytics script here
    const script = document.createElement('script');
    script.src = 'https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX';
    document.head.appendChild(script);
};
events.forEach(e => document.addEventListener(e, loadAnalytics, {once: true}));

Utilisez l'API Beacon pour les événements personnalisés

Si vous envoyez des événements d'analyse personnalisés (soumissions de formulaires, clics sur des boutons, profondeur de défilement), utilisez navigator.sendBeacon() au lieu de XMLHttpRequest. L'API Beacon envoie des données de manière asynchrone sans bloquer le fil d'exécution principal et a la garantie de se terminer même pendant la navigation sur la page. Ceci est particulièrement important pour maintenir un INP bas sur les interactions qui déclenchent des appels d'analyse.

// Send analytics data without blocking the interaction
document.querySelector('.buy-button').addEventListener('click', (e) => {
    // Use sendBeacon - non-blocking, survives page navigation
    navigator.sendBeacon('/analytics', JSON.stringify({
        event: 'purchase_click',
        timestamp: Date.now()
    }));
});

Envisagez des alternatives côté serveur

Le moyen le plus efficace d'éliminer le JavaScript de suivi est de ne pas le charger du tout. Cloudflare Zaraz déplace l'exécution des analyses vers l'edge, remplaçant les scripts du gestionnaire de balises côté client par une balise web (beacon) légère. Les conteneurs GTM Server-Side permettent à votre serveur de transférer les données aux fournisseurs d'analyse sans qu'aucun JavaScript tiers n'atteigne le navigateur. Ces approches demandent plus d'efforts à mettre en place mais leur impact sur les performances est proche de zéro.

Pour des besoins plus simples, des alternatives légères comme Plausible (moins de 1 Ko) ou Umami (environ 2 Ko) fournissent des analyses de trafic pour une fraction du coût de 134 Ko de GA4.

À quoi ressemble une bonne configuration

Sur l'ensemble des sites surveillés par CoreDash, les pages chargeant moins de 5 scripts tiers réussissent l'INP à environ 88 %, contre 64 % pour les pages en chargeant 15 ou plus. La différence au niveau du LCP est tout aussi évidente : moins de requêtes concurrentes signifie que le navigateur peut prioriser ce qui compte vraiment pour le visiteur.

Vous n'avez pas besoin de supprimer tout le suivi. Vous devez être intentionnel sur ce que vous chargez, quand vous le chargez, et si quelqu'un utilise réellement les données. Commencez par auditer votre gestionnaire de balises. Supprimez ce dont vous n'avez pas besoin. Retardez ce que vous conservez. Utilisez le Real User Monitoring pour vérifier l'amélioration des données sur le terrain (field data), car les tests en laboratoire ne vous montreront pas une image complète de la façon dont les scripts de suivi interagissent avec les conditions réseau réelles et le comportement réel des utilisateurs.