Core Web Vitals : que surveiller et comment corriger les régressions
Les régressions de performance ne sont presque jamais expédiées intentionnellement. Elles arrivent avec un changement apparemment anodin : un nouveau carrousel, une balise tierce, un changement de police. Le temps que quelqu'un remarque la baisse de conversions, la régression a deux semaines. La surveillance continue de CWV inverse la boucle.
Google classe les sites selon la performance réelle des utilisateurs. LCP, FCP, CLS, TTFB — ce ne sont pas des chiffres abstraits, ce sont des tueurs de conversion quand ils dérivent. Voici comment les surveiller en continu et attraper les régressions avant qu'elles n'atteignent les utilisateurs.
Ce que mesurent vraiment les Core Web Vitals
Les six métriques qui comptent, en termes simples :
• LCP (Largest Contentful Paint) — temps jusqu'au rendu du plus grand élément visible. Bon < 2,5s. • FCP (First Contentful Paint) — temps jusqu'au premier pixel rendu. Bon < 1,8s. • CLS (Cumulative Layout Shift) — déplacements de mise en page au chargement. Bon < 0,1. • TTFB (Time to First Byte) — latence pure serveur/CDN. Bon < 0,8s. • TBT (Total Blocking Time) — durée de blocage du thread principal. Bon < 200ms. • Speed Index — score synthétisé de ressenti. Bon < 3,4s.
Pourquoi les scores de laboratoire mentent
Lighthouse-CI exécute votre page sur un appareil milieu de gamme simulé avec une 3G simulée. C'est bon pour les comparaisons relatives, mais il rate beaucoup de modes d'échec réels. Les scripts tiers qui se lazy-loadent selon le consentement cookie, les branches A/B qui ne s'affichent que pour la moitié des utilisateurs — Lighthouse ne les voit jamais.
Une vérification Playwright en navigateur complet attrape les échecs que Lighthouse rate. SpeedTest exécute les deux.
Lire les graphiques : régressions graduelles vs. en marches
Deux formes de régressions racontent des histoires différentes.
Une montée graduelle du LCP sur deux semaines signifie généralement qu'une seule ressource grossit — un flux d'images produit sans pagination, un bundle analytics qui prend du poids.
Un changement en marche lors d'un seul déploiement — TTFB passe de 400ms à 1200ms du jour au lendemain — est une cause directe au niveau du code. Corrélez l'horodatage avec vos entrées DeployLog.
Seuils d'alerte par métrique qui fonctionnent
Un seuil par métrique, alerter au franchissement de la limite 'poor' plutôt que sur un criard 'régressé de 10%' :
• LCP > 4,0s — alerte • FCP > 3,0s — alerte • CLS > 0,25 — alerte • TTFB > 1,8s — alerte • TBT > 600ms — alerte
Combinez avec un seuil d'avertissement à la ligne 'needs improvement' de Google.
Que faire quand CWV régresse après un déploiement
Le playbook quand une métrique rouge s'allume juste après une release :
1. Ouvrir la trace Playwright de l'exécution ratée. 2. Trouver la ressource nouvelle ou modifiée. 3. Si c'est un tiers, vérifier sa page de statut et envisager `async` ou `defer`. 4. Si c'est votre code, corréler avec DeployLog et revenir en arrière ou hotfixer. 5. Ajouter le motif d'échec à votre checklist pré-déploiement.
Guide produit
Uptime Monitoring
AlertsDock gives teams uptime monitoring for websites, APIs, TCP checks, DNS checks, SSL expiry, and fast alert routing without enterprise overhead.
Lire le guidePage alternative
Better Stack Alternative
Compare AlertsDock with Better Stack for teams that want a more focused monitoring product covering uptime, cron jobs, status pages, and webhooks.
Voir la comparaisonMore articles
Changelogs générés par IA : transformez les commits Git en notes de version automatiquement
Écrire des notes de version est la corvée que personne ne veut. DeployLog lit vos commits à chaque push et génère des changelogs propres et lisibles regroupés par type — pas besoin d'Anthropic, fonctionne avec Groq, Gemini, Cloudflare, OpenRouter ou Ollama auto-hébergé.
Arrêtez d'envoyer des fichiers .env par e-mail : un guide pratique des coffres-forts chiffrés
Le DATABASE_URL de votre équipe est dans les DM Slack de quelqu'un. Votre STRIPE_SECRET_KEY vit sur une page Notion. C'est comme ça que les secrets fuient. Voici l'hygiène que vous auriez dû avoir dès le premier jour — et comment les coffres-forts chiffrés la rendent indolore.
Playbooks d'incident auto-exécutables : du runbook au runtime
Écrire un runbook que personne ne lit à 3h du matin est un gaspillage. En écrire un qui démarre automatiquement dès qu'un moniteur tombe en panne et enregistre chaque étape est un multiplicateur de force.