--- title: "Core Web Vitals : LCP, INP et CLS expliqués simplement" description: "Core Web Vitals : ce que mesurent le LCP, l’INP et le CLS, les seuils de Google, comment tester votre site et améliorer chaque indicateur, sans jargon." canonical_url: "https://studiofogg.fr/journal/core-web-vitals-lcp-inp-cls" --- > Index of every page on this site: [llms.txt](https://studiofogg.fr/llms.txt) Les Core Web Vitals sont trois indicateurs définis par Google pour mesurer l’expérience réelle des visiteurs d’une page. Le LCP (*Largest Contentful Paint*) mesure la vitesse d’affichage du contenu principal : il est bon jusqu’à 2,5 secondes. L’INP (*Interaction to Next Paint*) mesure la réactivité aux clics, aux touchers et au clavier : bon jusqu’à 200 millisecondes. Le CLS (*Cumulative Layout Shift*) mesure la stabilité de la mise en page : bon jusqu’à 0,1. Une page les réussit quand, pour chacun, au moins 75 % des visites respectent le seuil. Google s’en sert dans son classement, sans qu’ils remplacent la pertinence d’un contenu. Ce guide, qui prolonge [nos articles pour être trouvé sur Google](https://studiofogg.fr/journal/rubrique/seo-visibilite-locale), explique comment les lire, les tester gratuitement et les améliorer. ## Trois indicateurs, trois questions Chaque indicateur répond à une question de vos visiteurs. Les trois sigles ont chacun [leur définition dans notre glossaire du web](https://studiofogg.fr/glossaire#lcp) ; voici l’essentiel.
Indicateur La question du visiteur Bon Médiocre
LCP — chargement « La page s’affiche-t-elle vite ? » 2,5 s ou moins Plus de 4 s
INP — réactivité « Répond-elle quand je touche un bouton ? » 200 ms ou moins Plus de 500 ms
CLS — stabilité visuelle « Le contenu reste-t-il en place ? » 0,1 ou moins Plus de 0,25
**Le LCP** retient le plus grand élément visible à l’écran — une image, une vidéo, une image de fond ou un bloc de texte — et mesure le temps écoulé, depuis le début de la navigation, jusqu’à son affichage. Il cesse de chercher dès que le visiteur clique ou touche l’écran, fait défiler la page ou tape au clavier ([définition du LCP](https://web.dev/articles/lcp)). **L’INP** observe toutes les interactions de la visite : clics, touchers et touches du clavier, mais ni le survol ni le défilement. Il retient la plus lente, en écartant une valeur extrême par tranche de 50 interactions ([fonctionnement de l’INP](https://web.dev/articles/inp)). **Le CLS** additionne les décalages inattendus de la pire rafale : des décalages espacés de moins d’une seconde, sur cinq secondes au plus. Un mouvement qui survient moins d’une demi-seconde après un clic, un toucher ou une frappe au clavier, comme un menu qui s’ouvre, ne compte pas. ## Les seuils, et la règle des 75 % Une même page n’est pas vécue de la même façon par tous : un visiteur sur la fibre, un autre en 4G dans le tramway nantais, un troisième sur un vieux téléphone. Google ne juge donc ni la meilleure visite ni la moyenne, mais le 75ᵉ centile : classez les visites de la plus rapide à la plus lente, c’est la valeur qui sépare les trois quarts les plus rapides du quart restant. Selon l’équipe Chrome, ce choix [assure qu’une majorité de visites atteint l’objectif sans que quelques valeurs extrêmes faussent le résultat](https://web.dev/articles/defining-core-web-vitals-thresholds). À retenir : - **Mobile et ordinateur sont mesurés séparément**, avec les mêmes seuils. - **Les trois indicateurs doivent être bons** : dans la Search Console, le plus mauvais des trois donne son état à un groupe de pages. - **Les données réelles couvrent les 28 derniers jours** de visites. ## Tester votre site : données réelles ou laboratoire Les données réelles, dites « de terrain », viennent des visites d’utilisateurs de Chrome, réunies dans le rapport CrUX : elles font le verdict. Les tests « de laboratoire » chargent la page une fois, sur un appareil et une connexion simulés : ils aident à trouver les causes.
Votre question L’outil Ce qu’il mesure
Mes pages passent-elles les seuils ? Rapport Core Web Vitals de la Search Console Les visites réelles, par groupe de pages
Et cette page précise ? PageSpeed Insights, partie haute Les visites réelles de l’adresse, ou de tout le site
Pourquoi est-elle lente ? PageSpeed Insights, partie basse (Lighthouse) Un chargement simulé
Qu’est-ce qui ralentit ce clic ? Outils de développement de Chrome Votre propre visite, en direct
Le [rapport Core Web Vitals de la Search Console](https://support.google.com/webmasters/answer/9205520?hl=fr) regroupe les adresses qui offrent une expérience similaire, souvent les pages d’un même modèle, et classe chaque groupe « Bon », « Amélioration nécessaire » ou « Médiocre ». Faute de visites suffisantes — cas d’un site récent ou peu visité —, il affiche « Aucune donnée disponible ». [PageSpeed Insights](https://developers.google.com/speed/docs/insights/v5/about?hl=fr) montre d’abord les données réelles de l’adresse testée, ou de tout le site si elle manque de visites : l’évaluation est réussie si les trois indicateurs sont bons, ou le LCP et le CLS faute de données sur l’INP. Plus bas, la note sur 100 d’un test Lighthouse sert au diagnostic, pas au verdict. Ce test ne clique nulle part : il ne mesure pas l’INP, mais le *Total Blocking Time* (TBT), un indicateur voisin qui ne le remplace pas. Dans les outils de développement de Chrome, enfin, le [panneau consacré aux performances](https://developer.chrome.com/docs/devtools/performance/overview) affiche en direct le LCP de votre visite, en désignant l’élément retenu, et son CLS, puis l’INP dès que vous interagissez. Il peut aussi les comparer aux données réelles. ## Améliorer le LCP : afficher plus tôt le contenu principal Le LCP se décompose en quatre temps, que [le guide d’optimisation de web.dev](https://web.dev/articles/optimize-lcp) invite à mesurer un par un :
Étape Ce qui se passe Ce qui l’allonge souvent Les leviers
1. Réponse du serveur Le premier octet de la page arrive Redirections, serveur lent, aucun cache Cache de pages, CDN, moins de redirections
2. Découverte Le navigateur repère l’image principale Image appelée par un script ou chargée en différé Image dans le HTML, priorité haute
3. Téléchargement L’image arrive Fichier lourd ou trop grand pour l’écran Format récent, taille adaptée
4. Affichage L’élément apparaît à l’écran Feuilles de style et scripts bloquants Scripts différés, rendu côté serveur
Sur une page bien optimisée, la réponse du serveur et le téléchargement pèsent chacun environ 40 % du LCP, les deux autres temps moins de 10 % chacun. Sur les sites lents, la répartition est tout autre : dans [une analyse des données réelles de Chrome](https://web.dev/blog/common-misconceptions-lcp), mise à jour en août 2024, pour le site médian au LCP médiocre (LCP sur une image, valeurs au 75ᵉ centile), le premier octet arrivait après 2,27 secondes et le navigateur attendait encore 1,29 seconde avant de commencer à télécharger l’image… qui n’a ensuite demandé que 350 millisecondes. Compresser l’image ne ferait gagner qu’une partie de ces 350 millisecondes : il faut d’abord accélérer la réponse du serveur et faire découvrir l’image plus tôt. L’image principale doit donc figurer dans le HTML, avec ses dimensions et une priorité haute, sans chargement différé : ```text La salle du restaurant, côté Loire ``` Réservez `fetchpriority="high"` à une ou deux images au plus ; une image appelée par la feuille de style ou par un script se signale plus tôt avec une balise de préchargement. Côté serveur, des pages générées à l’avance sont servies sans calcul : c’est l’une des raisons pour lesquelles nous recommandons un site statique pour un site vitrine. ## Améliorer l’INP : répondre vite à chaque geste Entre le geste et la réponse, trois délais s’additionnent : l’attente avant que le navigateur ne s’occupe du geste, l’exécution des scripts qui y répondent, puis l’affichage de la nouvelle image. Tous trois dépendent du fil principal du navigateur, qui exécute aussi les scripts de la page : un travail qui l’occupe plus de 50 millisecondes y forme une [« tâche longue »](https://web.dev/articles/optimize-long-tasks), pendant laquelle le geste du visiteur attend. Les leviers : - **Charger moins de JavaScript au démarrage**, y compris celui des services tiers (chat, widgets d’avis, balises marketing), qui s’exécute souvent sur le même fil que vos boutons. - **Découper les tâches longues** pour rendre la main au navigateur, qui peut alors traiter un clic en attente. - **Montrer la réaction d’abord** — bouton enfoncé, indicateur de chargement —, puis faire le travail moins urgent. - **Garder une page légère** : plus elle contient d’éléments, plus chaque mise à jour de l’affichage coûte. - **Animer en CSS** plutôt qu’en JavaScript, comme l’explique [notre article sur le coût caché des animations](https://studiofogg.fr/journal/animations-site-web-utiles-ou-nuisibles). Pour vérifier, interagissez avec la page pendant son chargement : c’est souvent là que le fil principal est le plus occupé, rappelle [le guide de web.dev pour optimiser l’INP](https://web.dev/articles/optimize-inp). Ralentissez aussi le processeur dans les outils de développement de Chrome : leur panneau des performances liste chaque interaction enregistrée. ## Améliorer le CLS : une page qui ne bouge pas Chaque décalage reçoit un score : la part de l’écran touchée, multipliée par la distance parcourue. Dans l’exemple de [la documentation du CLS](https://web.dev/articles/cls), un bloc qui occupe la moitié de l’écran et descend d’un quart de la hauteur de l’écran touche 75 % de la surface, sur 25 % de distance : 0,75 × 0,25 = 0,1875, soit déjà plus que le seuil de 0,1. Les causes fréquentes ont chacune leur parade, détaillée dans [le guide d’optimisation du CLS](https://web.dev/articles/optimize-cls) : - **Images et vidéos sans dimensions** : déclarez leur largeur et leur hauteur, ou un rapport d’aspect en CSS. - **Publicités, vidéos et cartes intégrées** : réservez leur place dès le départ, sans la refermer s’il n’y a rien à afficher. - **Contenus insérés en haut de page après l’affichage** — bandeau promotionnel, formulaire, alerte : réservez leur place, ou affichez-les en surimpression ou plus bas dans la page. Les bandeaux cookies en sont un cas fréquent : [notre guide du bandeau cookies conforme à la CNIL](https://studiofogg.fr/journal/bandeau-cookies-regles-cnil) montre comment l’afficher sans décaler la page. - **Polices web** : une police de secours aux proportions ajustées évite que le texte ne bouge à l’arrivée de la police définitive. - **Animations de position ou de taille** : animez plutôt `transform`, qui ne décale pas la mise en page. Enfin, un test Lighthouse ne voit pas un décalage provoqué après le chargement, au défilement par exemple ; les données réelles, si. Et une page compatible avec le cache de navigation (*back/forward cache*) revient intacte, sans nouveau décalage, quand le visiteur clique sur « Précédent ». ## Core Web Vitals et référencement : ce qu’il faut en attendre Google est clair sur le principe : [les Core Web Vitals sont utilisés par ses systèmes de classement](https://developers.google.com/search/docs/appearance/page-experience?hl=fr), alors que les autres aspects de l’expérience de page n’aident pas directement à mieux se classer. Il l’est tout autant sur les limites : il n’existe pas de signal unique d’expérience de page, Google cherche toujours à afficher le contenu le plus pertinent, même si l’expérience est médiocre, et de bons résultats dans la Search Console ne garantissent pas d’apparaître en tête des résultats. Concrètement : - **Un départage, pas un raccourci.** Quand beaucoup de pages répondent aussi bien à une recherche, une bonne expérience peut faire la différence, selon Google ; elle ne compense pas un contenu moins utile. - **Une évaluation surtout page par page**, avec quelques évaluations à l’échelle du site : corrigez d’abord les modèles de pages qui comptent. - **Pas de score parfait à poursuivre** : pour Google, viser la note maximale pour le seul SEO n’est pas forcément le meilleur usage de votre temps. Si votre site n’apparaît pas du tout dans Google, la vitesse est rarement en cause : cherchez d’abord [pourquoi vos pages ne sont pas indexées](https://studiofogg.fr/journal/pourquoi-mon-site-n-apparait-pas-sur-google). Une chute brutale de trafic s’explique, elle aussi, rarement par des indicateurs calculés sur 28 jours : [notre méthode de diagnostic d’une baisse de trafic sur Google](https://studiofogg.fr/journal/baisse-de-trafic-google-trouver-la-cause) passe les pistes en revue. Enfin, la performance n’est qu’un chantier de [notre accompagnement en référencement naturel](https://studiofogg.fr/services/referencement-naturel-seo-nantes), aux côtés des contenus, du maillage et de la visibilité locale. ## Ce qui évolue : les navigations « douces » Sur les sites conçus comme des applications, JavaScript change le contenu et l’adresse sans recharger la page : c’est une navigation « douce » (*soft navigation*). Un site Nuxt, la technologie que nous utilisons, fonctionne ainsi après la première page. Jusqu’ici, CrUX n’enregistrait que le premier chargement et lui rattachait tous les clics et décalages de la visite. Chrome 151, sorti en juillet 2026, sait désormais les détecter, et [depuis la publication de CrUX d’octobre 2026](https://web.dev/blog/crux-experimental-soft-navs), annoncée le 13 octobre, des versions expérimentales des trois indicateurs en tiennent compte. Pour la plupart des sites, les valeurs ne bougent pas ou presque : seuls 7 à 11 % des origines (en pratique, des sites) utilisent ces navigations pour plus de la moitié de leurs pages vues. Pour les autres, l’écart est net : sur Android, parmi les sites dont 75 à 100 % des navigations sont douces, la part de ceux qui ont un bon LCP passe de 26 % à 87 %. Ces sites ne sont pas plus rapides pour autant : sur tout site, les pages suivantes réutilisent ce qui a déjà été téléchargé. Pendant cette évaluation, ni les scores officiels ni la Search Console ne changent ; Google vise une sortie de la phase expérimentale en mai 2027, sous réserve des retours, après quoi la Search Console passera à ces nouvelles données. Les seuils, eux, n’ont pas bougé : ce sont toujours ceux de web.dev et de l’aide de la Search Console. Google s’engage d’ailleurs à ne modifier les Core Web Vitals stables qu’une fois par an au plus, avec préavis ([cycle de vie des indicateurs](https://web.dev/articles/vitals)) : méfiez-vous des « nouveaux seuils » annoncés sans source officielle. ## Par où commencer ? 1. **Ouvrez le rapport Core Web Vitals** de la Search Console et repérez, sur mobile comme sur ordinateur, les groupes de pages en échec et l’indicateur en cause. Sans données réelles, testez directement vos pages clés. 2. **Testez une adresse type** de chaque groupe dans PageSpeed Insights, puis dans les outils de développement de Chrome. 3. **Corrigez d’abord ce qui touche le plus de pages** — un modèle de pages avant une page isolée —, en vérifiant chaque correctif en laboratoire. 4. **Attendez quatre semaines** avant de juger sur les données réelles. Vous préférez confier ce diagnostic ? [Notre service d’optimisation des Core Web Vitals](https://studiofogg.fr/services/optimisation-vitesse-site-web-nantes) part des données réelles de vos visiteurs, classe les correctifs par gain attendu et vérifie le résultat 28 jours plus tard. ## Sitemap See the full [sitemap](https://studiofogg.fr/sitemap.md) for all pages.