Core Web Vitals : comment mesurer et corriger le LCP, l'INP et le CLS

En bref : les Core Web Vitals sont trois métriques que Google utilise pour décrire l'expérience réelle des utilisateurs : Largest Contentful Paint (LCP, chargement, bon à 2,5 s ou moins), Interaction to Next Paint (INP, réactivité, bon à 200 ms ou moins) et Cumulative Layout Shift (CLS, stabilité visuelle, bon à 0,1 ou moins). Chacune est évaluée au 75e centile des visites Chrome réelles sur 28 jours, séparément pour mobile et ordinateur. Google indique qu'elles sont utilisées par ses systèmes de classement, mais la pertinence passe avant tout. Pour les corriger, décomposez chaque métrique en ses parties et traitez d'abord la plus importante.

La plupart des conseils sur les Core Web Vitals sont des listes de cinquante astuces. C'est pourquoi des équipes consacrent un sprint à la « performance » sans voir leurs chiffres bouger. Les métriques sont plus structurées que cela : chacune se décompose en quelques parties mesurables, et une seule d'entre elles est généralement responsable de l'essentiel du problème.

Ce guide présente ce que mesurent les trois métriques, les seuils en vigueur en octobre 2026, la source de données à privilégier, ce que Google dit réellement du classement, et un plan de correction fondé sur le diagnostic pour chaque métrique, d'après la documentation officielle de Google sur web.dev.

Ce que mesurent les Core Web Vitals

D'après la présentation des Web Vitals sur web.dev, l'ensemble actuel et stable comprend trois métriques :

Les seuils correspondent au tableau de la page À propos de PageSpeed Insights.

La règle du 75e centile

Google ne juge pas une page sur sa moyenne ni sur un test isolé. Web.dev indique qu'un bon seuil de mesure est « le 75e centile des chargements de page, segmenté entre mobile et ordinateur ». Autrement dit : au moins trois visites réelles sur quatre doivent atteindre le seuil « bon ». Pour réussir l'évaluation, une page doit obtenir un bon résultat au 75e centile sur les trois métriques.

Cela a deux conséquences que l'on oublie souvent :

1. Mobile et ordinateur sont séparés. Une page peut être bonne sur ordinateur et mauvaise sur mobile. Le mobile est généralement le plus difficile, car les téléphones ont des processeurs et des réseaux plus lents.
2. Vos visiteurs les plus lents décident du résultat. Si un quart de vos visiteurs utilise de vieux téléphones Android sur des connexions faibles, leur expérience est votre score. Tester sur un ordinateur portable récent avec le Wi-Fi du bureau n'apprend presque rien.

L'INP a remplacé le FID en 2024

Interaction to Next Paint a remplacé First Input Delay (FID) comme Core Web Vital le 12 mars 2024. Le FID ne mesurait que le délai avant que le navigateur commence à traiter la première interaction. L'INP couvre les clics, les appuis tactiles et les pressions de touches pendant toute la visite, ainsi que le temps total jusqu'à l'affichage de l'image suivante. De nombreux sites qui réussissaient facilement le FID échouent à l'INP, car la lenteur venait toujours du travail effectué après la première action, que le FID ne comptait pas. Si vous voyez encore le FID dans un ancien rapport ou un plugin, ignorez-le.

Web.dev précise aussi que les Core Web Vitals stables « ne changeront pas plus d'une fois par an », et que les nouvelles métriques candidates restent au moins six mois en phase d'attente, ce qui vous laisse un préavis avant tout changement de règles.

Données terrain vs données de laboratoire

Il existe deux types de données de performance, et les confondre est la raison la plus courante pour laquelle des équipes corrigent le mauvais problème.

Quelques précisions tirées de la documentation de Google :

• CrUX est une moyenne glissante sur 28 jours, mise à jour quotidiennement, selon la documentation de l'API CrUX. Elle peut être interrogée pour une origine entière ou une seule URL, et filtrée par mobile, ordinateur ou tablette.
• PageSpeed Insights affiche les deux. Sa section terrain utilise les 28 derniers jours de données CrUX. Si une URL a trop peu de visites, il se rabat sur les données de l'origine entière ; si l'origine est trop petite, il n'y a aucune donnée terrain (À propos de PageSpeed Insights). La section laboratoire et le score de 0 à 100 proviennent de Lighthouse.
• Lighthouse ne peut pas mesurer l'INP. Web.dev indique que les outils qui chargent les pages « dans un environnement simulé sans utilisateur ne peuvent pas mesurer l'INP », et suggère le Total Blocking Time (TBT) comme indicateur de substitution en laboratoire.
• Le rapport Core Web Vitals de la Search Console regroupe les pages offrant une expérience similaire et attribue à chaque groupe le statut de sa métrique la plus lente pour ce type d'appareil. Il utilise les données CrUX des 28 derniers jours (aide du rapport Core Web Vitals).

