Pourquoi les Core Web Vitals sont importants
Les Core Web Vitals (CWV) sont 3 métriques de performance web définies par Google. Depuis 2021, elles sont un facteur de ranking officiel.
Mais au-delà du SEO, ces métriques mesurent l'expérience utilisateur réelle :
• Un site lent frustre les visiteurs
• Un site qui "saute" pendant le chargement désoriente
• Un site qui ne réagit pas aux clics fait fuir
Impact business :
• Un visiteur qui attend quitte plus souvent la page avant d'agir
• Une page stable et réactive facilite la prise de contact ou l'achat
• Les études de cas doivent être citées avant d'attribuer un effet chiffré sur les conversions
Les 3 métriques :
- LCP (Largest Contentful Paint) : vitesse d'affichage
- INP (Interaction to Next Paint) : réactivité
- CLS (Cumulative Layout Shift) : stabilité visuelle
LCP : accélérer l'affichage du contenu principal
Le LCP mesure le temps d'affichage du plus gros élément visible (image, titre, bloc de texte).
Seuils :
• Bon : < 2.5 secondes
• À améliorer : 2.5 - 4 secondes
• Mauvais : > 4 secondes
Ce qui est mesuré (par ordre de priorité) :
• Images (<img>, <image> dans SVG, background-image)
• Vidéos (<video> avec poster)
• Blocs de texte (<h1>, <p> avec contenu significatif)
Causes courantes d'un mauvais LCP :
- Images trop lourdes ou non optimisées
- JavaScript qui bloque le rendu
- CSS trop lourd ou non critique
- Temps de réponse serveur lent (TTFB)
- Lazy-loading sur l'image LCP (erreur fréquente)
Optimiser le LCP : actions concrètes
Suivez cette checklist pour améliorer votre LCP.
- Optimiser les images : WebP/AVIF, compression, dimensions adaptées
- Précharger l'image LCP : <link rel='preload' as='image'>
- NE PAS lazy-loader l'image LCP (above the fold)
- Réduire le TTFB : CDN, cache, hébergement performant
- Éliminer le JS bloquant : defer/async, code-splitting
- Inliner le CSS critique, différer le reste
- Utiliser font-display: swap pour les polices
- Compresser avec gzip/brotli
INP : rendre l'interface réactive
L'INP (Interaction to Next Paint) remplace le FID depuis mars 2024. Il mesure la réactivité de votre site aux interactions utilisateur (clics, taps, touches clavier).
Seuils :
• Bon : < 200 millisecondes
• À améliorer : 200 - 500ms
• Mauvais : > 500ms
Contrairement au FID qui ne mesurait que la première interaction, l'INP mesure TOUTES les interactions et prend la pire comme score.
Ce qui dégrade l'INP :
- JavaScript lourd qui bloque le thread principal
- Tâches longues (> 50ms)
- Handlers d'événements lents
- Mise à jour DOM complexe après interaction
- Third-party scripts (analytics, chat, pubs)
Optimiser l'INP : actions concrètes
L'INP est souvent le plus difficile à optimiser. Voici les leviers principaux.
- Identifier les Long Tasks avec Chrome DevTools > Performance
- Découper les tâches JS longues (yield to main thread)
- Différer les scripts non essentiels (analytics, chat widgets)
- Utiliser requestIdleCallback pour le travail non urgent
- Éviter les re-renders inutiles (frameworks réactifs)
- Optimiser les event handlers (debounce, throttle)
- Réduire la complexité du DOM (moins de nœuds = plus rapide)
- Virtualiser les longues listes (react-virtual, etc.)
CLS : stabiliser la mise en page
Le CLS mesure les décalages visuels inattendus. Quand un bouton "bouge" juste avant que vous cliquiez, c'est un mauvais CLS.
Seuils :
• Bon : < 0.1
• À améliorer : 0.1 - 0.25
• Mauvais : > 0.25
Causes courantes de CLS :
- Images sans dimensions (width/height)
- Pubs ou iframes sans espace réservé
- Polices web qui changent la taille du texte (FOUT)
- Contenu injecté dynamiquement au-dessus du contenu existant
- Animations qui modifient la taille des éléments
Optimiser le CLS : actions concrètes
Le CLS est généralement le plus facile à corriger.
- Toujours spécifier width et height sur les images
- Utiliser aspect-ratio CSS pour les conteneurs dynamiques
- Réserver l'espace pour les pubs/embeds (skeleton, min-height)
- Utiliser font-display: optional ou swap + preload
- Ne jamais insérer de contenu au-dessus de contenu existant
- Préférer transform à top/left pour les animations
- Éviter les animations qui modifient width/height
- Charger les polices en local si possible
Outils pour mesurer les Core Web Vitals
Deux types de données :
• Lab data : mesures en conditions contrôlées (utile pour débugger)
• Field data : mesures des vrais utilisateurs (ce que Google utilise pour le ranking)
Google utilise les FIELD DATA sur 28 jours pour évaluer vos CWV.
- PageSpeed Insights - Lab + Field data, recommandations détaillées
- Google Search Console - Rapport CWV groupé par type d'URL
- Chrome DevTools > Performance - Analyse technique détaillée
- Lighthouse (Chrome) - Audit complet automatisé
- web.dev/measure - Historique et suivi dans le temps
- Web Vitals Extension - Mesure en temps réel dans Chrome
- CrUX Dashboard (Looker Studio) - Données historiques field data
Erreurs fréquentes à éviter
Ces erreurs reviennent constamment lors des audits performance.
- Lazy-loader l'image hero (LCP) : ERREUR grave, préchargez-la
- Charger tout le JS en render-blocking : utilisez defer/async
- Images sans dimensions : cause n°1 de mauvais CLS
- Polices non préchargées : FOUT et mauvais CLS
- Analytics/tracking avant le contenu : différez avec setTimeout
- Optimiser seulement le desktop : Google est mobile-first
- Se fier uniquement aux lab data : les field data comptent pour Google
- Ignorer les third-party scripts : ils impactent fortement l'INP
Plan d'optimisation en 2 semaines
Voici un plan réaliste pour améliorer vos CWV.
- Jour 1-2 : Auditer avec PageSpeed Insights toutes les pages clés
- Jour 3-4 : Optimiser les images (formats, compression, dimensions)
- Jour 5-6 : Corriger le CLS (dimensions images, polices)
- Jour 7-8 : Optimiser le LCP (préchargement, CSS critique)
- Jour 9-10 : Améliorer l'INP (différer scripts, optimiser handlers)
- Jour 11-12 : Tester sur vrais appareils mobiles
- Jour 13-14 : Monitorer les field data, ajuster