Surveiller les Core Web Vitals avec l’API PageSpeed Insights et n8n

Un audit ponctuel de performance ne dit rien sur ce qui se passe entre deux vérifications : un plugin ajouté, une image non compressée mise en ligne un vendredi soir, ou une nouvelle bannière tierce peuvent dégrader silencieusement les Core Web Vitals d’une page pendant des semaines avant que quelqu’un ne le remarque. Ce guide montre comment interroger l’API PageSpeed Insights directement depuis n8n, historiser les scores dans Supabase, et déclencher une alerte dès qu’une régression dépasse un seuil — sur le même principe que la surveillance de disponibilité de sites déjà décrite sur ce blog, appliqué cette fois à la performance plutôt qu’au simple statut HTTP.

Pourquoi la performance mérite un monitoring continu

Les Core Web Vitals — LCP (Largest Contentful Paint, temps d’affichage du contenu principal), INP (Interaction to Next Paint, réactivité aux interactions) et CLS (Cumulative Layout Shift, stabilité visuelle) — ne sont pas de simples indicateurs techniques : ils conditionnent directement le comportement des visiteurs. Une étude de référence en interaction homme-machine, celle de Fiona Fui-Hoon Nah, A study on tolerable waiting time: how long are Web users willing to wait? (Behaviour & Information Technology, 2004), montre que la tolérance à l’attente d’un internaute chute brutalement au-delà de quelques secondes, avec un effet mesurable sur l’abandon de la tâche en cours. Sur un terrain proche — l’impact causal de la latence sur le comportement des utilisateurs plutôt qu’une simple corrélation — l’étude de Shubho Sengupta Krishnan et Ramesh K. Sitaraman, Video Stream Quality Impacts Viewer Behavior: Inferring Causality Using Quasi-Experimental Designs (IMC 2012), établit par un protocole quasi-expérimental qu’une dégradation de latence provoque bien un abandon accru, et non l’inverse. Ces deux résultats justifient de traiter une régression de performance comme un incident à part entière, détecté et corrigé aussi vite qu’une panne serveur.

Comprendre l’API PageSpeed Insights

L’API PageSpeed Insights v5 de Google accepte une simple requête HTTP GET avec l’URL à tester et une clé API :

https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://exemple.fr/&key=VOTRE_CLE&strategy=mobile&category=performance

La réponse JSON contient deux blocs distincts :

• loadingExperience — les données de terrain issues du Chrome UX Report (CrUX) : la réalité vécue par de vrais visiteurs Chrome, disponible uniquement si la page reçoit suffisamment de trafic ;
• lighthouseResult — un audit de laboratoire simulé (moteur Lighthouse), toujours disponible, avec les valeurs brutes de LCP, CLS et un score de performance sur 100.

La clé API se crée gratuitement dans la Google Cloud Console (API « PageSpeed Insights API » à activer sur un projet). Le quota gratuit — 25 000 requêtes par jour, 240 par minute — est largement suffisant pour surveiller un catalogue de pages plusieurs fois par jour sans jamais s’en approcher.

Construire le workflow n8n

Le pipeline s’articule en cinq étapes, réutilisant des briques déjà présentes sur ce blog :

1. Schedule Trigger — une exécution toutes les 4 à 6 heures, voir notre guide sur le node Schedule Trigger et les fuseaux horaires pour caler l’heure sur votre trafic (éviter de tester en pleine nuit si vous voulez des données CrUX représentatives des heures de pointe).
2. Node Set — une liste statique des URLs à surveiller (accueil, pages packs, page de paiement), ou une lecture depuis une table Supabase si le catalogue évolue souvent.
3. Loop Over Items — itération sur chaque URL, avec un léger délai entre les appels pour rester loin des limites de quota ; voir le guide dédié aux boucles n8n pour la configuration du traitement par lots.
4. HTTP Request — appel à l’API PageSpeed Insights pour chaque URL, en strategy=mobile (le mobile reste le terrain le plus exigeant et le plus représentatif) ; consultez notre guide sur le node HTTP Request, les retries et les timeouts pour absorber les latences parfois élevées de l’API (l’audit Lighthouse peut prendre 15 à 30 secondes par page).
5. Node Code — extraction des métriques utiles (lighthouseResult.audits['largest-contentful-paint'].numericValue, cumulative-layout-shift, performanceScore) et écriture dans une table Postgres/Supabase dédiée, avec la date et l’URL en clé.

