Core Web Vitals : LCP, INP et CLS expliqués

Les Core Web Vitals sont les métriques qui font le pont entre le SEO technique et l'expérience utilisateur réelle. Elles traduisent des notions abstraites de performance en trois valeurs mesurables que Google collecte directement dans les navigateurs de vrais visiteurs. Cet article explique en détail le LCP, l'INP et le CLS, évalue leur poids réel en tant que signal de classement et montre comment améliorer ces métriques de manière ciblée dans une stack moderne composée de Next.js, d'Edge/CDN et de HTTP/3. L'accent est mis sur l'usage mobile, par lequel passe la majorité des accès à Internet, par exemple en Autriche.

Pourquoi les Core Web Vitals comptent pour le SEO technique

Les Core Web Vitals sont la partie de l'expérience sur la page que Google met en avant et utilise dans ses systèmes de classement. Dans sa documentation officielle, Google précise qu'il n'existe pas de signal unique d'expérience sur la page, mais que les Core Web Vitals sont utilisées par les systèmes de classement et qu'une bonne expérience sur la page peut contribuer au succès dans les recherches pour lesquelles il existe beaucoup de contenu utile (Google Search Central). Les trois métriques ne sont donc pas un facteur de classement majeur, mais un signal de qualité solide, qui fait pencher la balance surtout lorsque plusieurs résultats équivalents sur le fond sont en concurrence.

La pratique montre l'ampleur de la marge de progression. Selon le Web Almanac 2024, seulement 43 % des origines mobiles valident les trois Core Web Vitals, contre 54 % sur desktop (HTTP Archive, Web Almanac 2024). Si tu travailles proprement sur ce point, tu te démarques donc de plus de la moitié du web mobile. Pour l'Autriche, c'est particulièrement pertinent, car l'usage d'Internet y est fortement mobile : en juin 2024, 81,5 % des accès à Internet s'y sont faits depuis des appareils mobiles. Une grande partie concernait des applications. Le web mobile représentait 31,6 % de l'ensemble des accès (Statista, Österreichische Webanalyse). Pour les Core Web Vitals, seule la part du navigateur compte, et elle aussi est en grande partie mobile.

Les trois métriques et leurs seuils

Google classe l'évaluation en good, needs improvement et poor, et mesure toujours au 75e percentile des pages vues, séparément pour mobile et desktop. Les seuils « good » officiels sont : LCP de 2,5 secondes ou moins, INP de 200 millisecondes ou moins et CLS de 0,1 ou moins (web.dev). Concrètement, le 75e percentile signifie que trois pages vues sur quatre doivent atteindre le seuil ; le quart le moins bon ne compte pas. Une page ne valide donc une Core Web Vital que si elle est rapide de manière fiable, pas seulement dans le meilleur des cas.

• Largest Contentful Paint (LCP) : mesure le moment où le plus grand élément visible dans le viewport est rendu. C'est l'indicateur qui représente la vitesse de chargement perçue.
• Interaction to Next Paint (INP) : mesure la latence entre une interaction de l'utilisateur et la mise à jour visible suivante de l'affichage, sur l'ensemble de la session.
• Cumulative Layout Shift (CLS) : mesure la plus grande rafale de décalages de mise en page inattendus pendant toute la durée de vie de la page, autrement dit la stabilité du contenu (web.dev).

Au niveau des métriques individuelles, le tableau est contrasté sur mobile. En 2024, 59 % des pages mobiles obtenaient un bon LCP, 74 % un bon INP et 79 % un bon CLS (Web Almanac 2024). Sur mobile, le LCP est donc la métrique la plus souvent ratée des trois.

LCP en détail : optimiser la perception du chargement

Pour le LCP, il s'agit presque toujours d'une image. Sur 73,3 % des pages mobiles, l'élément LCP est une image (Web Almanac 2024). L'image LCP est donc le levier d'optimisation individuel le plus important. Les causes typiques d'un LCP lent se situent dans trois domaines : un temps de réponse serveur élevé (TTFB), des ressources bloquant le rendu, comme le CSS et le JavaScript sur le chemin critique, et le temps de chargement de la ressource LCP elle-même.

Les contre-mesures les plus efficaces agissent précisément à ces niveaux :

• Piloter la priorité : marquer l'image LCP avec fetchpriority="high" et, si nécessaire, la demander tôt via <link rel="preload">, pour que le navigateur ne la place pas derrière des ressources moins importantes.
• Ne jamais charger l'image LCP en lazy loading : un anti-pattern répandu. 16 % des pages mobiles chargent leur image LCP en lazy loading, et 9,5 % le font même via l'attribut natif loading="lazy" (Web Almanac 2024). L'élément LCP se trouve au-dessus de la ligne de flottaison et doit être chargé en mode eager.
• Utiliser des formats d'image modernes : AVIF et WebP réduisent nettement la taille des fichiers par rapport au JPEG et raccourcissent ainsi le temps de chargement des ressources.
• Réduire le TTFB via Edge/CDN : servir depuis un nœud CDN proche de l'utilisateur et utiliser des protocoles de transport modernes raccourcit le temps de réponse du serveur, avant même qu'un seul pixel soit rendu.

