Performance

Core Web Vitals 2026 : les 3 signaux à surveiller pour rester visible

LCP, INP, CLS : pourquoi ces 3 métriques pèsent encore en 2026 sur Google et les réponses IA, et comment les surveiller sans devenir dev.

Tableau de bord stylisé avec trois jauges représentant les Core Web Vitals LCP, INP et CLS

Vous avez peut-être ouvert votre rapport Search Console et vu trois petits voyants rouges. Ou un prestataire qui vous a parlé de « LCP » et d'« INP » sans vraiment expliquer. C'est l'heure de mettre tout ça au clair : voilà les 3 mesures que Google regarde en 2026, pourquoi elles comptent aussi pour les réponses générées par l'IA, et comment savoir où vous en êtes sans installer un seul outil de développeur.

Pourquoi Google n'a pas abandonné les Core Web Vitals en 2026

Les Core Web Vitals (CWV) sont les trois métriques officielles que Google utilise depuis 2021 pour évaluer la qualité d'expérience d'une page web. Beaucoup espéraient les voir disparaître, ou se faire diluer par les signaux IA. Elles n'ont pas bougé. Google les confirme toujours comme un facteur de classement dans sa documentation Search en 2026, et le calcul reste celui qu'on connaît depuis l'origine : il faut passer les trois seuils, sur 75 pour cent de vos visiteurs réels, pour décrocher le statut « bon ».

Concrètement, sur deux pages au contenu équivalent, celle qui a des CWV « bons » l'emporte sur celle qui est dans le rouge. Et selon les rapports publics 2025-2026 (HTTP Archive, CrUX), moins de la moitié des sites mobiles passe les trois seuils. Autrement dit, plus de la moitié du web est encore suboptimal sur ce critère, ce qui veut dire que c'est un levier différenciant pour une PME qui prend le sujet au sérieux.

LCP, INP, CLS : ce que mesure chaque signal et comment le corriger

Les trois métriques mesurent trois choses très différentes de la même page : sa vitesse de chargement, sa réactivité aux clics, et sa stabilité visuelle. Aucune n'est plus importante que les deux autres dans le calcul Google : il faut passer les trois pour avoir le statut « bon ». Et chacune se corrige avec ses propres leviers : l'INP ne se règle pas comme le LCP.

LCP, Largest Contentful Paint

C'est le temps qu'il faut pour que le plus gros élément visible de votre page apparaisse à l'écran, généralement une image hero ou un gros titre. Seuil officiel : moins de 2,5 secondes pour être « bon ». Entre 2,5 et 4 secondes, c'est orange (« à améliorer »). Au-delà de 4 secondes, c'est rouge. C'est la mesure la plus liée à la perception « ça rame » côté visiteur.

Cadran chronographe 3D avec zones verte, ambre et rouge, aiguille pointant dans la zone verte avant 2,5 secondes, illustration metaphorique du seuil LCP

Trois actions concrètes, dans l'ordre :

  1. Convertir l'image hero en WebP ou AVIF et la dimensionner correctement (pas une image 4000 px de large affichée à 1200 px). Sur 8 sites PME sur 10, c'est ce seul geste qui débloque le LCP.
  2. Marquer l'image hero comme prioritaire avec fetchpriority="high" (ou priority sur next/image en Next.js), pour qu'elle soit téléchargée avant les ressources secondaires.
  3. Précharger les ressources critiques au-dessus de la ligne de flottaison : polices web (preload), CDN images (preconnect). C'est mécanique et ça gagne 200 à 500 ms.

INP, Interaction to Next Paint

C'est le temps que met votre page à réagir à un clic, une touche tactile, une saisie clavier. INP a officiellement remplacé FID (First Input Delay) le 12 mars 2024 dans les Core Web Vitals, parce que FID ne mesurait que la première interaction et passait à côté de tout le reste. INP regarde toutes les interactions de la session et retient la plus lente. Seuil officiel : moins de 200 millisecondes pour être « bon ». Au-delà de 500 ms, c'est rouge. C'est aujourd'hui la métrique qui échoue le plus souvent.

