Core Web Vitals : comprendre et optimiser pour Google

Google a officiellement intégré les Core Web Vitals comme signal de classement en mai 2021. Pour beaucoup de propriétaires de sites, c'était une alerte technique abstraite. Deux ans après, les données sont claires : les pages avec de bons scores Core Web Vitals sont mieux positionnées, génèrent plus de conversions et ont des taux de rebond plus faibles. Ce n'est pas qu'une question de performance technique. C'est une question d'expérience utilisateur qui se traduit directement en résultats business. Ce guide explique les trois métriques actuelles, comment les mesurer et surtout comment les corriger concrètement.

Pourquoi Google a introduit les Core Web Vitals ?

Avant 2021, Google utilisait déjà des signaux de performance dans son algorithme (vitesse mobile depuis 2018, HTTPS depuis 2014), mais ils étaient imprécis et peu transparents. Les Core Web Vitals représentent un changement de philosophie : Google définit explicitement ce qu'est une bonne expérience utilisateur avec des seuils mesurables, et les annonce publiquement plusieurs mois à l'avance pour laisser le temps aux développeurs de corriger leurs sites.

L'idée derrière les CWV est simple : Google veut diriger ses utilisateurs vers des pages qui offrent une expérience rapide, stable et réactive. Si deux pages ont une pertinence sémantique équivalente, la page avec de meilleurs Core Web Vitals sera privilégiée. Ce n'est pas le seul critère de classement (la pertinence du contenu reste dominante), mais c'est un facteur de départage qui peut faire la différence sur des requêtes très concurrentielles.

LCP : Largest Contentful Paint

Le LCP mesure le temps que met le plus grand élément visible de la page à s'afficher depuis le début du chargement. Concrètement, il s'agit le plus souvent d'une image principale, d'un bloc de texte Hero ou d'une vidéo. L'objectif : un LCP inférieur à 2,5 secondes est considéré comme bon. Entre 2,5 et 4 secondes, il y a un besoin d'amélioration. Au-delà de 4 secondes, le score est mauvais et l'impact SEO est négatif.

