Retour au blog

Core Web Vitals : pourquoi le monitoring uptime ne suffit pas

· 6 min de lecture

En bref : Le serveur renvoie HTTP 200, le monitoring dit "UP" - et vous perdez quand même du trafic depuis Google. Core Web Vitals (LCP, INP, CLS) mesurent l'expérience utilisateur réelle. Un web lent est, du point de vue de Google, "down" tout comme un site indisponible.

En bref : Le serveur renvoie HTTP 200, le monitoring dit "UP" - et vous perdez quand même du trafic depuis Google. Core Web Vitals (LCP, INP, CLS) mesurent l'expérience utilisateur réelle. Un web lent est, du point de vue de Google, "down" tout comme un site indisponible.

Trois métriques CWV

Google a introduit en 2020 les Core Web Vitals comme facteur de ranking. Depuis mars 2024, ils sont composés de :

  • LCP (Largest Contentful Paint) - quand l'élément le plus grand de la page apparaît. Bon : ≤ 2,5 s. À améliorer : 2,5-4 s. Mauvais : > 4 s.
  • INP (Interaction to Next Paint) - avec quelle rapidité la page réagit aux interactions de l'utilisateur (clic, tap). A remplacé le FID en mars 2024. Bon : ≤ 200 ms. À améliorer : 200-500 ms. Mauvais : > 500 ms.
  • CLS (Cumulative Layout Shift) - combien les éléments de la page bougent visuellement pendant le chargement. Bon : ≤ 0,1. À améliorer : 0,1-0,25. Mauvais : > 0,25.

Pourquoi le monitoring ne l'attrape pas

Un monitor uptime classique envoie une requête HTTP GET et mesure :

  • Code de statut (200 = OK)
  • Time to first byte (TTFB)
  • Optionnellement keyword match dans le HTML

Mais il ne rend pas la page dans le navigateur. Il ne voit pas que :

  • Le bundle JavaScript fait 3 MB et le parsing prend 4 secondes
  • L'image hero se charge synchrone et bloque le paint
  • La tierce partie (analytics, publicité) bloque le main thread
  • Le layout saute pendant que les éléments se chargent

Du point de vue du visiteur, le web est lent et inutilisable - du point de vue du monitoring, tout est "UP".

Lab vs field data

Le CWV se mesurent de deux façons :

Lab data (Lighthouse, PageSpeed Insights, WebPageTest) - navigateur contrôlé, réseau défini (typiquement 4G), device spécifique. Reproductible, adapté aux tests de régression après les déploiements.

Field data / RUM (Chrome User Experience Report, JS custom) - collecte de données de vrais visiteurs dans leurs vraies conditions. Ce que Google utilise pour le ranking. Reflète la vraie variabilité (client mobile 3G dans le train, desktop fibre, etc.).

Les lab data sont une bonne référence, les field data sont la vérité.

Note : ePulz.io ne suit pas actuellement les métriques CWV. Pour les mesurer, utilisez des outils spécialisés (PageSpeed Insights, WebPageTest, Lighthouse CI ou votre propre snippet RUM JS). Pour les régressions visuelles, ePulz.io offre un moniteur de type visual qui compare les screenshots - cela couvre partiellement les scénarios "la page se rend complètement différemment", mais ne mesure pas LCP/INP/CLS.

Stratégie pratique de monitoring

  1. Synthetic uptime check - moniteur HTTP classique toutes les 1-5 min. Détecte le hard downtime, 5xx, certificats expirés.
  2. Mesure CWV (hors ePulz) - Lighthouse CI dans le pipeline de déploiement ou cron nocturne ou Chrome headless une fois par jour. Détecte la régression après un déploiement (LCP est passé de 1,8 s à 4,2 s après le déploiement d'un nouveau bundle JS).
  3. Visual regression check - screenshot diff. Détecte quand la page se rend complètement différemment qu'avant (CSS cassé, font fail, JS error).
  4. Real User Monitoring - snippet JS sur la page collecte le CWV de vrais visiteurs. Vous suivez le 75e percentile des métriques.

Top causes de mauvais CWV

LCP trop élevé :

  • Grandes images hero sans priority hint (fetchpriority="high")
  • Serveur lent / TTFB (CDN cache miss, query DB lente)
  • Blocking resources dans <head> (analytics, fonts sans display=swap)
  • Web fonts chargés depuis un CDN tiers sans preconnect

INP trop élevé :

  • Gros bundle JS bloquant le main thread
  • Event listeners synchrones qui font du travail lourd
  • Scripts tiers lents (chat widgets, A/B testing)

CLS trop élevé :

  • Images sans attributs width et height explicites
  • Publicités sans espace réservé
  • Contenus injectés dynamiquement au-dessus du fold
  • Web fonts avec FOUT (Flash of Unstyled Text) sans bon fallback

Impact SEO

Google utilise les CWV comme tie-breaker. Pour un contenu également pertinent, il préfère la page plus rapide. Dans les niches compétitives, c'est décisif.

Impact pratique :

  • Un site avec CWV dans la fourchette "good" a en moyenne ~20% de bounce rate plus bas
  • Le taux de conversion monte avec chaque -100 ms LCP
  • Le mobile-first indexing signifie que Google évalue la version mobile - testez là-bas

Conclusion

Le monitoring uptime répond à "Le serveur est-il joignable ?". Les Core Web Vitals répondent à "Le web est-il utilisable ?". Les deux métriques sont indépendantes et vous devez surveiller les deux. Le serveur peut avoir 100% d'uptime et le web perdre quand même du trafic à cause d'un LCP supérieur à 4 secondes.

Monitoring au-delà de l'uptime

La visual regression détecte les changements visuels même quand le serveur renvoie 200. Le monitoring du response time attrape les endpoints lents.

Essayer ePulz.io →

Essayez ePulz.io gratuitement - 7 jours sans carte de crédit.

Créer un compte