La règle pratique : les données terrain décident si vous avez un problème, les données de laboratoire aident à en trouver la cause. Un score Lighthouse de 98 avec un mauvais LCP terrain signifie que vos utilisateurs réels vivent une expérience moins bonne que la simulation, souvent à cause d'appareils lents, de publicités, de personnalisation ou de scripts tiers que le test en laboratoire ne déclenche pas.

Quel poids les Core Web Vitals ont-ils dans le classement ?

La documentation de Google sur l'expérience de la page est claire dans les deux sens :

• « Les Core Web Vitals sont utilisés par nos systèmes de classement », et Google recommande d'obtenir de bons Core Web Vitals « pour réussir dans la Recherche ».
• Il n'existe « aucun signal unique » pour l'expérience de la page ; les systèmes de classement principaux examinent une variété de signaux.
• « Google Search cherche toujours à afficher le contenu le plus pertinent, même si l'expérience de la page est médiocre. »
• De bons résultats dans la Search Console ou dans des outils tiers ne garantissent pas que vos pages seront classées en tête.
• « Chercher à obtenir un score parfait pour des raisons purement SEO n'est peut-être pas le meilleur usage de votre temps. »

Notre lecture : les Core Web Vitals ne feront pas passer une page non pertinente devant une page pertinente, mais ils peuvent compter entre des pages de qualité comparable, et ils comptent directement pour les utilisateurs. Une fiche produit qui met cinq secondes à afficher sa photo, ou un bouton « Acheter » qui se fige une demi-seconde, fait perdre des clients quel que soit le classement. Visez « bon » sur les trois métriques, puis cessez de courir après les points et revenez au contenu.

Étape 1 : identifier la métrique en échec et où

Avant de toucher au code :

1. Ouvrez le rapport Core Web Vitals de la Search Console, en commençant par le mobile. Notez quelle métrique échoue et quels groupes d'URL sont concernés (fiches produit, articles de blog, page d'accueil).
2. Choisissez une URL représentative par groupe en échec et analysez-la dans PageSpeed Insights. Vérifiez si les données terrain concernent cette URL ou l'origine.
3. Corrigez un gabarit à la fois. Les problèmes de Core Web Vitals sont presque toujours des problèmes de gabarit : toutes les fiches produit partagent le même composant d'image, les mêmes scripts et la même mise en page.

Notre vérificateur Core Web Vitals gratuit offre une première lecture rapide sans compte : il récupère depuis CrUX le LCP, l'INP et le CLS au 75e centile de votre origine pour les visiteurs sur mobile, et mesure le temps de réponse du serveur, le poids du HTML, la compression, les scripts bloquant le rendu dans le head de la page et les formats d'image de votre page d'accueil.

Étape 2 : corriger le LCP par ses quatre sous-parties

Le LCP correspond au temps nécessaire pour afficher la plus grande image ou le plus grand bloc de texte dans la zone visible. Les éléments éligibles comprennent <img>, <video>, les éléments avec une image d'arrière-plan CSS url() et le texte de niveau bloc (LCP sur web.dev). Sur la plupart des fiches produit et pages d'atterrissage, il s'agit de l'image principale.

Optimize LCP décompose le LCP en quatre parties dont la somme donne le total :

Web.dev qualifie ces proportions de « lignes directrices, pas de règles strictes », mais elles sont très utiles pour le diagnostic. Le panneau Performance de Chrome DevTools affiche la décomposition pour un chargement enregistré. La partie qui dépasse largement sa part est celle par laquelle commencer.

TTFB élevé

Le TTFB inclut les redirections, l'établissement de la connexion et le traitement côté serveur. Le guide TTFB de web.dev suggère 0,8 seconde ou moins comme objectif approximatif, tout en précisant que le TTFB n'est pas lui-même un Core Web Vital.