Doigt appuyant sur une surface tactile noire avec onde de reponse en trois cercles concentriques bleu et violet, illustration metaphorique de la reactivite INP

Trois actions concrètes :

  1. Auditer les scripts tiers chargés (analytics, chatbot, A/B test, gestionnaire de consentement). Demandez la liste, et virez tout ce qui n'est pas critique. Sur un WordPress avec 7-8 plugins, on récupère facilement 300 à 400 ms.
  2. Différer ce qui n'est pas critique avec defer, async, ou un chargement après la première interaction utilisateur. Le gestionnaire de consentement et le chat tiers sont les premiers candidats.
  3. Casser les longues tâches JavaScript (plus de 50 ms) en plus petits morceaux, avec requestIdleCallback, scheduler.yield(), ou simplement un découpage logique. C'est plus du ressort du dev, mais c'est ce qui débloque les cas durs.

CLS, Cumulative Layout Shift

C'est le score de stabilité visuelle. Il mesure si votre contenu « saute » pendant le chargement : une image qui pousse le texte vers le bas, une bannière de cookies qui apparaît tardivement et décale tout, une publicité qui s'insère après coup. Seuil officiel : moins de 0,1 pour être « bon ». Au-delà de 0,25, c'est rouge. Sur un site bien fait, c'est généralement la plus facile des trois à passer.

Trois cartes empilees parfaitement alignees dans le vide, finitions indigo glaucous et violet tekhelet, illustration metaphorique de la stabilite visuelle CLS

Trois actions concrètes :

  1. Déclarer width et height sur toutes les images et vidéos, même celles qui sont responsives. Le navigateur réserve l'espace dès le départ et le contenu en dessous ne saute plus.
  2. Réserver l'espace des éléments dynamiques : bannière de cookies, formulaires chargés en JS, blocs publicitaires. Un placeholder à la bonne hauteur fait le travail.
  3. Stabiliser les polices web avec font-display: optional ou size-adjust dans @font-face, pour éviter que le texte ne re-flow quand la police custom remplace la police système.

Comment je mesure (sans devenir dev)

Trois outils suffisent, dans cet ordre.

PageSpeed Insights (pagespeed.web.dev). Vous collez l'URL, vous lisez les 3 jauges en haut. C'est gratuit, c'est Google, c'est la source officielle, et ça fait le travail pour 90 pour cent des cas. Deux sections à distinguer : les « Données de terrain » (les vrais utilisateurs sur 28 jours, ce qui compte vraiment pour le classement) et les « Données de laboratoire » (un test ponctuel sur un serveur Google, utile en complément).

Le rapport CrUX et son dashboard public (developer.chrome.com/docs/crux). CrUX, c'est le Chrome User Experience Report, le jeu de données anonymisé que Chrome remonte depuis les vrais utilisateurs. C'est la source brute des chiffres que vous voyez dans PageSpeed et dans Search Console. Pour aller plus loin, le dashboard public Looker Studio (relié à BigQuery) permet de voir l'évolution mensuelle de vos métriques sur 12 mois, par appareil et par type de connexion. Pratique pour suivre l'effet d'une optimisation dans le temps.

Chrome DevTools, panneau Performance. Là, c'est pour mettre les mains dedans. F12, onglet Performance, Record, vous chargez la page, Stop. Vous voyez en détail les scripts qui bloquent, les images en retard, les long tasks qui plombent l'INP. C'est le seul outil qui vous montre le pourquoi, pas juste le quoi. Si votre PageSpeed est rouge sans que vous compreniez la cause, c'est ici qu'un dev compétent va creuser en dix minutes.

Combo type : PageSpeed pour le diagnostic, CrUX pour suivre dans la durée, DevTools pour creuser quand un chiffre résiste.

AI Overviews et ChatGPT : la performance compte-t-elle pour l'IA ?

C'est la question que beaucoup se posent depuis que Google AI Overviews, ChatGPT Search et Perplexity siphonnent une partie des clics. Réponse honnête : la performance n'est pas un levier de croissance pour la visibilité IA, mais elle reste un garde-fou. Les études publiques disponibles à ce jour (notamment une analyse de plus de 100 000 pages apparaissant dans les AI Overviews) montrent des corrélations très faibles entre les CWV et les citations IA. Aucune plateforme (Google, OpenAI, Microsoft, Perplexity) n'a confirmé les CWV comme un facteur direct de citation.

