Core Web Vitals : LCP, INP, CLS — les métriques SEO de Google expliquées

Les Core Web Vitals sont trois métriques définies par Google pour mesurer la qualité de l'expérience utilisateur d'une page web. Introduites en 2020 et intégrées à l'algorithme de classement Google en 2021 via la mise à jour Page Experience, elles sont désormais un facteur SEO officiel. Pour les boutiques e-commerce, comprendre et optimiser ces trois indicateurs — LCP, INP et CLS — est devenu aussi important que le travail de contenu ou de netlinking.

Qu'est-ce que les Core Web Vitals ?

Avant les Core Web Vitals, la vitesse d'une page web était mesurée par des métriques techniques comme le Time to First Byte (TTFB) ou le First Contentful Paint (FCP) — des indicateurs utiles pour les développeurs, mais qui ne reflétaient pas fidèlement ce que ressent réellement un utilisateur. Google a voulu combler ce fossé en définissant trois métriques centrées sur l'expérience perçue : à quelle vitesse le contenu principal s'affiche-t-il ? La page répond-elle rapidement aux interactions ? Le contenu se déplace-t-il de manière inattendue ?

Ces trois questions correspondent exactement aux trois Core Web Vitals : LCP pour la vitesse de chargement, INP pour la réactivité, et CLS pour la stabilité visuelle. Google collecte ces données de manière agrégée via Chrome (le Chrome User Experience Report, ou CrUX) et les utilise dans son algorithme pour récompenser les pages offrant une bonne expérience utilisateur.

LCP — Largest Contentful Paint : la vitesse d'affichage du contenu principal

Le LCP (Largest Contentful Paint, ou « affichage du plus grand élément de contenu ») mesure le temps écoulé entre le début du chargement d'une page et le moment où son plus grand élément visible est entièrement rendu à l'écran. Cet élément peut être une image, une balise vidéo, un bloc de texte, ou tout autre contenu dans la zone visible sans défilement (above the fold).

Pour les boutiques e-commerce, le LCP est presque toujours déterminé par l'image principale du produit — la photo packshot qui occupe une grande partie de l'écran en haut de la fiche produit. Cette image est généralement la plus lourde de la page, et donc celle qui prend le plus de temps à charger. C'est pourquoi l'optimisation du LCP dans le contexte e-commerce passe en priorité par l'optimisation de la livraison des images.

Les principales causes d'un mauvais LCP sur les boutiques e-commerce sont : des images de produit trop lourdes (JPEG non optimisé), un hébergement lent avec un TTFB élevé, l'absence de CDN entraînant une latence géographique, et le chargement différé (lazy loading) appliqué à tort sur l'image principale. Cette dernière erreur est fréquente : l'attribut loading="lazy" ne doit jamais être appliqué à l'image above the fold, car il empêche précisément le navigateur de charger rapidement l'élément que Google utilise pour calculer le LCP.

INP — Interaction to Next Paint : la réactivité de la page

L'INP (Interaction to Next Paint) a remplacé le FID (First Input Delay) en mars 2024 comme Core Web Vital officiel. Là où le FID ne mesurait que le délai de réponse à la première interaction, l'INP mesure la latence de toutes les interactions utilisateur pendant la durée de vie de la page — clics, tapotements sur mobile, saisies au clavier — et retient la valeur au 98e percentile.

Concrètement, l'INP mesure le temps entre le moment où l'utilisateur interagit (par exemple, clique sur un bouton « Ajouter au panier ») et le moment où le navigateur affiche visuellement la réponse à cette interaction. Si votre JavaScript est lourd et monopolise le thread principal du navigateur, l'INP sera élevé : la page semble « gelée » ou lente à réagir.

Pour les boutiques e-commerce, les principales causes d'un mauvais INP sont : du JavaScript tiers excessif (widgets de chat, trackers analytics, scripts de comparateurs de prix), des handlers d'événements trop lourds, et des bibliothèques UI volumineuses chargées de manière synchrone. L'optimisation de l'INP passe par l'audit et la réduction du JavaScript non essentiel, et par le report du chargement des scripts tiers après l'interaction utilisateur.

CLS — Cumulative Layout Shift : la stabilité visuelle de la page

Le CLS (Cumulative Layout Shift, ou « décalage cumulatif de la mise en page ») mesure à quel point les éléments de la page se déplacent de manière inattendue pendant le chargement. Chaque fois qu'un élément visible se déplace — un texte qui saute à cause d'une image qui se charge sans dimensions réservées, une bannière publicitaire qui s'insère et pousse le contenu vers le bas — le CLS augmente.

