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 prouvé : • Amazon : +100ms de chargement = -1% de ventes • Google : +500ms = -20% de trafic • Études CWV : passer de "mauvais" à "bon" = +24% de conversion en moyenne
Les 3 métriques : 1. LCP (Largest Contentful Paint) : vitesse d'affichage 2. INP (Interaction to Next Paint) : réactivité 3. 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 : 1. Images trop lourdes ou non optimisées 2. JavaScript qui bloque le rendu 3. CSS trop lourd ou non critique 4. Temps de réponse serveur lent (TTFB) 5. 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 : 1. JavaScript lourd qui bloque le thread principal 2. Tâches longues (> 50ms) 3. Handlers d'événements lents 4. Mise à jour DOM complexe après interaction 5. 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 : 1. Images sans dimensions (width/height) 2. Pubs ou iframes sans espace réservé 3. Polices web qui changent la taille du texte (FOUT) 4. Contenu injecté dynamiquement au-dessus du contenu existant 5. 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