INP en détail : garantir l'interactivité

L'INP a remplacé le FID en tant que Core Web Vital le 12 mars 2024 et a été affiché au même moment dans la Search Console à la place du FID (web.dev). Ce changement n'avait rien de cosmétique : le FID ne mesurait que le délai de la première interaction, alors que l'INP évalue toutes les interactions d'une session et se montre nettement plus strict. Cela se voit dans les chiffres : avec le FID, 48 % des pages mobiles auraient encore eu de bonnes CWV en 2024, avec l'INP elles ne sont que 43 % (Web Almanac 2024).

L'INP se compose de trois phases : l'input delay (temps d'attente avant que le gestionnaire d'événements puisse démarrer), le processing time (exécution du gestionnaire) et le presentation delay (temps jusqu'à l'image suivante). La cause de loin la plus fréquente d'un mauvais INP est le JavaScript bloquant, qui occupe le thread principal et fait s'accumuler les interactions. Il en découle trois leviers, que l'article Optimiser l'INP traite en détail :

• Découper les tâches longues (task splitting) : fractionner les grosses tâches JavaScript en morceaux plus petits et rendre la main au navigateur entre-temps, par exemple avec scheduler.yield() ou un report, pour que les saisies n'aient pas à attendre.
• Découpler les événements (debouncing) : limiter les gestionnaires qui se déclenchent fréquemment, comme les événements de scroll ou de saisie, pour qu'une logique coûteuse ne s'exécute pas à chaque pixel.
• Déporter le travail (Web Workers) : déplacer les traitements gourmands en calcul et sans lien avec l'interface vers un Web Worker, afin de garder le thread principal libre.

CLS en détail : préserver la stabilité visuelle

Le CLS évalue la stabilité visuelle d'une page : il pénalise les contenus qui bougent encore après le premier rendu. Les causes sont bien connues : images et iframes sans dimensions fixes, contenu chargé dynamiquement au-dessus du contenu existant, polices web chargées tardivement qui provoquent un saut de mise en page, et emplacements publicitaires sans espace réservé. Les contre-mesures sont toutes préventives :

• Définir les dimensions : toujours indiquer width et height ou un aspect-ratio pour les images et les vidéos, afin que le navigateur réserve l'espace avant le chargement.
• Réserver de l'espace pour les éléments dynamiques : prévoir des emplacements fixes dans la mise en page pour les publicités, les embeds et les bannières chargées après coup, au lieu de les insérer dans le flux.
• Atténuer le changement de police : limiter le reflow lors du remplacement de police grâce à font-display et à des polices préchargées.

Avec 79 % de bonnes valeurs sur mobile, le CLS est la métrique la mieux maîtrisée des trois (Web Almanac 2024). Cela tient au fait que les contre-mesures sont techniquement simples et qu'il suffit de les mettre en place une fois.

Bonnes pratiques : les CWV dans une stack Next.js et Edge

Dans Next.js, de nombreuses optimisations des CWV sont déjà prévues dans les briques du framework, mais il faut les utiliser sciemment. next/image impose des dimensions et sert des formats modernes. Pour l'image la plus importante, fetchPriority="high" augmente la priorité de chargement, ce qui agit directement sur le LCP. Jusqu'à Next.js 14, l'attribut priority définissait automatiquement cette valeur. Depuis Next.js 15, priority ne gère plus que le preload et le chargement eager ; fetchPriority="high", tu dois le définir toi-même (Next.js, Pull Request #67351). Depuis Next.js 16, priority est marqué comme obsolète au profit de preload, et la documentation Next.js recommande dans la plupart des cas fetchPriority="high" ou loading="eager". next/font charge les polices localement et en auto-hébergement, ce qui évite le saut de mise en page lié aux polices qui dégrade le CLS. Le streaming via SSR et les React Server Components réduisent le JavaScript envoyé au client, ce qui désamorce la cause principale d'un mauvais INP.

Le point le plus critique dans l'App Router est l'hydratation. Chaque composant client interactif doit être hydraté dans le navigateur, et trop de JavaScript côté client produit justement les tâches longues qui font grimper l'INP. Concrètement : laisser le plus possible en Server Components, limiter l'interactivité à de petits îlots client et charger les composants lourds de manière différée et ciblée.

L'infrastructure technique renforce ces effets. Sur le web, 54 % de plus de 1,3 milliard de requêtes sont désormais servies via un CDN, tandis que HTTP/3 est certes disponible sur environ 30 % des pages, mais n'est réellement utilisé que pour 7 à 9 % des premières pages vues (Web Almanac 2024, HTTP). Le cache en edge et HTTP/3 réduisent le TTFB et donc le point de départ du LCP, sans qu'il soit nécessaire de modifier le code frontend.

