Suivi des Core Web Vitals avec les outils analytics : le guide

La question qui revient le plus souvent quand on parle performance web, ce n'est pas "comment améliorer mon LCP" — c'est "comment je sais, dans un mois, si je l'ai vraiment amélioré ?". Et là, la réponse honnête fait mal : la plupart des équipes qui surveillent leurs Core Web Vitals regardent encore un rapport Search Console statique, une fois par trimestre, en se disant que ça suffira. Ça ne suffit pas.

Le suivi des Core Web Vitals avec les outils analytics, c'est le chaînon manquant entre un audit Lighthouse ponctuel et une vraie stratégie de performance continue. Dans ce guide, je vous montre comment je procède réellement sur les sites que je gère, avec le code, les seuils, les pièges que j'ai rencontrés, et pourquoi la majorité des articles sur le sujet passent à côté du vrai problème.

Pourquoi vos rapports Core Web Vitals ne vous disent rien d'utile

Le problème avec la plupart des outils de test gratuits, c'est qu'ils répondent à une question que personne ne se pose vraiment. "Est-ce que mon LCP est bon aujourd'hui, à 14h32, depuis un datacenter situé en Virginie ?" Voilà ce que vous dit un test Lighthouse lancé à la main. Ce n'est pas inintéressant. Mais ce n'est pas ce qui décide de votre classement.

Google évalue vos Core Web Vitals à partir de données terrain, collectées auprès de vos vrais visiteurs, sur leurs vrais appareils, avec leurs vraies connexions. Ces données alimentent le rapport CrUX, que vous consultez dans Search Console. Sauf que ce rapport vous donne une photo mensuelle agrégée à l'échelle du site entier. Dès que vous voulez savoir pourquoi votre INP se dégrade, vous êtes bloqué.

La différence entre données terrain et données labo

Je le répète à chaque audit parce que c'est la confusion numéro un que je rencontre :

• Données labo (Lighthouse, PageSpeed Insights en mode "analyse") : environnement contrôlé, réseau simulé, CPU bridé. Reproductibles, pratiques pour déboguer, mais elles ne représentent personne en particulier.
• Données terrain (CrUX, RUM, votre propre instrumentation) : vos utilisateurs réels. C'est ce que Google regarde pour le classement, et c'est ce qui varie selon l'appareil, la géolocalisation et l'état du réseau.

Un site peut avoir un LCP labo de 1,2 seconde et un LCP terrain de 4,8 secondes. Ça m'est arrivé sur un projet e-commerce : le héros se chargeait vite sur fibre, mais un script tiers de chat bloquait le rendu sur mobile en 4G. Le labo ne le voyait pas. Les utilisateurs, si.

C'est exactement pour ça qu'un outil analytics bien configuré change la donne : il vous ramène du terrain, segmenté, en continu.

Envoyer vos Core Web Vitals dans GA4 : le code qui marche

GA4 ne collecte pas les Core Web Vitals nativement. Point. Vous devez les envoyer vous-même. La méthode qui tient en production repose sur la bibliothèque web-vitals, et il faut être précis sur les paramètres envoyés, sinon vous obtenez des événements inexploitables.

La bibliothèque web-vitals en pratique

Voici la structure que j'utilise. Elle envoie chaque métrique comme un événement GA4 personnalisé, avec la valeur, l'identifiant de la métrique et son évaluation (bon / à améliorer / mauvais) :

import { onLCP, onINP, onCLS } from 'web-vitals';

function envoyerVersGA4({ name, value, id, rating }) {
  gtag('event', name, {
    value: Math.round(name === 'CLS' ? value * 1000 : value),
    metric_id: id,
    metric_rating: rating,
    non_interaction: true
  });
}

onLCP(envoyerVersGA4);
onINP(envoyerVersGA4);
onCLS(envoyerVersGA4);

Deux détails qui font la différence entre un setup qui sert et un setup qui pourrit un compte GA4 :

1. Le paramètre non_interaction: true évite de fausser votre taux de rebond. Sans lui, l'envoi de la métrique compte comme une interaction et votre taux de rebond tombe artificiellement à zéro. Je l'ai vu sur un site, et ça a faussé six mois de reporting avant que quelqu'un s'en aperçoive.
2. Les noms d'événements doivent être exacts : LCP, INP, CLS. GA4 est sensible à la casse dans certains contextes de rapport.

Une fois les événements reçus, créez dans GA4 des dimensions personnalisées pour metric_rating et metric_id. Sans elles, vous ne pourrez segmenter ni par seuil ni par page. C'est l'étape que 80 % des tutos oublient de détailler — et c'est celle qui rend l'ensemble exploitable.

Segmenter pour prioriser

Une métrique globale ne dit pas quoi corriger. Une métrique segmentée, oui. Dans GA4, explorez vos événements INP en croisant :

• Le type d'appareil (mobile vs desktop) — c'est presque toujours là que se cache l'écart réel.
• La source de trafic, parce qu'une campagne sur un réseau social amène souvent une audience sur des connexions plus lentes.
• Le pays, quand votre base d'utilisateurs est internationale.
• Le page_path, pour isoler les gabarits de page problématiques.

Sur un site média, cette seule segmentation m'a permis de comprendre que 60 % des INP mauvais venaient d'un unique gabarit d'article surchargé en publicités, pas du site entier. Corriger ce gabarit a fait passer le taux de bonnes expériences mobiles de 68 % à 91 % en cinq semaines. Sans segmentation, j'aurais optimisé au hasard.

Comparer les approches : GA4, CrUX et outils RUM

