// guide pilier · écosystème seo
Core Web Vitals : LCP, INP et CLS expliqués.
Trois métriques, trois seuils, et beaucoup de malentendus. Ce que Google mesure vraiment, pourquoi votre score PageSpeed contredit Search Console, le poids réel dans le classement, et le seul endroit où la performance touche directement l'indexation.
Ce que mesurent les Core Web Vitals.
Les Core Web Vitals (signaux web essentiels) sont trois métriques par lesquelles Google tente de quantifier l'expérience perçue d'une page. Chacune correspond à un moment vécu par l'utilisateur : est-ce que ça s'affiche, est-ce que ça répond, est-ce que ça bouge sous mes yeux.
75e
percentile : le seuil doit être tenu pour 75 % des visites réelles, pas en moyenne.
28
jours de fenêtre glissante CrUX. Le délai incompressible avant de voir l'effet d'un correctif.
// à retenir
Le 75e percentile change tout, et c'est la subtilité la plus coûteuse à ignorer. Un LCP moyen à 2 secondes peut cacher un quart d'utilisateurs à 5 secondes, et c'est ce quart-là que Google regarde. Optimiser pour la moyenne revient à optimiser pour les visiteurs qui allaient déjà bien. Le travail utile porte sur la traîne : mobile bas de gamme, connexions lentes, premières visites sans cache.
Leur poids réel dans le classement.
Le sujet est saturé de promesses. Il faut donc énoncer la position de Google telle qu'elle est : les Core Web Vitals départagent des pages de pertinence équivalente. Ils ne hiérarchisent pas le contenu, ils tranchent une égalité.
Un signal de départage
À pertinence égale, la page la plus rapide passe devant. Sur une SERP concurrentielle où dix pages se valent, le signal devient décisif. Sur une requête où votre contenu est objectivement le meilleur, il ne change presque rien.
→ utile en fin de parcours
Un prérequis au classement
Des sites en rouge sur les trois métriques dominent des requêtes très concurrentielles, tous les jours. La performance n'est pas un ticket d'entrée. Aucune optimisation ne sauvera une page qui rate l'intention de recherche.
→ ne compense jamais le fond
La vraie raison d'optimiser
Elle n'est pas dans la SERP. Une page lente perd des visiteurs avant même de s'afficher, et cet abandon coûte du chiffre d'affaires immédiatement, sans attendre un quelconque recalcul d'algorithme. Traiter les Core Web Vitals comme un sujet de conversion plutôt que comme un sujet SEO donne des arbitrages plus sains, et accessoirement plus faciles à défendre en interne.
Labo contre terrain : la confusion à lever.
C'est l'incompréhension numéro un du sujet, celle qui fait perdre le plus de temps. Deux familles de mesures coexistent, elles ne disent pas la même chose, et une seule compte pour Google.
Lighthouse, PageSpeed (score)
Une simulation unique, sur une machine standardisée, dans des conditions réseau simulées. Reproductible et immédiat, donc parfait pour diagnostiquer et pour vérifier un correctif en développement. Ne reflète pas vos utilisateurs.
→ outil de diagnostic
CrUX, Search Console
Les mesures collectées auprès des vrais utilisateurs de Chrome, sur 28 jours glissants, avec leurs vrais appareils. Lent à bouger, mais c'est le seul verdict que Google utilise pour classer.
→ la seule donnée qui compte
// le piège du score
Le score sur 100 de PageSpeed n'est pas les Core Web Vitals. C'est un agrégat Lighthouse qui pondère une dizaine de métriques de laboratoire, dont certaines que Google n'utilise pas pour classer. Un site peut afficher 100/100 et échouer en données de terrain, ou afficher 60/100 et passer au vert. Piloter sur ce score, c'est optimiser une simulation.
LCP : le plus gros élément visible.
Le Largest Contentful Paint mesure le temps avant l'affichage du plus gros élément visible dans la fenêtre : généralement l'image de couverture ou le bloc de titre. Cible : sous 2,5 secondes. C'est la métrique la plus liée à l'infrastructure, donc la plus structurelle à corriger.
- Commencer par le TTFB. Le temps de réponse serveur est le plancher du LCP : aucune optimisation d'image ne rattrapera un serveur qui répond en 1,5 seconde. Cache serveur, CDN, requêtes base de données. Viser sous 600 ms.
- Ne pas mettre l'image LCP en lazy loading. Erreur extrêmement répandue : le
loading="lazy"appliqué à toutes les images retarde précisément celle qui définit le LCP. Le lazy loading concerne ce qui est hors de l'écran, jamais l'image de couverture. - Précharger l'image de couverture. Un
fetchpriority="high"signale au navigateur de la traiter en priorité au lieu de la découvrir tardivement dans le HTML. - Servir en WebP ou AVIF, dimensionné pour l'affichage réel. Une image de 3000 px redimensionnée en CSS pour occuper 800 px fait payer la différence à chaque visiteur.
INP : la réactivité.
L'Interaction to Next Paint mesure le délai entre une interaction (clic, tap, touche) et la mise à jour visuelle qui en résulte. Cible : sous 200 ms. C'est la métrique qui a remplacé FID en 2024, et celle qui fait le plus de dégâts.
// à retenir
FID ne mesurait que le délai avant la première interaction, et uniquement le temps d'attente avant traitement : presque tout le monde le passait. INP mesure toutes les interactions de la session, jusqu'au rendu visuel du résultat. Les sites qui échouent à INP sont presque toujours ceux qui exécutent trop de JavaScript sur le fil principal.
- Réduire le JavaScript exécuté. La cause racine dans la grande majorité des cas. Chaque tâche longue sur le fil principal bloque la réponse à l'interaction suivante. Supprimer avant d'optimiser.
- Découper les tâches longues. Toute tâche au-delà de 50 ms bloque le fil principal. Fractionner le travail permet au navigateur de répondre entre deux morceaux.
- Auditer les scripts tiers. Tags marketing, chats, tests A/B, régies. Ils s'accumulent sans que personne n'assume de les retirer, et ils monopolisent le fil principal aux pires moments.
- Se méfier de l'hydration. Sur les sites à framework, l'hydration rend la page visible mais pas interactive pendant plusieurs secondes. L'utilisateur clique dans le vide. Voir JavaScript SEO.
CLS : la stabilité visuelle.
Le Cumulative Layout Shift quantifie les décalages de mise en page pendant le chargement : le bouton qui saute au moment du clic, le paragraphe qui descend quand une bannière s'insère. Cible : sous 0,1. C'est la métrique la plus facile à corriger des trois, et souvent la plus rentable en confort.
- Dimensions explicites sur les images. Les attributs
widthetheightpermettent au navigateur de réserver la place avant même le téléchargement. Le correctif le plus simple et le plus efficace du lot. - Réserver l'espace des insertions tardives. Bannières, publicités, bandeaux de consentement : leur emplacement doit exister dans la mise en page dès le départ, même vide.
- Gérer le chargement des polices. Une police de substitution aux métriques trop différentes provoque un décalage au moment de la bascule. Utiliser
font-display: swapavec une police de repli aux dimensions proches. - Animer en transform uniquement. Animer
width,heightoutopdéclenche des recalculs de mise en page comptabilisés dans le CLS.transformetopacityne coûtent rien.
Performance et indexation : le vrai lien.
C'est le point que la plupart des guides sur le sujet manquent, et le seul endroit où la performance touche réellement l'indexation. Le lien existe, mais il ne passe pas par les Core Web Vitals.
// à retenir
Aucune des trois métriques n'entre dans la décision d'indexer une page. En revanche, la vitesse de réponse du serveur détermine la crawl capacity limit : Google augmente son débit de crawl quand le serveur suit, et le réduit dès que les temps de réponse montent ou que des erreurs 5xx apparaissent. Le TTFB conditionne le LCP sans en faire partie, et c'est lui, pas le LCP, qui gouverne le crawl.
Conséquences pratiques
- Sur un gros site, le TTFB est un sujet d'indexation. Diviser le temps de réponse par deux peut augmenter significativement le nombre de pages crawlées par jour. Voir crawl budget.
- Les erreurs 5xx font chuter le crawl. Google interprète l'instabilité comme un signal de surcharge et se retire. Voir erreur serveur 5xx.
- Un LCP dégradé n'empêche pas l'indexation. Si une page n'est pas indexée, chercher la cause dans les directives et le maillage, jamais dans la performance. Voir page non indexée.
- Ordre de traitement : indexabilité, puis contenu, puis performance. La séquence complète est dans audit SEO technique.
Questions fréquentes.
Les Core Web Vitals sont-ils un facteur de classement ?
Oui, mais un facteur de départage, pas de hiérarchisation. Google les présente comme un critère qui tranche entre deux pages de pertinence équivalente. En pratique : un contenu excellent avec des Core Web Vitals moyens battra un contenu faible aux scores parfaits, systématiquement. Optimiser la performance ne sauvera jamais une page qui ne répond pas à l'intention de recherche. C'est un signal de finition, à traiter une fois que le contenu et l'indexabilité tiennent.
Quels sont les seuils à respecter ?
LCP sous 2,5 secondes (affichage du plus gros élément visible), INP sous 200 millisecondes (réactivité aux interactions), CLS sous 0,1 (stabilité visuelle). Ces trois seuils sont inchangés en 2026. Point crucial souvent ignoré : ils s'évaluent au 75e percentile des visites réelles, ce qui signifie que 75 % de vos visiteurs doivent passer sous le seuil. Une moyenne flatteuse peut masquer un quart d'utilisateurs en échec.
Pourquoi mon score PageSpeed est bon mais Search Console dit le contraire ?
Parce que les deux mesurent des choses différentes. PageSpeed Insights affiche un test en laboratoire : une simulation, sur une machine standardisée, une seule fois. Search Console remonte les données de terrain (CrUX), collectées auprès des vrais utilisateurs de Chrome sur 28 jours glissants, avec leurs vrais appareils et leurs vraies connexions. Seules les données de terrain comptent pour Google. Le score de laboratoire sert au diagnostic, jamais de verdict.
INP a remplacé FID, qu'est-ce qui change ?
FID (First Input Delay) ne mesurait que le délai avant la première interaction, et seulement le temps d'attente avant traitement. Presque tous les sites le passaient, ce qui en faisait une métrique peu discriminante. INP mesure la latence de toutes les interactions de la session, du clic jusqu'à l'affichage du résultat visuel. Bien plus exigeant, et bien plus représentatif du ressenti. Beaucoup de sites qui passaient FID échouent à INP, généralement à cause d'un excès de JavaScript.
Les Core Web Vitals influencent-ils l'indexation ?
Pas directement, et c'est une confusion fréquente. Aucune des trois métriques n'entre dans la décision d'indexer une page. En revanche, la vitesse de réponse serveur (le TTFB, qui conditionne le LCP sans en faire partie) influence bien la capacité de crawl que Google alloue au site : un serveur lent ou instable fait baisser le nombre de pages crawlées par jour. Le lien existe donc, mais il passe par le serveur, pas par les Core Web Vitals eux-mêmes. Voir crawl budget.
Faut-il viser 100/100 sur PageSpeed Insights ?
Non. Ce score est un agrégat de laboratoire pondéré par Lighthouse, sans rapport direct avec ce que Google utilise pour classer. Passer de 85 à 100 demande souvent des semaines pour un gain de classement nul, pendant que les vrais utilisateurs ne perçoivent aucune différence. La cible utile est le vert sur les trois métriques en données de terrain, pas un chiffre rond en laboratoire. Au-delà du vert, le rendement est proche de zéro.
Combien de temps avant de voir l'effet d'une optimisation ?
Compter 28 jours minimum. Les données CrUX sont calculées sur une fenêtre glissante de 28 jours : même si le correctif est instantané pour vos visiteurs, Search Console mettra près d'un mois à refléter pleinement l'amélioration. Ne pas conclure à l'échec au bout d'une semaine. Pour vérifier immédiatement qu'un correctif fonctionne, utiliser une mesure de terrain locale plutôt que d'attendre le rapport agrégé.
Un site lent peut-il être bien classé ?
Oui, et on en croise tous les jours. Des sites en rouge sur les trois métriques dominent des requêtes concurrentielles parce que leur contenu est le meilleur disponible. C'est la preuve pratique que la performance est un signal de départage et non un prérequis. La vraie raison d'optimiser est ailleurs : le taux de rebond, la conversion, et le confort mobile pèsent sur le chiffre d'affaires bien plus que le demi-rang gagné sur la SERP.
// passer à l'action
La performance vient après l'indexabilité.
Optimiser le LCP d'une page que Google n'indexe pas ne sert à rien. Vérifier d'abord qu'aucun blocage technique ne la retient hors de l'index.