• Servez le HTML depuis un CDN et mettez-le en cache en périphérie, même brièvement. The most effective ways to improve Core Web Vitals cite le CDN comme le meilleur moyen de réduire le TTFB.
• Supprimez les chaînes de redirections, y compris celles issues des publicités et des liens raccourcis.
• Surveillez les paramètres d'URL uniques (issus de l'analytics ou des campagnes) qui font de chaque requête un échec de cache.
• Analysez les requêtes de base de données lentes et le rendu côté serveur du gabarit de page.

Délai de chargement de la ressource élevé

C'est souvent la sous-partie la plus lourde et généralement la moins coûteuse à corriger. Le navigateur aurait pu lancer plus tôt le téléchargement de l'image, mais il ne la connaissait pas.

• Placez l'image LCP dans le HTML initial sous forme de <img src> ou srcset classique. Les images insérées par JavaScript, ou utilisant data-src pour une bibliothèque de chargement différé, sont découvertes tardivement.
• Ne chargez jamais l'image LCP en lazy-loading. Retirez loading="lazy" de l'image principale ; web.dev est clair : « ne jamais charger en différé votre image LCP ».
• Ajoutez fetchpriority="high" à l'image LCP, et à une ou deux images au maximum.
• Si l'image est un arrière-plan CSS, préchargez-la avec <link rel="preload"> et une priorité de chargement élevée, ou passez à une balise <img>.
• Servez les images critiques depuis la même origine que le HTML lorsque c'est possible, afin de réutiliser la connexion.

Durée de chargement de la ressource élevée

• Servez l'image à la taille à laquelle elle est affichée, avec srcset et sizes, afin que les téléphones ne téléchargent pas une image pour ordinateur.
• Utilisez des formats modernes comme AVIF ou WebP, et compressez correctement.
• Utilisez un CDN d'images qui redimensionne et convertit automatiquement.
• Réduisez les autres téléchargements à haute priorité qui se disputent la bande passante au même moment.

Délai de rendu de l'élément élevé

L'image est arrivée, mais quelque chose empêche le navigateur de l'afficher :

• CSS bloquant le rendu : réduisez-le, différez les styles non critiques, n'intégrez en ligne que de très petits CSS critiques.
• Scripts synchrones dans le <head> : ajoutez async ou defer.
• Rendu côté client : si le contenu de la page n'apparaît qu'après l'exécution d'un framework JavaScript, privilégiez le rendu côté serveur ou le prérendu.
• Scripts de tests A/B ou de personnalisation qui masquent la page jusqu'à ce qu'ils décident quelle variante afficher.
• Longues tâches JavaScript qui s'exécutent au moment où l'image est prête.

Si le LCP est un bloc de texte plutôt qu'une image, le délai et la durée de chargement de la ressource sont nuls, et le problème vient du TTFB, des ressources bloquant le rendu ou des polices web.

Étape 3 : corriger l'INP par ses trois phases

L'INP enregistre les clics, les appuis tactiles et les pressions de touches pendant toute la visite (pas le défilement ni le survol) et rapporte l'interaction la plus lente, en ignorant une valeur aberrante pour 50 interactions (INP sur web.dev). Chaque interaction comporte trois phases :

Le problème sous-jacent vient presque toujours des tâches longues : toute tâche qui dure plus de 50 millisecondes sur le thread principal. Tant qu'une tâche longue s'exécute, le navigateur ne peut pas répondre à l'utilisateur.

Réduire le délai d'entrée

• Chargez moins de JavaScript au démarrage ; l'évaluation des scripts crée des tâches longues précisément quand les utilisateurs essaient de toucher la page pour la première fois.
• Auditez votre gestionnaire de balises. Web.dev note que « les anciennes balises contenant du code inutilisé peuvent être supprimées ». Les widgets de chat, les heatmaps, les tests A/B et les scripts publicitaires exécutent souvent un travail lourd sur le thread principal.
• Utilisez l'outil Coverage de Chrome et le code splitting pour cesser de livrer du code que la page n'utilise pas.

Réduire la durée de traitement

• Faites moins de choses dans le gestionnaire d'événement. Mettez d'abord à jour ce que l'utilisateur doit voir, puis différez le reste (appels analytics, sauvegarde de l'état, recalcul des recommandations).
• Cédez la main au thread principal entre les blocs de travail. await scheduler.yield() poursuit le travail restant dans une nouvelle tâche prioritaire. Ce n'est pas pris en charge par tous les navigateurs, donc web.dev suggère de se rabattre sur setTimeout encapsulé dans une Promise (Optimize long tasks).
• Évitez le layout thrashing : lire des valeurs de mise en page (comme offsetHeight) juste après avoir modifié des styles dans la même tâche oblige le navigateur à calculer la mise en page de façon synchrone. Regroupez les lectures et les écritures.