Un CLS élevé est particulièrement frustrant sur mobile : l'utilisateur s'apprête à cliquer sur un lien, et au moment où son doigt touche l'écran, une image se charge et déplace le contenu. Il clique sur un autre lien — parfois sur « Ajouter au panier » alors qu'il voulait lire la description. C'est une expérience dégradée que Google pénalise.

La cause principale de CLS élevé sur les boutiques e-commerce est l'absence de dimensions explicites sur les images (attributs width et height dans le HTML). Lorsque le navigateur parse le HTML et rencontre une balise img sans dimensions, il ne peut pas réserver l'espace nécessaire dans la mise en page. Quand l'image se charge et révèle ses dimensions réelles, la mise en page est recalculée, tout se décale. La solution est simple : toujours spécifier width et height sur les balises img, ou utiliser la propriété CSS aspect-ratio.

Comment les Core Web Vitals influencent le classement Google

Google utilise les Core Web Vitals comme signal de classement depuis juin 2021. Techniquement, ils font partie d'un signal plus large appelé « Page Experience » qui inclut également la compatibilité mobile, la sécurité HTTPS et l'absence de contenus interstitiels intrusifs. Google a précisé que le contenu de qualité reste le signal dominant, mais que les Core Web Vitals peuvent faire la différence entre deux pages de qualité équivalente.

En pratique, Google évalue les Core Web Vitals via deux sources de données : les données de terrain (field data) collectées anonymement via Chrome sur les vraies visites des utilisateurs, et les données de laboratoire (lab data) calculées par des outils comme Lighthouse dans des conditions contrôlées. Les données de terrain — agrégées dans le Chrome User Experience Report (CrUX) — sont celles qui entrent dans l'algorithme. Une page doit recevoir suffisamment de trafic Chrome pour apparaître dans CrUX ; les pages peu visitées sont évaluées au niveau du domaine ou de l'URL racine.

Défis spécifiques au e-commerce

Les boutiques en ligne concentrent plusieurs défis qui rendent l'optimisation des Core Web Vitals particulièrement difficile. D'abord, le volume d'images : une boutique de 1 000 références avec 5 photos par produit doit gérer 5 000 images, chacune devant être optimisée en taille, format et dimensions. Ensuite, la complexité des pages : fiches produit avec galeries, carrousels, zooms, onglets de description, widgets d'avis clients, configurateurs de variantes — autant de composants JavaScript qui peuvent dégrader l'INP.

• Images de produit lourdes sans optimisation format (JPEG non optimisé vs WebP/AVIF)
• Carrousels et galeries avec JavaScript tiers qui bloquent le thread principal
• Lazy loading mal configuré appliqué à l'image hero (dégrade le LCP)
• Images sans attributs width/height explicites dans les templates (dégrade le CLS)
• Scripts de suivi analytics et de remarketing chargés de manière synchrone (dégrade l'INP)
• Hébergement mutualisé lent avec TTFB élevé impactant tous les Core Web Vitals

Comment Lexiik améliore vos Core Web Vitals

Lexiik agit principalement sur le LCP et le CLS — les deux Core Web Vitals les plus directement liés aux images. Pour le LCP, le CDN Cloudflare réduit drastiquement le temps de livraison de l'image principale produit en la servant depuis un nœud géographiquement proche du visiteur, avec des en-têtes de cache d'un an. Pour le CLS, Lexiik garantit que les images servies depuis le CDN maintiennent leurs dimensions d'origine, permettant au navigateur de réserver l'espace correct avant le chargement complet.

La conversion automatique en WebP et AVIF réduit la taille des images de 30 à 50 % sans perte visible de qualité, ce qui accélère non seulement le LCP mais améliore également l'ensemble des métriques de performance ressenties. Sur les connexions mobiles en 4G, passer d'une image JPEG de 400 Ko à une image WebP de 120 Ko peut faire passer le LCP de 3,5 secondes à moins de 1,5 seconde.

Comment vérifier vos scores Core Web Vitals

Plusieurs outils permettent de mesurer et surveiller vos Core Web Vitals. Google Search Console est l'outil de référence pour les données de terrain réelles (CrUX) : la section « Expérience de la page » affiche le pourcentage d'URLs de votre site classées « Bonne expérience », « À améliorer » ou « Mauvaise expérience », avec un détail par métrique. C'est cet outil qui reflète ce que Google voit réellement.

• Google Search Console (search.google.com/search-console) : données de terrain réelles, par URL ou par groupe d'URLs
• PageSpeed Insights (pagespeed.web.dev) : données de terrain + données de laboratoire pour une URL spécifique
• Google Lighthouse (intégré dans Chrome DevTools) : données de laboratoire uniquement, utile pour le développement
• Chrome DevTools > Performance tab : analyse détaillée des événements de rendu et interactions
• web.dev/measure : outil Google pour une analyse rapide en ligne