Un site e-commerce sur lequel on intervient a vu son LCP passer de 3,1 s à 2,4 s après avoir simplement retiré le tracking Google Analytics 4. Pas de refonte, pas de CDN supplémentaire. Juste la suppression de gtag.js et son remplacement par une instance Matomo auto-hébergée. Ce genre de résultat ne surprend que ceux qui n’ont jamais ouvert l’onglet Network des DevTools pendant un chargement de page.
On te dira que comparer Google Analytics et Matomo, c’est opposer un service gratuit ultra-puissant à une solution open source confidentielle. C’est rater le sujet. La vraie question, pour un responsable technique : à quel point ton outil d’analytics plombe les signaux de performance que Google utilise pour classer tes pages.
Le vrai poids de Google Analytics 4 sur le rendu
Quand on parle de la lourdeur de GA4, on pense immédiatement au poids du fichier. La bibliothèque gtag.js pèse environ 45 Ko compressés. Ce n’est pas négligeable, mais ce n’est pas le problème principal. Le vrai coût se joue sur deux fronts : la latence réseau et l’exécution JavaScript.
Chaque page charge d’abord le script, puis établit une connexion vers les serveurs de Google. Sur une connexion mobile moyenne, cette résolution DNS et cette poignée de main TLS ajoutent entre 200 et 400 ms avant même d’avoir émis le moindre événement. Ensuite, le navigateur exécute la bibliothèque, installe des observateurs sur les clics, le scroll, les changements d’état de l’historique. Ce travail occupe le thread principal au moment même où le navigateur tente de rendre les éléments visibles, ce qui repousse le LCP et dégrade l’INP.
Les sites qui activent les signaux Google (remarketing, rapports démographiques, suivi des conversions Google Ads) alourdissent encore la facture : des appels supplémentaires à doubleclick.net et googleadservices.com viennent concurrencer les requêtes métier. Le navigateur, avec ses six connexions simultanées par domaine, se retrouve à prioriser des appels marketing pendant que l’image produit attend son tour.
⚠️ Attention : Le simple fait d’activer « Mesure avancée » dans GA4 injecte des écouteurs d’événements sur les fichiers téléchargés, les clics sortants et la recherche du site. Sur nos mesures, l’INP grimpe d’une trentaine de millisecondes après activation, parfois plus sur les pages chargées en composants interactifs.
Notre analyse des Core Web Vitals le rappelle : chaque script tiers retarde la stabilité visuelle et la réactivité. GA4 ajoute par-dessus une instrumentation que peu d’équipes exploitent vraiment.
Matomo et la mesure sans consentement explicite
Contrairement à GA4, Matomo peut fonctionner sans cookie si vous activez le tracking anonyme. Pas de bannière de consentement obligatoire pour les cookies analytics exemptés, et donc zéro friction sur le chargement initial de la page. Le visiteur n’est pas bloqué par un pop-up, le navigateur n’a pas à gérer une callback post-consentement, et le tag manager ne s’emballe pas au DOMContentLoaded.
TTFB et requêtes first-party : pourquoi l’auto-hébergement change la donne
Un script d’analytics first-party, hébergé sur votre propre domaine, élimine la résolution DNS et la négociation TLS propres à un domaine tiers. L’appel au piwik.js ou matomo.js partage la même connexion HTTP/2 que vos assets métier. Le navigateur télécharge et exécute le script sans ouvrir de socket supplémentaire.
L’impact sur le TTFB se lit directement dans les logs serveur. Plutôt que de rediriger le visiteur vers un sous-domaine Google, le serveur d’origine traite une requête locale, souvent servie depuis le cache opcode si vous utilisez le plugin PHP officiel. Le temps de réponse tombe sous les 10 ms, contre une moyenne de 80 à 150 ms pour un appel à www.google-analytics.com selon la localisation du visiteur.
Ce n’est pas seulement une question de performance. C’est aussi une question de résilience. Quand les bloqueurs de pubs et les navigateurs orientés vie privée coupent les appels vers les domaines Google, vos données partent dans le vide. Avec une collecte first-party, vous récupérez les données de trafic que GA4 abandonne. Sur un site à audience technique, la perte de signal côté GA4 atteint régulièrement plusieurs dizaines de pourcents. Matomo en mode first-party les capte intégralement.
Même logique que pour le state management côté client : on ne garde que l’essentiel. C’est ce qu’on a documenté sur React et Zustand.
Les événements automatiques de GA4, ennemis de l’INP
L’INP mesure le temps de latence entre l’interaction de l’utilisateur (un clic, une frappe) et le prochain affichage visuel. Google recommande de rester sous les 200 ms. Le problème, c’est que les événements automatiques de GA4 transforment chaque clic sur un lien, chaque soumission de formulaire ou chaque téléchargement de fichier en un appel collect vers les serveurs de Google.
Ce traitement se produit au milieu du thread principal. Si le script met 150 ms à sérialiser les paramètres de l’événement et à émettre la requête, l’interaction suivante ne pourra pas être traitée avant la fin de cette tâche. Cumulé avec d’autres processus (recalcul du layout, exécution d’autres listeners), le dépassement du seuil de 200 ms devient systématique sur les pages un tant soit peu animées.
Le pire, c’est que ces données sont rarement exploitées. La plupart des sites ne regardent jamais les rapports sur les clics sortants ou les téléchargements de fichiers qu’ils ont pourtant activés. Ils paient le coût d’une instrumentation lourde pour des KPIs qu’ils ne consultent pas.
Désactiver ces événements automatiques fait gagner du temps de thread principal sans sacrifier la moindre information stratégique. Et quand on veut vraiment tracker un clic sur un bouton d’ajout au panier, on pose un petit écouteur maison, léger, sans dépendance au bridge gtag.
Notre migration vers Matomo : -400 ms de LCP, score Lighthouse 72 → 88
On a fait le test sur Responsive Mind il y a dix-huit mois. Avant migration, le site chargeait gtag.js en mode priorité basse, mais le script retardait quand même le load complet de la page et injectait une dizaine de requêtes supplémentaires sur chaque article. Résultat : un LCP autour de 2,8 s sur mobile et un INP qui flirtait avec les 250 ms dès qu’un visiteur déroulait un article contenant des illustrations lourdes.
On a installé Matomo sur un sous-domaine dédié, stats.responsivemind.fr, avec le tracking côté serveur via le tag manager intégré. Le script JS n’est plus qu’un fichier de 22 Ko servi depuis notre propre CDN, sans cookie stocké dans le navigateur. Les données de visite sont envoyées en POST asynchrone sur le même domaine, sans impact sur les requêtes critiques.
Les gains ont été immédiats. Le LCP a perdu 400 ms en moyenne, l’INP est retombé sous les 170 ms, et le score Performance Lighthouse est passé de 72 à 88. Mieux, nous avons découvert que 38 % de notre lectorat utilisait des bloqueurs de pubs ou des navigateurs qui coupent GA4. Matomo, en first-party, nous a rendu la visibilité sur ce trafic, ce qui a modifié notre compréhension des sujets les plus lus.
💡 Conseil : Configurez le tracking sans cookie et activez le « suivi par empreinte numérique » dans Matomo. Vous obtenez des données de session sans stocker d’identifiant chez le visiteur, ce qui simplifie la conformité RGPD.
Même raisonnement que dans notre comparaison Claude Code vs Cursor : moins de dépendances tierces, plus de contrôle sur ce qui s’exécute réellement chez le visiteur.
Le territoire où GA4 reste imbattable : Google Ads et BigQuery
Si vous gérez des campagnes Google Ads, l’intégration native entre GA4 et l’écosystème Google reste précieuse. L’import des conversions, les audiences partagées, la connexion avec BigQuery pour croiser données CRM et données comportementales, c’est le territoire de GA4. Matomo peut importer les coûts publicitaires et attribuer des conversions, mais la synchronisation demande du développement sur mesure.
De même, une équipe qui a déjà industrialisé ses rapports dans Looker Studio avec le connecteur GA4 natif aura du mal à reproduire la même fluidité avec Matomo, même si des connecteurs existent.
Pour autant, ces avantages ne justifient pas de pénaliser tous les visiteurs, y compris ceux qui viennent du SEO, avec un script d’analytics qui ralentit la page. Une architecture hybride se défend : Matomo pour le suivi global des visites, les Core Web Vitals et la mesure sans cookie, et un snippet GA4 allégé, chargé uniquement sur les landing pages de campagnes payantes. C’est plus lourd à maintenir, mais c’est la seule façon de ne pas sacrifier la performance sur l’autel de la mesure publicitaire.
Questions fréquentes
Matomo peut-il suivre les conversions Google Ads ?
Oui, via l’import manuel des coûts et l’intégration du paramètre gclid. Le suivi n’est pas aussi automatisé que dans GA4, et vous devrez configurer des objectifs personnalisés. L’exercice reste faisable pour un développeur, mais il demande une journée de travail si vous ne l’avez jamais fait.
Est-ce que Matomo impacte le budget crawl ? Non. Les appels de tracking sont émis côté client (ou serveur) en POST et ne génèrent aucune URL crawlable. Votre plan de site et votre maillage interne restent parfaitement lisibles par Googlebot, contrairement à ce qu’on observe avec certaines solutions qui génèrent des paramètres de requête en GET.
Peut-on utiliser Matomo et Google Analytics en parallèle ? Techniquement oui, mais vous dupliquez la charge pour le visiteur et compliquez la gouvernance des données. Si vous devez conserver GA4 pour les besoins publicitaires, cantonnez-le aux pages où il a une vraie utilité, et confiez le reste de la mesure à Matomo.
