Vérifier les Core Web Vitals site par site dans l’interface de PageSpeed Insights ne tient pas la charge au-delà de quelques clients : un monitoring pour plusieurs sites exige des seuils d’alerte propres à chaque site, pas un seuil absolu unique, et une méthode pour les sites dont le trafic ne suffit jamais à générer de données CrUX exploitables.
Sommaire
Pourquoi la vérification manuelle site par site ne scale pas
Consulter PageSpeed Insights un par un pour dix ou vingt sites clients prend du temps, ne garde aucun historique structuré au-delà de l’interface elle-même, et repose sur la mémoire de la personne qui doit penser à repasser régulièrement sur chaque site. Passé une poignée de sites suivis, cette méthode devient le premier facteur de retard de détection d’une régression de performance, un problème distinct de l’audit ponctuel détaillé dans notre guide sur l’audit et l’optimisation de l’INP.
Consolider les données de terrain via l’API CrUX
L’API CrUX permet d’interroger par requête programmatique les métriques de terrain (LCP, INP, CLS, et leur historique) pour un ou plusieurs domaines à la fois, sans passer par l’interface de PageSpeed Insights. Sur un portefeuille de sites, cela permet de construire une extraction périodique automatisée, stockée dans un tableur ou une base simple, plutôt que de dépendre d’une vérification manuelle et répétitive.
Ce que cela change concrètementUne extraction hebdomadaire programmée sur l’ensemble du portefeuille détecte une dégradation dans la semaine qui suit un déploiement client, au lieu d’attendre la prochaine réunion de suivi mensuelle où le problème est découvert après coup.
Seuils par site, pas un seuil universel
Le seuil « Bon » publié par Google pour chaque métrique (LCP, INP, CLS) est un repère absolu utile pour situer un site dans l’écosystème, mais un seuil d’alerte opérationnel pour un portefeuille multi-sites doit être calé sur la baseline propre à chaque site, pas sur ce seuil universel. Un site avec un LCP terrain historiquement stable à 2,1 secondes qui grimpe soudainement à 2,6 secondes reste dans la zone « Bon » au sens Google, mais représente une dégradation réelle de 24% qui mérite d’être investiguée avant qu’elle ne franchisse le seuil absolu.
Pourquoi la baseline diffère autant d’un site à l’autre
La répartition d’appareils (mobile/desktop), la répartition géographique du trafic, et le type de contenu (page produit riche en images contre page de blog texte) font que deux sites parfaitement optimisés peuvent avoir des baselines CrUX naturellement différentes. Comparer tous les sites du portefeuille au même seuil absolu masque les dégradations relatives propres à chacun.
Le cas des sites sans données CrUX exploitables
Un site à faible trafic n’atteint jamais le volume minimum requis par CrUX pour publier des données de terrain fiables, que ce soit via l’API ou l’interface PageSpeed Insights. Pour ces sites, souvent les plus nombreux dans un portefeuille de PME ou d’indépendants, le monitoring doit reposer sur des tests de laboratoire programmés (Lighthouse en ligne de commande ou via l’API PageSpeed Insights, exécuté à intervalle régulier sur les mêmes pages clés) plutôt que sur une donnée de terrain qui n’existera jamais.
La limite à connaître : un test de labo répété varie d’une exécution à l’autre selon la charge du serveur au moment du test, il faut donc suivre une tendance sur plusieurs exécutions consécutives, pas une seule mesure isolée, pour distinguer un vrai changement d’un simple bruit de mesure.
Construire des alertes qui ne noient pas sous le bruit
- Définir la baseline par site avant toute alerteCalculez la moyenne et la variation normale de chaque métrique sur plusieurs semaines avant de fixer un seuil d’écart déclencheur.
- Alerter sur l’écart relatif, pas seulement l’écart absoluUne dégradation de 20% par rapport à la baseline du site mérite un signalement même si la métrique reste dans la zone « Bon » du seuil Google.
- Séparer sites avec données CrUX et sites en labo seulLes deux nécessitent des règles d’alerte différentes : tendance sur plusieurs semaines pour le terrain, tendance sur plusieurs exécutions rapprochées pour le labo.
- Prioriser l’investigation par volume de trafic du site concernéSur un portefeuille large, traitez d’abord les alertes des sites à plus fort trafic, où l’impact SEO et business d’une dégradation est le plus significatif.
| Type de site | Source de données | Fréquence de contrôle |
|---|---|---|
| Fort trafic, données CrUX disponibles | API CrUX, historique par origine | Hebdomadaire, alerte sur écart relatif |
| Faible trafic, pas de données CrUX | Lighthouse programmé sur pages clés | Tendance sur plusieurs exécutions rapprochées |
Un monitoring qui s’adapte à chaque site, pas l’inverse
Superviser les Core Web Vitals de plusieurs sites simultanément exige de sortir du réflexe du seuil absolu unique et de la vérification manuelle répétée : une baseline propre à chaque site, une source de données adaptée à son volume de trafic, et des alertes calées sur l’écart relatif détectent une régression bien avant qu’elle ne devienne visible dans un rapport mensuel classique.
Faut-il utiliser le même seuil d’alerte pour tous les sites d’un portefeuille ?
Non, chaque site a une baseline naturelle différente selon son trafic et son type de contenu. Une alerte doit se déclencher sur l’écart relatif à la baseline du site, pas seulement sur le seuil absolu publié par Google.
Comment monitorer les Core Web Vitals d’un site à faible trafic sans données CrUX ?
Par des tests de laboratoire programmés (Lighthouse ou API PageSpeed Insights) exécutés régulièrement sur les mêmes pages, en suivant une tendance sur plusieurs exécutions plutôt qu’une mesure isolée.
L’API CrUX peut-elle interroger plusieurs sites en une seule fois ?
Elle permet des requêtes programmatiques par domaine, ce qui rend possible une extraction automatisée et périodique sur l’ensemble d’un portefeuille de sites, plutôt qu’une vérification manuelle site par site.
Pourquoi un test Lighthouse répété peut-il donner des résultats différents à chaque exécution ?
Un test de labo dépend de la charge du serveur et des conditions au moment précis du test ; il faut suivre une tendance sur plusieurs exécutions consécutives pour distinguer un vrai changement d’un simple bruit de mesure.
À propos de l’auteur
Aymeric Maingé
Consultant SEO senior avec plus de 10 ans d’expérience, côté agence et annonceur. J’accompagne des sites de tout CMS sur des problématiques de performance technique et de suivi des Core Web Vitals à l’échelle d’un portefeuille de clients. Mon approche croise audit terrain, priorisation métier et recommandations actionnables. Faites appel à un conseil SEO freelance en performance pour structurer le suivi de vos sites.
