Audit de site web › Core Web Vitals

Core Web Vitals : LCP, INP et CLS expliqués simplement, avec leurs seuils et leurs corrections

En bref : les Core Web Vitals sont trois mesures prises sur de vrais visiteurs. Le LCP dit au bout de combien de temps le gros du contenu apparaît, l'INP combien de temps la page met à réagir à un clic, le CLS à quel point elle bouge sous les yeux du lecteur. Google juge une page « bonne » quand 3 visites sur 4 restent sous 2,5 secondes, 200 millisecondes et 0,1. Sur un site vitrine, quatre coupables reviennent sans cesse : la grande photo d'en-tête, les polices, le bandeau cookies et le widget de chat.

Trois questions qu'un visiteur se pose sans le savoir

Quand quelqu'un ouvre votre page sur son téléphone, il se demande : « est-ce que ça s'affiche ? », « est-ce que ça répond quand j'appuie ? », « est-ce que ça arrête de bouger ? ». Chaque Core Web Vital chiffre une de ces questions, selon les définitions de Google sur web.dev.

LCP : le rideau qui se lève

Image mentale : au théâtre, le LCP est le moment où le rideau est assez levé pour voir le décor principal. Peu importe que les coulisses soient encore en désordre : le spectateur sait qu'il est au bon endroit.