Réduire le délai de présentation

• Gardez un DOM de petite taille. Optimize INP explique que le travail de rendu augmente avec la taille du DOM.
• Utilisez content-visibility pour ignorer le rendu des sections hors écran, comme de longues listes d'avis ou les pieds de page.
• Évitez de rendre de gros blocs de HTML en JavaScript en réponse à un clic ; ne rendez que le nécessaire.

Pour trouver l'interaction lente, regardez d'abord les données d'utilisateurs réels (quelles pages échouent), puis reproduisez dans Chrome DevTools : enregistrez une trace Performance en cliquant sur l'élément suspect avec un processeur ralenti, et cherchez les tâches longues après le clic.

Étape 4 : corriger le CLS cause par cause

Le CLS additionne les décalages de mise en page inattendus. Chaque décalage a pour score la part de la zone visible qui a bougé multipliée par la distance parcourue, les décalages sont regroupés en fenêtres de cinq secondes maximum, et le CLS correspond à la pire fenêtre (CLS sur web.dev). Les décalages survenant dans les 500 ms suivant un clic, un appui tactile ou une pression de touche sont exclus, car l'utilisateur les attendait. Le défilement ne compte pas comme une action, donc le contenu qui se décale pendant que quelqu'un fait défiler la page compte bel et bien.

Selon Optimize CLS, les causes habituelles et leurs correctifs :

Deux remarques tirées de l'expérience :

• Un espace qui disparaît provoque aussi un décalage. Web.dev avertit que retirer un espace réservé « peut provoquer autant de CLS qu'insérer du contenu ». Si un emplacement publicitaire reste vide, conservez l'espace réservé.
• Les bandeaux de cookies et les barres promotionnelles sont des coupables fréquents. Superposez-les au contenu au lieu de repousser la page vers le bas.

N'oubliez pas le cache arrière/avant

Quand les utilisateurs appuient sur Retour, une page restaurée depuis le bfcache s'affiche instantanément, sans nouveaux décalages de chargement. Web.dev qualifie l'éligibilité au bfcache de technique très efficace pour maintenir un CLS bas. Les deux obstacles les plus courants, d'après le guide bfcache de web.dev : les écouteurs d'événement unload (utilisez pagehide à la place) et l'en-tête Cache-Control: no-store sur des pages qui ne contiennent pas de données sensibles. Chrome DevTools propose un test sous Application › Back/forward cache.

Un exemple chiffré (chiffres hypothétiques)

Ce qui suit est un exemple hypothétique, pas des données réelles. Fernwood Home, une boutique de meubles en ligne inventée, échoue à l'évaluation Core Web Vitals sur mobile pour le gabarit de ses fiches produit. Valeurs terrain au 75e centile :

LCP : 4,6 s

Une trace DevTools sur un profil de téléphone ralenti montre que l'élément LCP est la photo principale du produit. La décomposition :

Le délai de chargement de la ressource représente plus de trois fois sa part cible, il passe donc en premier. Les correctifs : afficher la première photo sous forme de simple <img> dans le HTML serveur, retirer loading="lazy", ajouter fetchpriority="high", servir de l'AVIF et du WebP aux tailles de téléphone via srcset, mettre le HTML en cache au niveau du CDN en ignorant les paramètres de suivi dans la clé de cache, et charger le script A/B avec defer.

Résultat en laboratoire après la mise en production : TTFB 0,7 s, délai de chargement 0,2 s, durée de chargement 0,6 s, délai de rendu 0,3 s, soit un LCP de 1,8 s.

INP : 340 ms

