On a vu un site e-commerce perdre 15 % de son trafic organique en deux semaines sans que personne ne s’en rende compte. La cause : un déploiement anodin qui a fait passer le LCP de 2,8 s à 5,4 s. Aucune alarme. Le client l’a découvert en ouvrant la Search Console un matin, avec le café froid et le regard qui reste bloqué sur la courbe rouge.
Si vous surveillez vos Core Web Vitals uniquement dans les rapports mensuels ou quand Google vous envoie une notification « régression du LCP », vous avez déjà pris du retard sur la performance qui coûte des positions. Une surveillance réellement intelligente ne se contente pas de comparer des chiffres : elle sait distinguer le bruit d’une vraie dégradation, et elle vous prévient avant que le crawl n’ait tout indexé.
Pourquoi la surveillance manuelle ne suffit plus
Sur un site qui déploie plusieurs fois par jour, le LCP peut fluctuer sans que personne ne touche au code. Un changement de tier CDN, une tâche cron qui réchauffe mal le cache, une campagne pub qui amène du trafic depuis des mobiles plus lents. Si vous attendez le rapport Search Console, le problème a déjà été digéré par les signaux de classement.
Le souci, ce n’est pas le manque d’outils. C’est que la plupart des dashboards Core Web Vitals qu’on branche affichent une météo du mois précédent. On a tous vu des captures Lighthouse avec le rond vert, mais personne ne regarde le p75 des données de champ remonter de 10 % en trois jours. Une alarme intelligente, c’est celle qui repère cette dérive sans que vous posiez les yeux sur un graphe chaque matin. Elle combine deux choses : une fenêtre glissante suffisamment courte pour détecter vite, et une logique qui ignore les variations normales.
Les seuils « intelligents » plutôt que les seuils fixes
On te dira qu’il suffit d’alerter quand le LCP dépasse 2,5 s. Appliqué brutalement, ce seuil fixe génère des notifications pour chaque ralentissement passager du CDN ou chaque pic de trafic du Black Friday. Résultat : la chaîne Slack qui reçoit l’alerte finit en mute, et la prochaine alerte importante passe inaperçue.
Une approche plus exploitable consiste à surveiller la distribution des percentiles, pas la valeur moyenne. On peut, par exemple, déclencher une alerte quand le p75 des données de champ dépasse de 15 % la médiane des sept derniers jours, deux jours consécutifs. Ça filtre l’essentiel du bruit statistique. On ne réagit pas à un point isolé : on réagit quand un déploiement a eu le temps de polluer l’expérience d’assez de sessions pour que la tendance se confirme.
Ce genre de logique, on la branche en amont : le pipeline qui ingère les données CrUX quotidiennes exécute une requête simple, compare la fenêtre courante à la fenêtre de référence, et ne notifie que si l’écart dépasse un seuil de significativité. Pas besoin de machine learning sorti d’un tiroir, une condition bien calée fait le travail.
⚠️ Attention : une alerte Slack qui envoie chaque nouvelle URL « LCP médiocre » listée dans la Search Console vous mènera à l’épuisement. Le délai entre l’apparition du problème et le signal dans la Search Console peut dépasser 28 jours. Vous aurez l’alerte quand les positions seront déjà perdues.
Brancher l’alarme sur les données de terrain, pas seulement le lab
Lighthouse dans la CI, c’est pratique pour détecter une régression avant de merger. Mais un LCP qui reste vert dans un environnement de test avec un CPU bridé ne garantit rien sur le terrain. Les données de champ, elles, incorporent la diversité réelle des appareils, des réseaux et des chemins de navigation. Une alarme qui ne lit que les synthétiques est aveugle aux régressions qui ne se manifestent que sur 4G faible avec un vieux mobile.
On branche donc une deuxième couche : un job quotidien qui interroge l’API CrUX ou un service tiers qui expose ces métriques. Ce job compare le p75 du LCP sur l’ensemble des pages d’un type (fiches produit, par exemple) à la performance de la semaine précédente. Si l’écart est anormal, on déclenche une investigation avant même que Googlebot ait recalculé le signal.
L’idée n’est pas de réagir à chaque oscillation. L’idée, c’est de ne jamais être le dernier informé. Un LCP qui monte de 3,2 s à 4,1 s en trois jours, c’est un bug dans le chargement conditionnel d’un bundle, un script d’A/B testing qui bloque le fil d’eau, un nouveau bloc lazy-loadé qui n’a pas reçu de fetchpriority. Peu importe la cause, ce qu’on veut, c’est que l’alerte parte dans l’heure où la tendance est confirmée. Pas dans le rapport mensuel.
Architecture d’alerte en trois couches
Plutôt qu’un monolithe qui alerte sur tout, on découpe la logique en trois niveaux. Le premier, c’est le pipeline CI : chaque Pull Request déclenche une comparaison du LCP synthétique sur les pages critiques. Si le delta dépasse 300 ms, le merge est bloqué.
Le deuxième niveau, c’est la surveillance quotidienne du champ : une tâche qui compare les distributions de la veille aux sept derniers jours. Elle n’est pas sensible à la minute, mais elle verrait une dérive installée.
Le troisième niveau, c’est le déclenchement conditionnel post-déploiement : après une mise en production, on scrute le p75 pendant les quatre heures qui suivent, avec un seuil resserré. Si le déploiement a dégradé le LCP, on le sait dans la demi-journée, pas au prochain rapport.
Ce découpage évite l’effet « pompiers constants » : on ne vous notifie que quand l’un des niveaux détecte une anomalie confirmée, et chaque niveau a sa propre fenêtre de tolérance.
La fausse piste des notifications push
On voit fleurir des intégrations qui promettent de vous envoyer une notification Slack à chaque fois qu’un Core Web Vital dépasse un seuil. Si vous branchez ça sans filtre, vous allez noyer votre canal dans du bruit. La richesse du signal n’est pas dans l’instantanéité brute, elle est dans la synthèse.
Une alarme intelligente ne vous dit pas « le LCP de la page X est à 3,1 s ». Elle vous dit « le LCP médian de la catégorie Y a dérivé de 18 % sur les dernières 48 heures, voici les trois pages les plus impactées ». C’est une question de mise en forme presque triviale côté backend, mais c’est ce qui fait la différence entre un système qu’on lit et un système qu’on ignore.
Ce que Google Search Console ne vous dit pas à temps
La Search Console vous informe d’une dégradation des Core Web Vitals une fois que Google a calculé la tendance sur 28 jours. Ça signifie que la fenêtre d’analyse s’est déjà refermée, et que le mal est fait. Vous pouvez utiliser ce signal pour confirmer une tendance, mais pas pour réagir en amont.
En couplant une alerte terrain quotidienne avec un blocage des régressions dans la CI, vous réduisez le temps entre l’introduction du bug et sa correction de plusieurs semaines à quelques heures. C’est ce qu’on a mis en place après le cas du site e-commerce qui a perdu 15 % de trafic. Depuis, la première anomalie est détectée avant le prochain crawl. Et le client dort mieux.
On ne va pas vous mentir : ça demande un peu d’infrastructure. Mais cette infrastructure, une fois posée, vous évite de découvrir vos problèmes de performance en page 2 des SERP.
Questions fréquentes
Quelle différence entre une alerte basée sur Lighthouse et une alerte basée sur les données de champ ? Lighthouse mesure une page dans un environnement contrôlé, avec une seule configuration matérielle et réseau. Les données de champ (CrUX) sont la réalité de vos visiteurs. Une régression peut être invisible dans le lab et réelle sur mobile 4G. Les deux sont nécessaires, mais seule la donnée de champ déclenche une alerte fiable.
J’ai déjà des alertes sur le temps de réponse serveur, est-ce suffisant pour le LCP ? Non. Un TTFB dégradé peut expliquer un LCP en hausse, mais un LCP qui se détériore sans impact sur le TTFB est courant : un chargement tardif du LCP, une police qui bloque le rendu, un CSS prioritaire oublié. Les alertes serveur ne couvrent pas toute la chaîne de rendu critique.
Combien de temps faut-il pour que Google répercute une amélioration du LCP après correction ? L’amélioration est visible dans les données de champ de la Search Console après un cycle complet de 28 jours glissants, mais les effets sur le classement peuvent être plus rapides si la page est recrawlée et que les signaux terrain s’améliorent. L’alerte précoce sert justement à ne pas attendre ce cycle pour agir.