Techniquement, le Largest Contentful Paint est le temps écoulé entre le début de la navigation et l'affichage du plus grand élément visible à l'écran : une image, l'affiche d'une vidéo, une image de fond déclarée en CSS ou un bloc de texte. Le navigateur écarte ce qui ressemble à un simple fond (un élément qui couvre tout l'écran, une image presque vide, un élément transparent). Source : web.dev, « Largest Contentful Paint (LCP) ».

Sur la page d'accueil d'un artisan ou d'un commerce, l'élément mesuré est presque toujours la grande photo du haut, ou le gros titre posé dessus. Le LCP inclut aussi le temps de réponse du serveur : une photo légère ne sauve pas un hébergement qui met deux secondes à répondre.

INP : la sonnette de la porte

Image mentale : vous appuyez sur une sonnette. Si rien ne se passe pendant une demi-seconde, vous appuyez de nouveau, puis vous doutez qu'elle marche. L'INP mesure ce silence entre le geste et la première réaction visible.

L'Interaction to Next Paint observe tous les clics de souris, touchers d'écran et frappes au clavier pendant la visite. Le survol, le défilement et le zoom ne comptent pas. Pour chaque interaction, le délai se décompose en trois temps : l'attente avant que le code commence, l'exécution du code, puis l'affichage de l'image suivante. La valeur retenue est la plus longue interaction de la visite, en ignorant la pire sur chaque tranche de 50 interactions pour écarter les accidents. Source : web.dev, « Interaction to Next Paint (INP) ».

L'INP a remplacé l'ancien indicateur FID le 12 mars 2024 (annonce web.dev). Si un article parle encore du FID, il est dépassé.

CLS : la nappe qu'on tire

Image mentale : vous allez poser votre verre et quelqu'un tire la nappe de dix centimètres. Le CLS chiffre ces glissements : le bouton « Appeler » qui descend au moment où le pouce arrive, et c'est la bannière du dessus qu'on touche.

Le Cumulative Layout Shift additionne les déplacements inattendus d'éléments visibles. Les décalages qui suivent de moins de 500 millisecondes un clic ou une frappe ne sont pas comptés, puisque le visiteur les a provoqués. Les décalages sont regroupés en « rafales » : moins d'une seconde entre deux décalages, cinq secondes au plus par rafale, et le CLS retient la pire rafale de la visite. C'est un score sans unité, pas une durée. Source : web.dev, « Cumulative Layout Shift (CLS) ».

Les seuils officiels : bon, à améliorer, mauvais

Seuils publiés par Google pour chaque Core Web Vital
Mesure	Bon	À améliorer	Mauvais	Source
LCP	2,5 s ou moins	plus de 2,5 s, jusqu'à 4 s	plus de 4 s	web.dev/lcp
INP	200 ms ou moins	plus de 200 ms, jusqu'à 500 ms	plus de 500 ms	web.dev/inp
CLS	0,1 ou moins	plus de 0,1, jusqu'à 0,25	plus de 0,25	web.dev/cls

La limite « mauvais » de chaque mesure et le choix du 75^e centile sont justifiés dans « Defining the Core Web Vitals metrics thresholds » ; Google Search Central reprend les seuils « bons » sur sa page « Understanding Core Web Vitals and Google search results ». Pages consultées le 6 octobre 2026.

Le 75^e centile, sans mathématiques

Google ne juge pas votre page sur votre propre test, fait depuis le bureau avec la fibre. Il prend les visites réelles des 28 derniers jours, les range de la plus rapide à la plus lente, et regarde la valeur atteinte par trois visites sur quatre. Ce choix, explique web.dev, garantit que la plupart des visites atteignent le niveau visé tout en limitant l'effet des valeurs aberrantes.

Exemple fictif : la page d'accueil d'un salon de coiffure reçoit 100 visites mobiles en un mois. 70 affichent la photo en moins de 2 secondes, 8 entre 2 et 2,5 secondes, 22 au-delà, souvent en 4G dans le métro. La 75^e visite est à 2,4 secondes : le LCP mobile est « bon », malgré 22 visites lentes. Si la photo s'alourdit et que la 75^e visite passe à 2,7 secondes, la page bascule en « à améliorer ».

Deux règles complètent ce calcul. Mobile et ordinateur sont évalués séparément. Et dans le rapport de la Search Console, un groupe de pages prend l'état de sa pire mesure : un LCP bon et un CLS mauvais donnent un groupe « mauvais » (aide Search Console, rapport Core Web Vitals). Les outils pour lire ces chiffres sont présentés dans notre guide tester la vitesse de son site ; ici, on passe aux causes.

Les quatre coupables d'un site vitrine, et comment les corriger

Pour chaque cause, la correction dépend de l'outil qui a servi à construire le site. Les noms d'outils sont cités à titre factuel.

1. Image d'en-tête lourde, ou diaporama en haut de page (LCP)

WordPress : depuis la version 6.3, WordPress ajoute seul fetchpriority="high" à l'image qu'il juge principale et évite de la charger en différé (note officielle). Un diaporama ou une image de fond posée par un constructeur de pages échappe souvent à ce réglage : préférez une seule image, insérée comme bloc Image.
Wix : Wix conseille le JPG ou le WebP plutôt que le PNG, et de placer galeries, vidéos et widgets de boutique plus bas dans la page (aide Wix).
Site fait main : une balise <img> plutôt qu'un fond CSS, avec fetchpriority="high", et jamais loading="lazy" sur cette image : « ne chargez jamais en différé l'image du LCP », écrit web.dev.

2. Polices de caractères (LCP et CLS)

WordPress : limitez le thème à une ou deux familles et hébergez les polices sur le site plutôt que de les appeler chez un service tiers, si le thème le permet.
Wix : Wix recommande les polices système, ou le format WOFF2 pour une police personnalisée.
Site fait main : font-display: optional évite le saut au moment où la police arrive ; size-adjust aligne la taille de la police de secours (web.dev).

3. Bandeau cookies qui pousse le contenu (CLS)

WordPress et Wix : choisissez dans l'outil de consentement un affichage superposé (en bas de l'écran ou en fenêtre) plutôt qu'une barre insérée au-dessus de l'en-tête.
Site fait main : web.dev recommande de réserver la place d'un contenu qui arrive tard, ou de le superposer : un bandeau en position: fixed en bas d'écran ne décale rien.

4. Widget de chat ou de prise de rendez-vous (INP et LCP)

WordPress : chargez-le seulement sur les pages utiles, ou après un clic sur un bouton « Discuter ».
Wix : Wix conseille de faire le ménage dans les applis et codes tiers, et de limiter le nombre de widgets par page ; gardez les plus lourds hors du premier écran.
Site fait main : affichez d'abord un simple bouton et ne chargez le script du chat qu'au clic : le code lourd ne bloque plus les premiers gestes du visiteur.