Les données terrain pointent vers la fiche produit ; en reproduisant dans DevTools, l'interaction lente est le bouton « Ajouter au panier ». La trace montre environ 90 ms de délai d'entrée (un widget de chat et deux balises de suivi s'exécutant au même moment), 190 ms de traitement (le gestionnaire refait le rendu de tout le panneau du panier et envoie trois appels analytics de façon synchrone) et 60 ms de délai de présentation.

Les correctifs : charger le widget de chat seulement après la première interaction de l'utilisateur, afficher d'abord la mise à jour du panneau du panier, puis céder la main avant les mises à jour analytics et recommandations. Mesure en laboratoire sur le même profil ralenti : environ 150 ms.

CLS : 0,21

Trois causes : un widget d'étoiles d'avis inséré au-dessus du prix après le chargement, un échange de police web qui refait le retour à la ligne du titre du produit, et des vignettes sans dimensions. Les correctifs : réserver la hauteur du widget d'avis, précharger la police du titre et ajuster la police de repli avec size-adjust, ajouter width et height à chaque vignette. CLS en laboratoire : 0,04.

Lire le résultat

Les chiffres de laboratoire confirment que les correctifs fonctionnent. Les chiffres terrain, qui décident de l'évaluation, évoluent à mesure que de nouvelles visites remplacent les anciennes dans la fenêtre de 28 jours. Fernwood doit s'attendre à un changement progressif sur environ quatre semaines, puis cliquer sur Start tracking dans le rapport de la Search Console pour lancer la validation, qui dure elle aussi 28 jours. Si le LCP terrain se situe, disons, à 2,3 s plutôt qu'à 1,8 s, c'est normal : les vrais téléphones et réseaux sont plus lents que n'importe quel profil de laboratoire.

Erreurs courantes

• Courir après le score Lighthouse. Le score de 0 à 100 est un résumé de laboratoire. L'évaluation de Google utilise les données terrain au 75e centile.
• Tester uniquement sur ordinateur. Le mobile est évalué séparément et échoue généralement en premier.
• Tout charger en lazy-loading. Le chargement différé des images sous la ligne de flottaison est une bonne pratique ; différer l'image principale est l'une des causes les plus fréquentes d'un mauvais LCP.
• Ne corriger que la page d'accueil. L'essentiel du trafic arrive souvent sur des gabarits de produit, de catégorie ou d'article. Corrigez les gabarits qui regroupent le plus d'URL en échec.
• Ajouter encore un script. Chaque balise, widget et script de test se dispute le thread principal. Pour chaque ajout, supprimez-en un.
• S'attendre à des résultats immédiats. Les données terrain mettent environ 28 jours à refléter pleinement une mise en production.
• Négliger les bases du mobile. Une page sans balise viewport ou avec des images surdimensionnées est lente sur téléphone avant toute optimisation. Le test de compatibilité mobile gratuit vérifie ces bases.

Une checklist de départ d'une heure

1. Passez votre domaine dans le vérificateur Core Web Vitals gratuit pour obtenir le LCP, l'INP et le CLS réels sur mobile, ainsi que le temps de réponse du serveur, la compression et les scripts bloquants.
2. Ouvrez le rapport Core Web Vitals de la Search Console pour le mobile et listez les groupes d'URL en échec.
3. Pour chaque groupe en échec, analysez une URL dans PageSpeed Insights et notez quelle métrique échoue sur le terrain.
4. Pour le LCP, enregistrez une trace DevTools et notez les quatre sous-parties. Corrigez d'abord la plus importante.
5. Pour l'INP, trouvez l'interaction lente et les tâches longues qui la suivent.
6. Pour le CLS, vérifiez les images sans dimensions, le contenu injecté tardivement et les polices.
7. Mettez en production, confirmez en laboratoire, puis vérifiez les données terrain après deux et quatre semaines.

Les Core Web Vitals ne sont qu'un volet de la santé technique. Notre guide d'audit SEO technique les replace dans leur contexte avec l'exploration, l'indexation, les redirections et les données structurées.

Comment Searvia vous aide avec les Core Web Vitals

Le vérificateur Core Web Vitals gratuit ne demande aucun compte et vous donne en moins d'une minute le tableau des utilisateurs réels de votre site. Dans Searvia, l'onglet Page speed d'un projet de site web lance chaque semaine PageSpeed Insights sur vos pages les plus visitées et affiche à la fois les scores de laboratoire et les données réelles des utilisateurs Chrome pour le LCP, l'INP et le CLS des 28 derniers jours. Les correctifs sont classés selon le temps qu'ils font gagner, et Write a fix plan for my files with AI transforme les principaux éléments en modifications pas à pas adaptées à votre stack (3 crédits). Connectez la Search Console pour voir les clics et les positions à côté de la vitesse, afin de savoir si un gabarit plus rapide a réellement apporté plus de trafic. Le guide d'aide sur la vitesse de page explique la configuration en environ deux minutes.