Historiser les scores pour détecter une régression, pas juste un mauvais chiffre

Un score Lighthouse isolé est peu actionnable : la variabilité entre deux exécutions successives, même sans aucun changement sur le site, peut atteindre plusieurs points. C’est la tendance qui compte. Le node Code compare chaque nouvelle mesure à la moyenne mobile des 5 à 10 dernières exécutions stockées en base (même logique que celle décrite dans notre article sur la détection du déclin de trafic SEO, appliquée ici à la performance plutôt qu’au trafic) :

• LCP en hausse de plus de 20 % par rapport à la moyenne mobile ;
• CLS qui dépasse le seuil recommandé de 0,1 alors qu’il restait en dessous jusque-là ;
• Score de performance global qui chute de plus de 10 points.

Ces seuils, volontairement plus larges qu’un simple dépassement ponctuel, filtrent le bruit naturel des mesures Lighthouse tout en restant sensibles à une vraie régression durable.

Alerter avec un LLM qui priorise, pas juste qui notifie

Envoyer une alerte brute (« LCP a augmenté sur /packs/pack-assistant-rag ») laisse à l’équipe le travail d’interprétation. Un node IA en aval du calcul de régression peut faire mieux : à partir des audits Lighthouse détaillés (qui listent déjà les opportunités d’amélioration — images non optimisées, JavaScript bloquant, polices non préchargées), un prompt de synthèse produit un message exploitable directement dans Slack, sur le modèle de l’approbation humaine via Slack déjà documentée :

« Le LCP de /packs/pack-inbox-ia est passé de 1,8 s à 3,4 s depuis hier. La cause la plus probable selon l’audit Lighthouse : une image hero de 2,1 Mo ajoutée sans compression (hero-inbox-v2.png). Recommandation : compresser en WebP et ajouter fetchpriority="high". »

Ce niveau de détail transforme une alerte de monitoring en ticket actionnable, sans que personne n’ait besoin de rouvrir manuellement l’audit complet.

Reliez ce monitoring à vos autres signaux SEO

La performance n’est qu’un facteur parmi d’autres dans la visibilité organique. Ce pipeline se combine naturellement avec le rapport SEO hebdomadaire depuis Search Console (pour croiser une baisse de position avec une régression de performance survenue au même moment) et avec l’audit d’accessibilité automatisé, puisque de nombreux correctifs (images sans dimensions explicites, contrastes, focus visible) améliorent à la fois l’accessibilité et le CLS. Les deux workflows peuvent écrire dans les mêmes tables Supabase pour un tableau de bord unique de la santé technique du site.

Pièges fréquents

• Tester uniquement en desktop : Google indexe et classe très majoritairement en mobile-first ; si un seul appareil doit être surveillé, c’est le mobile.
• Ignorer l’absence de données CrUX : une page neuve ou peu visitée n’aura pas de loadingExperience — ce n’est pas une erreur du workflow, juste un volume de trafic insuffisant ; retombez alors sur les seules données Lighthouse.
• Alerter à chaque exécution sans lissage : sans moyenne mobile, la variance naturelle de Lighthouse (±5 à 10 points selon la charge du serveur d’audit Google) génère des faux positifs en continu et finit par faire ignorer les vraies alertes.
• Oublier le changement d’API à venir : Google prévoit de retirer les données CrUX de l’API PageSpeed Insights au profit de l’API CrUX dédiée ; gardez le node HTTP Request isolé dans un sous-workflow pour pouvoir basculer l’endpoint sans retoucher tout le pipeline, comme recommandé dans notre guide sur les sub-workflows.

Pour aller plus loin

Ce pipeline de monitoring — appel API planifié, historisation Supabase, alerte IA contextualisée — reprend exactement l’architecture déjà livrée dans le Pack Conformité & Audit (149 €), dont le workflow de rapport de synthèse IA peut être adapté sans réécriture pour synthétiser des audits de performance plutôt que des audits de conformité. Si votre priorité immédiate est plutôt de fiabiliser vos communications internes avant de vous pencher sur la performance web, le Pack Inbox IA (79 €) reste le point d’entrée le plus rapide à mettre en place.