Les causes les plus fréquentes d'un mauvais LCP sont assez prévisibles. Les images de grande taille non optimisées en sont responsables dans la majorité des cas : une photo JPEG de 2 Mo servie sans compression retardera mécaniquement l'affichage. Un serveur lent (hébergement mutualisé sur-chargé, absence de CDN) est la deuxième cause majeure. Le CSS bloquant le rendu (feuilles de style chargées dans le head qui empêchent l'affichage du contenu) est la troisième cause classique.

Solutions concrètes pour améliorer le LCP : précharger l'image principale avec la balise <link rel="preload">, utiliser le format WebP ou AVIF, activer un CDN, héberger les polices localement plutôt que de les charger depuis Google Fonts, et utiliser l'attribut fetchpriority="high" sur l'image principale.

INP : Interaction to Next Paint

L'INP (Interaction to Next Paint) a remplacé le FID (First Input Delay) comme métrique de réactivité en mars 2024. C'est le changement majeur des Core Web Vitals de ces dernières années. Là où le FID ne mesurait que le délai de traitement de la première interaction, l'INP mesure la réactivité de toutes les interactions pendant toute la durée de la visite : clics sur des boutons, soumissions de formulaires, sélections dans des menus.

L'objectif INP est d'être inférieur à 200 millisecondes. Entre 200 et 500 ms, le score nécessite une amélioration. Au-delà de 500 ms, il est considéré comme mauvais. En pratique, la grande majorité des problèmes d'INP viennent de JavaScript lourd qui bloque le thread principal du navigateur. Quand une interaction est déclenchée, le navigateur ne peut pas y répondre immédiatement si le thread principal est occupé à exécuter du JavaScript.

Les causes typiques d'un mauvais INP : de gros scripts tiers (widgets de chat en direct, pixels publicitaires, scripts analytiques), des gestionnaires d'événements JavaScript mal optimisés qui effectuent de lourds calculs à chaque clic, et des frameworks JavaScript côté client (React, Vue, Angular) avec un First Load JS bundle trop important. La solution passe par le report du chargement des scripts non essentiels (attribut defer ou async), la réduction du JavaScript inutilisé et l'optimisation des gestionnaires d'événements.

CLS : Cumulative Layout Shift

Le CLS mesure la stabilité visuelle d'une page pendant son chargement. Un CLS de 0 signifie que rien ne bouge de manière inattendue. Un CLS de 0,25 signifie que des éléments se déplacent de manière visible et gênante pour l'utilisateur. L'objectif est d'avoir un CLS inférieur à 0,1. Au-delà de 0,25, le score est mauvais.

La cause numéro un de CLS élevé est l'absence de dimensions sur les images et les vidéos. Quand le navigateur charge une image sans connaître ses dimensions à l'avance, il n'alloue pas d'espace dans le layout. L'image s'affiche ensuite et repousse tout le contenu situé en dessous. La correction est simple : toujours spécifier width et height sur les balises img et video, ou utiliser la propriété CSS aspect-ratio.

Les polices web sont la deuxième cause fréquente de CLS. Quand une police externe met du temps à charger, le navigateur affiche d'abord le texte avec une police système, puis le remplace par la police voulue. Ce remplacement peut décaler le texte et le contenu adjacent. Pour corriger ce phénomène (FOUT, Flash of Unstyled Text), utilisez font-display: optional ou preload vos polices critiques. Les publicités et les bannières sans dimensions réservées sont la troisième cause classique de CLS élevé, particulièrement sur les sites editoriaux avec beaucoup de displays.

Comment mesurer ses Core Web Vitals

PageSpeed Insights (pagespeed.web.dev) est l'outil le plus simple et le plus direct. Il analyse une URL et affiche les scores CWV basés sur deux sources : les données de laboratoire (Lighthouse, données synthétiques produites en simulant un chargement) et les données de terrain (CrUX, données réelles des utilisateurs Chrome). Les données de terrain sont ce que Google utilise pour le classement, pas les données de laboratoire. Attention à cette distinction : un bon score Lighthouse ne garantit pas de bons CWV terrain si le volume de traffic est insuffisant pour alimenter CrUX.

Google Search Console dispose d'un rapport "Expérience sur les pages" (Core Web Vitals) qui classe toutes vos URLs en trois catégories : Bonnes, A améliorer et Médiocres. C'est la vue la plus utile pour prioriser les corrections car elle agrège les données sur l'ensemble du site. Les URLs en rouge (Médiocres) doivent être traitées en priorité.

Pour les développeurs qui veulent aller plus loin, le Chrome DevTools Performance Panel permet d'analyser les CWV en temps réel pendant le chargement d'une page, d'identifier les scripts qui bloquent le thread principal et de visualiser les décalages de layout sur la timeline. CrUX Dashboard (via Looker Studio, gratuit) permet de suivre l'évolution de vos CWV dans le temps sur des graphiques historiques.

Impact réel des Core Web Vitals sur le SEO

Des études de corrélation publiées par SEMrush et Ahrefs dans les mois qui ont suivi le Page Experience Update montrent que les sites avec de bons Core Web Vitals ont en moyenne des positions légèrement meilleures, mais l'effet est modéré comparé à la qualité du contenu et à l'autorité du domaine. Les CWV ne font pas de miracles : une page médiocre qui charge rapidement ne surclassera pas une page excellente qui charge en 3 secondes.

En revanche, l'impact indirect est significatif. Un meilleur LCP réduit le taux de rebond (les utilisateurs qui quittent avant même que la page charge). Un CLS sous contrôle réduit les erreurs de clic accidentels. Un bon INP rend l'expérience plus fluide et augmente le temps passé sur le site. Ces comportements positifs (faible taux de rebond, temps de session long, taux de retour élevé) sont des signaux que Google prend en compte dans son évaluation de la qualité d'une page, même indirectement.