Core Web Vitals : comprendre LCP, INP et CLS et savoir les corriger

Les Core Web Vitals sont un ensemble de trois indicateurs définis par Google pour mesurer l'expérience de chargement, d'interactivité et de stabilité visuelle d'une page web. Ils font partie des signaux d'expérience de page utilisés par la recherche Google, et surtout ils reflètent ce que vos visiteurs ressentent réellement.

Les trois indicateurs sont le LCP (Largest Contentful Paint) pour la vitesse d'affichage du contenu principal, l'INP (Interaction to Next Paint) pour la réactivité aux interactions, et le CLS (Cumulative Layout Shift) pour la stabilité visuelle. L'INP a remplacé le FID (First Input Delay) en mars 2024.

Google évalue chaque indicateur sur des données de terrain, collectées auprès d'utilisateurs réels de Chrome, et considère la valeur au 75e centile des chargements de page. Autrement dit, une page est « bonne » si au moins trois quarts de ses chargements respectent le seuil.

Chaque indicateur possède trois plages : bon, à améliorer, médiocre. Les seuils sont publiés et documentés par Google sur web.dev, et sont identiques pour mobile et ordinateur, même si les valeurs mesurées diffèrent souvent fortement entre les deux types d'appareils.

Une page doit être « bonne » sur les trois indicateurs pour réussir l'évaluation. En pratique, le LCP sur mobile est le plus souvent en échec, suivi de l'INP sur les sites riches en JavaScript. Le CLS est généralement le plus simple à corriger une fois la cause identifiée.

Les données de terrain proviennent du rapport d'expérience utilisateur Chrome (CrUX) et sont visibles dans la Search Console, via le rapport Signaux Web essentiels, et dans PageSpeed Insights. Ce sont elles qui comptent pour Google. Elles ne sont disponibles que si le site reçoit suffisamment de trafic.

Les données de laboratoire (Lighthouse, WebPageTest, DevTools) simulent un chargement dans des conditions fixées. Elles sont indispensables pour diagnostiquer et reproduire, mais elles ne mesurent pas l'INP réel, qui dépend des interactions des utilisateurs. Un bon score Lighthouse ne garantit pas de bons Core Web Vitals.

Pour un suivi précis, installez la bibliothèque web-vitals de Google sur votre site et envoyez les mesures à votre outil d'analyse. Vous saurez quelles pages, quels appareils et quels éléments posent problème, avec une granularité que les rapports agrégés n'offrent pas.

L'élément LCP est généralement une image de couverture, une vidéo affichée en image ou un grand bloc de texte. Commencez par identifier cet élément, puis assurez-vous qu'il est découvert le plus tôt possible par le navigateur : image dans le HTML initial, ni injectée par JavaScript ni en arrière-plan CSS, avec une priorité élevée et sans chargement différé.

Réduisez le temps de réponse serveur : cache de page, CDN, base de données optimisée. Un TTFB élevé condamne le LCP avant même que le navigateur ait commencé à afficher quoi que ce soit. Ensuite, éliminez les ressources bloquantes, comme les CSS et scripts synchrones dans l'en-tête, qui retardent le premier rendu.

Optimisez enfin l'image elle-même : format moderne (AVIF, WebP), dimensions adaptées à l'écran, compression raisonnable, et polices web avec font-display pour éviter que le texte ne reste invisible en attendant la police.

L'INP mesure le délai entre une interaction (clic, touche, saisie) et le prochain rendu à l'écran, sur l'ensemble de la visite. Une valeur élevée signifie que le fil d'exécution principal est occupé par du JavaScript au moment où l'utilisateur agit, et que l'interface semble figée.

Les causes habituelles sont les scripts tiers (publicité, suivi, chat, consentement), les gestionnaires d'événements lourds, les mises à jour massives du DOM et les frameworks qui rendent à nouveau des arbres entiers. Découpez les tâches longues, différez le travail non urgent et donnez la priorité au retour visuel immédiat.

Auditez les scripts tiers un par un et retirez ceux qui n'apportent pas de valeur mesurable. Sur les applications React, Vue ou Angular, profilez les rendus et évitez les recalculs inutiles ; le rendu côté serveur et l'hydratation partielle réduisent aussi la charge initiale.

Le CLS mesure les déplacements inattendus de contenu pendant la vie de la page : une image qui apparaît et pousse le texte, une bannière insérée en haut, une police qui change de taille en se chargeant. Ces décalages sont particulièrement irritants sur mobile, où ils provoquent des clics involontaires.

Réservez systématiquement l'espace : attributs width et height sur les images et vidéos, dimensions fixes pour les emplacements publicitaires et les intégrations, et police de secours dont les métriques sont ajustées pour correspondre à la police finale.

N'insérez jamais de contenu au-dessus du contenu existant sans action de l'utilisateur, et préférez les animations par transform, qui ne déclenchent pas de recalcul de mise en page, aux animations de hauteur ou de position.

Commencez par les pages qui reçoivent le plus de trafic et qui sont en échec dans la Search Console : accueil, catégories, fiches produits, articles. Traitez d'abord le LCP, dont les corrections sont souvent les plus rentables, puis l'INP, puis le CLS.

Mesurez après chaque correction avec les données de laboratoire, puis attendez que les données de terrain se mettent à jour, ce qui prend plusieurs semaines puisqu'elles portent sur 28 jours glissants. Un suivi continu évite que les régressions ne s'installent au fil des déploiements.