Ce qui pèse vraiment pour être cité par une IA, c'est la clarté du contenu, la structuration sémantique (titres explicites, schema.org), la fraîcheur de la page, et l'alignement avec l'intention de la requête. Pas la vitesse pure de chargement.

Mais attention au piège inverse : si votre site est tellement lent que les crawlers IA n'arrivent pas à le parser dans la fenêtre de temps qu'ils s'allouent, ou si le rendu est si chaotique qu'un extracteur de passage rate l'information clé, vous êtes pénalisé indirectement. La performance ne vous fait pas gagner de citations IA, elle évite seulement d'en perdre. Pour aller plus loin sur la visibilité dans les réponses IA, j'en parle séparément sur la page apparaître sur Google et l'IA.

Si vous voulez creuser la méthode pour un site refondu de zéro avec ces contraintes intégrées dès la conception, j'en parle sur la page site rapide et durable. Et si vous préférez qu'on regarde ensemble ce que ça donne sur votre site précisément, on peut en parler ensemble.

À lire ensuite

FAQ

Est-ce que Google déclasse vraiment les sites lents ?

Oui, mais sans coup d'éclat brutal. Les CWV sont un facteur parmi d'autres, qui départage deux pages à contenu équivalent. Sur une requête concurrentielle, une page « bons » CWV passe devant une page « médiocres » CWV à pertinence égale. L'effet est rarement spectaculaire en isolé, il est cumulatif : sur des dizaines de requêtes, la différence devient visible dans le trafic organique mensuel.

Puis-je voir mes scores moi-même sans appeler un dev ?

Oui, en 5 minutes. Ouvrez pagespeed.web.dev, tapez l'URL de votre page d'accueil, lisez les 3 jauges colorées en haut. Pour la vue d'ensemble du site, ouvrez Search Console et cherchez le rapport « Signaux Web essentiels ». Vous y voyez la répartition de toutes vos URL en bon / à améliorer / médiocre, séparée mobile et desktop. Aucun outil à installer, aucun code à toucher.

Combien ça coûte d'améliorer mes Core Web Vitals ?

Pour un site relativement propre, comptez 1 à 3 jours de dev pour passer les 3 seuils, soit autour de 800 à 2 500 euros chez un freelance sérieux. Pour un site avec dette technique (vieux thème WordPress lourd, plugins en pagaille, code custom non optimisé), c'est plutôt 5 à 10 jours, et la question d'une refonte ciblée se pose. Le bon ratio à viser : viser un retour sous 3 mois en gain de trafic ou de conversion, sinon il y a probablement un problème en amont (cible, contenu, offre).

INP, c'est nouveau, FID est mort, c'est quoi cette histoire ?

FID (First Input Delay) a été remplacé par INP (Interaction to Next Paint) dans les Core Web Vitals le 12 mars 2024. Pourquoi ? Parce que FID ne mesurait que le délai de la première interaction de la page, et beaucoup de pages réussissaient FID alors qu'elles étaient lentes à réagir aux clics suivants. INP regarde toutes les interactions et garde la plus lente, ce qui reflète bien mieux l'expérience réelle. Si votre prestataire vous parle encore de FID en 2026, posez-lui poliment la question : il a peut-être un train de retard.

Et sur mobile, c'est pareil que sur desktop ?

Les seuils sont identiques (LCP < 2,5 s, INP < 200 ms, CLS < 0,1), mais les résultats sont mesurés séparément mobile et desktop. Et en pratique, le mobile est presque toujours plus dur à passer : connexion moins stable, processeur plus lent, écran plus petit qui rend les layout shifts plus visibles. Sur les rapports publics, l'écart est d'environ 15 à 20 points de pourcentage de réussite entre mobile et desktop. Google regarde d'abord vos chiffres mobiles pour les requêtes mobiles, donc c'est là qu'il faut prioriser.

Sources