Il n'y a pas une solution, il y a des compromis. Voici comment je choisis selon le contexte du projet :

Approche	Coût	Granularité	Idéal pour	Limite principale
Search Console / CrUX	Gratuit	Agrégée, 28 jours	Vue macro, conformité Google	Aucun détail par utilisateur ou par page fine
GA4 + web-vitals	Gratuit	Bonne, échantillonnée	Corréler perf et comportement	Échantillonnage, latence de traitement
GA4 + export BigQuery	Payant à l'usage	Très fine	Analyse avancée, jointures	Coût qui grimpe vite, besoin de SQL
Outils RUM tiers	Abonnement	Très fine + alerting	Surveillance continue, régressions	Budget, un outil de plus à maintenir

Franchement, si vous débutez, commencez par GA4 seul. Ajoutez BigQuery quand vous avez une vraie question analytique à laquelle GA4 ne répond pas. Un outil RUM tiers se justifie surtout quand vous gérez plusieurs sites ou que la performance est un enjeu commercial direct — je pense au e-commerce, où 100 ms de LCP en plus se traduisent par des paniers abandonnés.

Le piège du combo GA4 + BigQuery, c'est le coût. Les requêtes non optimisées sur des tables volumineuses peuvent faire grimper la facture à trois chiffres en une soirée d'exploration. Partitionnez vos tables par date et filtrez toujours sur cette colonne. Ça paraît basique. J'ai quand même vu une équipe brûler son budget mensuel en une après-midi.

Surveillance, alertes et régressions : ce que personne ne configure

Détecter une régression de performance le jour où elle arrive, ce n'est pas de la magie, c'est de l'alerting. Et c'est la partie que presque tout le monde saute.

Comment détecter une régression avant vos utilisateurs

Trois mécanismes, du plus simple au plus robuste :

1. Une comparaison de périodes dans GA4, enregistrée en rapport personnalisé, que vous consultez chaque semaine. Simple, mais passif.
2. Une audience GA4 basée sur les utilisateurs dont la métrique a le rating "mauvais", activée en audience prédictive. Elle vous sert aussi pour du remarketing ciblé si votre performance se dégrade.
3. Des alertes automatiques via votre outil RUM ou un job planifié qui interroge l'API et vous notifie en cas de franchissement de seuil sur 24 heures.

Le délai est votre ennemi. Une métrique Core Web Vitals remontée dans GA4 met souvent plusieurs heures à apparaître dans vos rapports, et l'agrégation CrUX est mensuelle. Concrètement, si vous déployez une régression un lundi matin, vous pouvez la découvrir le mercredi. D'où l'intérêt d'un outil RUM qui alerte en quasi temps réel quand c'est critique pour votre activité.

Un mot sur l'échantillonnage : GA4 échantillonne au-delà d'un certain volume d'événements dans les explorations. Sur un gros site, vous ne verrez jamais 100 % de vos données, même si vous les envoyez toutes. Ce n'est pas un bug, c'est un choix de conception, et il faut en tenir compte avant de tirer des conclusions sur un segment étroit.

Les seuils à retenir, sans se tromper

LCP : bon en dessous de 2,5 secondes, à améliorer jusqu'à 4 secondes, mauvais au-delà. INP : bon sous 200 ms, mauvais au-delà de 500 ms. CLS : bon sous 0,1, mauvais au-dessus de 0,25. Ces seuils sont ceux que Google applique dans ses évaluations, et ce sont eux que vous devez coder dans vos ratings côté instrumentation pour rester cohérent.

Les pièges qui font abandonner après trois mois

J'ai monté ce type de dispositif sur plusieurs projets, et j'ai fait toutes les erreurs possibles avant d'arriver à quelque chose de tenable. Voici celles qui reviennent :

• Confondre labo et terrain. Vous corrigez un score Lighthouse, vous êtes content, et le terrain ne bouge pas parce que le problème était ailleurs.
• Mesurer sans agir. Un dashboard que personne ne regarde ne sert à rien. Fixez un rituel : 20 minutes par semaine, un segment, une action.
• Ignorer les scripts tiers. La majorité des dégradations d'INP viennent d'eux, pas de votre code. Un tag manager mal géré peut ruiner un INP correct.
• Oublier le mobile. Sur la plupart des sites que je vois, l'écart mobile/desktop est le premier facteur explicatif. Regardez le mobile en priorité.

Et avouons-le, la mise en place initiale prend du temps. La première fois, j'ai passé une bonne semaine à comprendre pourquoi mes événements n'arrivaient pas dans GA4 — un mélange de nommage et d'ordre de chargement du script. Maintenant, c'est une journée, parce que je connais les pièges.

Ce que je retiens après tout ce temps

Le suivi des Core Web Vitals avec les outils analytics n'a de valeur que s'il déclenche une décision. Un événement LCP dans GA4 sans segmentation, sans seuil et sans personne pour le regarder, c'est de la donnée morte. Le passage à une vraie surveillance, c'est le moment où vous arrêtez de mesurer pour cocher une case et où vous commencez à surveiller pour corriger.

Si je ne devais garder qu'une seule chose de tout ce dispositif, ce serait le croisement entre performance et comportement : un utilisateur dont le LCP est mauvais convertit-il moins que les autres ? Quand la réponse est oui — et elle l'est presque toujours —, la performance cesse d'être un sujet technique et devient un sujet commercial. C'est là, et pas avant, que les budgets se débloquent.

La vraie question n'est donc peut-être pas "quel outil choisir", mais "qui, dans votre équipe, regardera ces chiffres lundi matin".