Une diffusion plus rapide et bien mise en cache profite en outre au crawl budget et aux crawlers IA, qui parcourent le web dans des volumes croissants : Googlebot a progressé de 96 % entre mai 2024 et mai 2025 et détient environ 50 % de la part des crawlers, tandis que GPTBot est passé de 2,2 à 7,7 % (Cloudflare). Une page performante, servie de manière prévisible, est donc aussi un atout pour la Generative Engine Optimization (GEO).

Erreurs fréquentes dans l'optimisation des CWV

• Prendre les valeurs de laboratoire pour la réalité : un score Lighthouse vert en laboratoire ne dit rien de ce que Google évalue. Ce qui compte, c'est le 75e percentile des utilisateurs réels.
• Charger l'image LCP en lazy loading : l'erreur auto-infligée la plus fréquente pour le LCP. L'élément situé au-dessus de la ligne de flottaison ne doit jamais être chargé en différé.
• Confondre INP et FID : si tu optimises encore pour le FID, tu mesures la mauvaise grandeur. Depuis mars 2024, l'INP est la seule métrique d'interactivité pertinente.
• Ne vérifier le CLS qu'en haut de page : les sauts de mise en page surviennent souvent au défilement ou lors d'insertions tardives. Le CLS est mesuré sur tout le cycle de vie de la page.
• Ne tester que sur desktop : Google évalue mobile et desktop séparément, et sur mobile, nettement moins d'origines valident les trois valeurs (43 contre 54 %, Web Almanac 2024). Les tests doivent se faire sur mobile, avec CPU et réseau bridés.

Mesure : laboratoire ou terrain, et les bons outils

La distinction la plus importante est celle entre données de laboratoire et données terrain. Les données de laboratoire (lab) sont produites dans un environnement contrôlé, par exemple dans Lighthouse, et servent au débogage et aux comparaisons reproductibles. Elles n'entrent toutefois pas dans le classement. Les données terrain (field) proviennent d'utilisateurs réels et sont évaluées au 75e percentile (web.dev). Seules ces données d'utilisateurs réels comptent pour l'évaluation.

• Chrome UX Report (CrUX) : la source officielle de données terrain, agrégées à partir d'utilisateurs réels de Chrome. Base du rapport de la Search Console et de PageSpeed Insights.
• PageSpeed Insights : combine les données terrain CrUX en haut avec une exécution Lighthouse en laboratoire en dessous. Idéal pour voir côte à côte l'état réel et la cause technique.
• Rapport CWV de la Search Console : regroupe les URL en good, needs improvement et poor sur la base des données terrain et montre l'évolution dans le temps pour l'ensemble de la propriété.
• RUM et web-vitals.js : une mesure maison sur utilisateurs réels dans le code, par exemple via la bibliothèque web-vitals.js, fournit des données terrain en continu et un diagnostic granulaire, y compris pour des outils comme DebugBear.

Si tu sépares rigoureusement laboratoire et terrain, tu évites l'erreur d'interprétation la plus courante : prendre un bon résultat de laboratoire pour une Core Web Vital validée.

Les CWV comme signal de classement et le business case

L'attente réaliste est la suivante : les Core Web Vitals ne remplacent ni la pertinence ni un contenu de qualité. Google indique explicitement qu'il n'existe pas de signal unique et qu'il veut toujours afficher la réponse la plus pertinente, même avec une expérience sur la page perfectible, mais qu'une bonne expérience sur la page peut faire la différence dans les recherches pour lesquelles il existe beaucoup de contenu utile (Google Search Central). Les CWV agissent donc comme amplificateur et critère de départage, pas comme raccourci pour contourner un contenu faible.

Le levier le plus fort est souvent la conversion. L'étude de cas redBus documentée par Google montre qu'une optimisation ciblée de l'INP a augmenté les ventes de 7 %, l'INP lui-même s'étant amélioré de 72 %, notamment grâce à des gestionnaires de scroll avec debounce et à moins d'appels d'API (web.dev, redBus). Ces chiffres proviennent d'un cas international, mais le mécanisme est transposable : des interactions plus rapides réduisent les abandons et augmentent les achats. Dans le contexte autrichien, où la majorité des accès à Internet se fait sur mobile (Statista), chaque amélioration mobile de l'INP ou du LCP touche directement une grande partie des visiteurs. Le business case des CWV est donc moins un argument SEO qu'un argument de chiffre d'affaires, avec un effet secondaire sur le SEO.

Pour aller plus loin

Les Core Web Vitals sont les plus efficaces lorsqu'elles s'intègrent dans l'ensemble de la stack SEO technique. Le LCP dépend du TTFB, donc du cache Edge/CDN et de HTTP/3 ; l'INP, de la stratégie JavaScript et de rendu ; et les trois profitent d'une architecture Next.js propre avec un minimum de JavaScript côté client. En investissant ici, tu améliores à la fois la diffusion vers les crawlers classiques et vers les crawlers IA, et donc la visibilité GEO. Pour approfondir le sujet, consulte les articles sur le SEO JavaScript et le rendu, HTTP/3 et l'infrastructure de performance, l'Edge SEO au niveau du CDN, le CDN et la localisation des serveurs ainsi que sur l'architecture SEO de Next.js.