Un réflexe commun aux trois cas : donnez toujours une largeur et une hauteur aux images et aux vidéos (attributs width et height, ou aspect-ratio en CSS), c'est la première recommandation de web.dev contre le CLS. Pour les causes propres à WordPress (cache, extensions, version de PHP), voyez notre guide WordPress lent.

Ce que Google dit officiellement du classement

Beaucoup d'articles exagèrent dans un sens ou dans l'autre. Voici ce qu'écrit Google Search Central, ni plus ni moins, sur sa page « Understanding page experience in Google Search results » (mise à jour du 22 septembre 2026, notre traduction) :

« Les Core Web Vitals sont utilisés par nos systèmes de classement. »
« Il n'existe pas de signal unique. » Les systèmes regardent plusieurs signaux liés à l'expérience de page.
« Google Search cherche toujours à montrer le contenu le plus pertinent, même si l'expérience de page est médiocre. »
De bons résultats dans le rapport de la Search Console ou dans d'autres outils « ne garantissent pas » que vos pages seront classées en haut des résultats.

Google ne publie aucun poids chiffré. Conclusion pratique : corrigez une page « mauvaise », car elle fait aussi fuir les visiteurs, mais ne sacrifiez pas un texte utile pour gagner 0,02 de CLS.

Faire contrôler sa page

L'Audit express à 19 € TTC mesure la vitesse mobile de votre page d'accueil et de 4 pages internes, repère les images et fichiers trop lourds, et contrôle aussi le référencement et l'accessibilité, soit 20 points au total. Vous recevez sous 24 h un rapport en français simple, avec les corrections classées par priorité. Il ne modifie rien sur votre site.

Seuils et citations vérifiés le 6 octobre 2026 sur web.dev, developers.google.com, support.google.com, make.wordpress.org et support.wix.com. L'exemple du salon de coiffure est fictif.

Questions fréquentes

Que veut dire « Core Web Vitals » ?

C'est le nom que Google donne à trois mesures de l'expérience d'un visiteur sur une page : le LCP (le contenu principal s'affiche-t-il vite ?), l'INP (la page réagit-elle vite quand on clique ?) et le CLS (la page reste-t-elle immobile pendant qu'on la lit ?). En français, on parle parfois de « signaux web essentiels » ou de « métriques essentielles ».

Qu'est-ce que le 75e centile dans les Core Web Vitals ?

Google ne regarde ni la meilleure visite ni la moyenne. Il range toutes les visites de la page, de la plus rapide à la plus lente, et prend la valeur atteinte par 3 visites sur 4. Si cette valeur est dans la zone « bonne », la page est jugée bonne, même si quelques visites restent lentes. Mobile et ordinateur sont évalués séparément.

Le FID existe-t-il encore ?

Non. Le FID (First Input Delay) a été remplacé par l'INP comme Core Web Vital le 12 mars 2024, selon l'annonce publiée sur web.dev. Le FID ne mesurait que le délai avant la première interaction ; l'INP observe tous les clics, touchers et frappes au clavier pendant la visite.

De mauvais Core Web Vitals font-ils perdre des places sur Google ?

Google indique que les Core Web Vitals sont utilisés par ses systèmes de classement, mais qu'il n'existe pas de signal unique et qu'il cherche toujours à montrer le contenu le plus pertinent, même si l'expérience de page est médiocre. De bons résultats ne garantissent pas non plus la première place. Google ne dit rien de plus précis sur leur poids.

Mon site n'a pas de données Core Web Vitals : est-ce un problème ?

Non. Les données réelles n'existent que si la page reçoit assez de visites de navigateurs Chrome sur 28 jours. Un petit site vitrine récent n'en a souvent pas. Dans ce cas, on s'appuie sur un test de laboratoire pour repérer les causes, en sachant qu'il ne mesure pas l'INP de la même façon.

Pas le temps de tout vérifier ?

Notre audit express contrôle 20 points sur votre page d'accueil et jusqu'à 4 pages internes, et vous remet un plan d'action priorisé sous 24 h, pour 19 € TTC.

Commander l'audit – 19 € TTC Voir l'offre

Guide rédigé par un agent d'intelligence artificielle (Claude) pour Pierre, PGA WEBCORPO. Publié le 2026-10-06.