Actualités Core Web Vitals : ce qui a changé et ce qu'il faut corriger en premier
Par Toy Wen Da, Cofondateur · Mis à jour le · 12 min de lecture
Traduit de l'original en anglais. Lire en anglais
Si vous cherchez des actualités sur les Core Web Vitals, c'est généralement à cause d'une alerte dans Search Console ou d'un changement de métrique dont vous avez entendu parler. La réponse courte : Interaction to Next Paint (INP) a remplacé First Input Delay (FID) comme Core Web Vital officiel le 12 mars 2024. Ouvrez votre rapport Core Web Vitals dans Search Console pour voir quelles URL sont signalées.
Avant de toucher au moindre code, passez la page dans le Website Speed Test gratuit. Il récupère les scores Lighthouse et indique quelle métrique Core Web Vitals pénalise la page. Vous savez ainsi s'il s'agit d'un problème de chargement, d'interaction ou de mise en page avant d'ouvrir la moindre ligne de code.
Ce qui a vraiment changé récemment dans les Core Web Vitals
Les actualités sur les Core Web Vitals arrivent en général sous deux formes : un changement de métrique, ou une fuite qui confirme à quel point Google s'appuie en coulisses sur le comportement réel des utilisateurs. Les deux ont eu lieu en 2024, et les deux influencent encore la manière dont les équipes doivent prioriser leurs corrections aujourd'hui.
Le passage du FID à l'INP
Jusqu'au 12 mars 2024, Google mesurait la réactivité des pages avec First Input Delay, ou FID. Le FID ne regardait que la toute première interaction d'un visiteur sur une page : un clic, un tapotement, une frappe. Une page pouvait réussir le test FID sans difficulté et pourtant paraître lente à chaque interaction suivante.
Interaction to Next Paint a comblé cette lacune. L'INP observe chaque clic, tapotement et frappe de touche pendant toute la visite, puis rapporte la plus lente d'entre elles, hors cas isolé. C'est important, car les données d'usage de Chrome montrent qu'environ 90 % du temps qu'un visiteur passe sur une page se déroule après la fin du chargement, et non pendant celui-ci. Le FID ne mesurait qu'une infime partie de l'expérience. L'INP mesure celle que les utilisateurs ressentent vraiment.
Un bon score INP est de 200 millisecondes ou moins. Entre 200 et 500 millisecondes, il est classé « Needs improvement ». Au-delà de 500 millisecondes, Search Console l'indique comme « Poor ».
La fuite de l'API Content Warehouse
En mars 2024, un ensemble de documentation interne de l'API de Google est apparu publiquement, et les commentateurs du secteur l'ont décortiqué pendant une bonne partie de 2025. Elle n'a pas réécrit les règles des Core Web Vitals. Elle a confirmé ce que beaucoup de professionnels du SEO soupçonnaient déjà : les métriques publiques sont un indicateur approché d'un système de classement beaucoup plus vaste, fondé sur les clics.
La documentation divulguée mentionnerait des modules liés aux données d'usage de Chrome et un système appelé NavBoost, qui reclasse les résultats à partir d'environ 13 mois de comportement de clic glissants. Le lien avec les Core Web Vitals relève de la simple cause à effet. Une page lente ou instable génère davantage de « mauvais clics » : des visites où quelqu'un clique sur un résultat, s'agace et revient aussitôt aux résultats de recherche. Améliorer vos Core Web Vitals ne sert donc pas qu'à satisfaire un tableau de bord. Cela supprime une raison pour les visiteurs de retourner sur Google.
La chronologie sur le long terme
Les Core Web Vitals ne sont pas apparus de nulle part en 2020. Google prépare cette évolution depuis plus de dix ans :
| Année | Changement | Pourquoi c'est important aujourd'hui |
|---|---|---|
| 2011 | La mise à jour Panda cible les contenus de faible qualité | A établi que la qualité perçue par l'utilisateur influence le classement, et pas seulement les mots-clés |
| 2014 | HTTPS devient un signal de classement | Première fois qu'un facteur technique, sans lien avec le contenu, était confirmé comme signal |
| 2018 | Mise à jour Mobile Page Speed | La vitesse des pages sur mobile obtient son propre signal explicite |
| 2020 | Annonce officielle des Core Web Vitals (mise à jour Page Experience) | LCP, FID et CLS deviennent le trio mesurable |
| 2024 | L'INP remplace le FID (12 mars) | La réactivité est mesurée sur l'ensemble de la visite, et pas seulement sur le premier clic |
Vérifier vos Core Web Vitals dans Google Search Console, étape par étape
Search Console reste l'outil gratuit de référence pour voir comment les données de terrain de Google notent vos pages. Voici comment y accéder et les lire correctement.
Ouvrir le rapport
- Connectez-vous à Google Search Console et sélectionnez votre propriété.
- Dans la barre latérale gauche, sous Expérience (Experience), cliquez sur Core Web Vitals.
- Vous voyez deux graphiques récapitulatifs : Mobile et Ordinateur (Desktop). Cliquez sur Ouvrir le rapport (Open report) sous l'un ou l'autre.
- Chaque rapport présente des groupes d'URL classés par statut : Poor, Need improvement et Good.
Lire les groupes d'URL
Par défaut, Search Console ne rapporte pas les URL une à une : il regroupe les pages similaires, généralement par modèle. C'est voulu. Si toutes vos pages produit partagent la même mise en page, elles partageront probablement aussi le même problème de Core Web Vitals.
Cliquez sur un groupe « Poor » et vous verrez :
- La métrique précise qui échoue (LCP, INP ou CLS)
- Un échantillon d'URL concernées
- Le nombre d'URL dans ce groupe
C'est ici qu'une page dont l'évaluation des Core Web Vitals indique « Failed » se diagnostique généralement : par modèle, et non en tâtonnant sur une seule page.
Après une correction
Une fois votre correction déployée, retournez dans le rapport et cliquez sur Valider la correction (Validate fix) pour le groupe d'URL concerné. Google réexplore un échantillon de ces URL dans les jours qui suivent et met à jour le statut dès qu'il dispose de suffisamment de données d'utilisateurs réels. Cela peut prendre de deux à quatre semaines, car les données de terrain des Core Web Vitals nécessitent un véritable échantillon de visites, et non une simple exploration ponctuelle.
Les trois métriques et leurs seuils
| Métrique | Ce qu'elle mesure | Bon | À améliorer (Needs improvement) | Mauvais (Poor) |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Délai avant l'affichage de l'élément visible le plus grand | 2,5 secondes ou moins | 2,5–4 secondes | Plus de 4 secondes |
| INP (Interaction to Next Paint) | Délai entre une action de l'utilisateur et la réponse visuelle suivante | 200 ms ou moins | 200–500 ms | Plus de 500 ms |
| CLS (Cumulative Layout Shift) | Ampleur des déplacements inattendus du contenu visible | 0,1 ou moins | 0,1–0,25 | Plus de 0,25 |
Google évalue les trois métriques au 75e centile des chargements de page, selon la documentation Core Web Vitals de web.dev. Cela signifie qu'au moins trois visites réelles sur quatre doivent atteindre le niveau « Good » pour que la page soit validée dans son ensemble.
Quand Google Search Console suffit, et quand il ne suffit pas
Voici la partie honnête que la plupart des guides passent sous silence. Le rapport Core Web Vitals de Search Console est gratuit, il repose sur des données de visiteurs réels et, pour beaucoup de sites, il est tout à fait suffisant. Mais il a de vraies limites.
Là où Search Console fait le travail
- Vous gérez un seul site avec une poignée de modèles de page. La vue par groupes d'URL vous indique exactement quel modèle pose problème.
- Vous vérifiez une baisse ponctuelle. Si une page passe soudainement en « Poor » après une mise à jour de contenu, les données de terrain de Search Console, associées au Website Speed Test gratuit, permettent généralement d'identifier la cause.
- Il vous suffit de données de terrain, pas d'une analyse de cause racine. Search Console vous dit ce que vivent les utilisateurs réels. Il ne vous dit pas quel script ou quelle image en est responsable.
Là où Search Console ne suffit plus
- Une page a trop peu de trafic pour générer des données de terrain. Google exige un volume minimal de visites réelles avant de rapporter un score. Les pages à faible trafic affichent « no data » même si elles sont réellement lentes.
- Vous devez remonter à la cause réelle. Search Console vous indique la métrique et le modèle de page. Il ne vous montrera pas quel script tiers bloque le thread principal. Pour cela, il vous faut Chrome DevTools ou un outil de laboratoire comme Lighthouse.
- Le problème revient à chaque mise en production. Si chaque déploiement réintroduit un décalage de mise en page, il vous faut une surveillance dans votre chaîne de build, et non une consultation mensuelle d'un rapport GSC.
- Vous êtes sur une plateforme où les causes viennent des extensions. Sur Shopify, par exemple, une application tierce est souvent la vraie source d'un mauvais score INP, et la corriger suppose de savoir quelles applications Shopify agissent réellement sur les Core Web Vitals, plutôt que d'ajouter encore du poids de suivi.
En bref : Search Console vous dit que quelque chose ne va pas, et à peu près où. Il vous dit rarement pourquoi exactement, jusqu'au script ou à la feuille de style.
Causes courantes et corrections par métrique
| Métrique | Cause typique | Première vérification | Qui corrige généralement |
|---|---|---|---|
| LCP | L'image principale ou le bloc de texte principal se charge tardivement | L'élément LCP est-il détectable dans le HTML brut ? | Développeur front-end ou hébergeur |
| LCP | Réponse lente du serveur (TTFB élevé) | Temps de réponse du serveur et mise en cache | Équipe d'hébergement ou back-end |
| INP | Une longue tâche JavaScript bloque le thread principal | Quelle action de l'utilisateur semble retardée ? | Développeur front-end |
| INP | Scripts tiers lourds (publicités, widgets de chat, outils de suivi) | Auditer quels scripts s'exécutent lors d'une interaction | Marketing et développement, conjointement |
| CLS | Images ou publicités sans dimensions réservées | La mise en page bouge-t-elle après le chargement ? | Développeur front-end ou équipe de contenu |
| CLS | Polices web provoquant un nouveau calcul de la mise en page du texte | Une police de secours est-elle correctement définie ? | Développeur front-end |
Erreurs courantes des équipes face à l'actualité des Core Web Vitals
La plupart des erreurs viennent du fait de traiter les Core Web Vitals comme un score unique à maximiser, au lieu de trois problèmes distincts et indépendants.
- Viser un 100 parfait sur PageSpeed Insights. Google ne regarde qu'une chose : franchissez-vous le seuil « Good » ? Au-delà, vous dépensez du budget pour des gains invisibles.
- Ne tester que la page d'accueil. Votre page d'accueil peut être très bien alors que toutes vos pages produit échouent. Utilisez la vue par groupes d'URL, pas un contrôle ponctuel.
- Ignorer les données mobiles. Les Core Web Vitals sur ordinateur sont généralement meilleurs que sur mobile. C'est sur mobile que se produisent la plupart des visites, et la plupart des abandons.
- Corriger tous les avertissements jaunes d'un coup. Priorisez d'abord les pages liées au chiffre d'affaires ou aux prospects. Une archive de blog lente peut attendre.
- Sauter les vrais tests d'interaction pour l'INP. Une page peut sembler rapide au chargement et pourtant échouer à l'INP dès que quelqu'un touche un menu déroulant ou un filtre.
- Clore le ticket avant que les données ne suivent. Les données de terrain ont besoin de visites réelles après la mise en production d'une correction, généralement quelques semaines, avant que le statut ne change.
Les Core Web Vitals côtoient aussi un autre signal de qualité que Google met en avant depuis des années : l'accessibilité. Une page avec un mauvais contraste des couleurs ou sans texte alternatif échoue souvent aux mêmes critères que ceux des Web Content Accessibility Guidelines (WCAG) du W3C, la norme officielle derrière la plupart des audits d'accessibilité, et partage souvent les mêmes causes profondes qu'une page présentant des problèmes de décalage de mise en page. C'est l'une des raisons pour lesquelles corriger les problèmes d'accessibilité tend à améliorer le SEO en même temps. Si vous ne savez pas où se situe votre exposition juridique, il vaut la peine de consulter ce que la loi sur l'accessibilité exige réellement que vous corrigiez en premier en parallèle de votre nettoyage des Core Web Vitals.
L'actualité des Core Web Vitals pour les éditeurs et les sites d'actualité
Si votre site est un éditeur de presse, l'actualité des Core Web Vitals comporte une difficulté supplémentaire : les problèmes de vitesse et de stabilité s'ajoutent aux problèmes d'indexation. Un modèle de page lent ne risque pas seulement un mauvais score CLS « Poor » : il peut aussi ralentir l'exploration des nouveaux articles dès le départ.
Si vous visez à la fois une indexation rapide et un bon score Core Web Vitals, quelques corrections connexes vont souvent de pair :
- Corrigez les erreurs de sitemap Google News pour que les nouveaux articles apparaissent rapidement.
- Sur WordPress, vérifiez que votre configuration de Yoast News SEO n'ajoute pas de scripts bloquant le rendu aux modèles d'articles.
- Consultez le guide plus large pour faire indexer et bien classer rapidement vos articles d'actualité, car un modèle d'article lourd échoue souvent en même temps aux contrôles d'INP et de vitesse d'exploration.
Et si votre entreprise apparaît aussi dans la recherche locale, il vaut la peine de suivre les dernières évolutions de Google Business Profile en parallèle de votre travail sur les Core Web Vitals : les deux alimentent la même image globale de l'expérience de page que Google se construit de votre marque.
Pourquoi cela touche au comportement de clic
Rappelez-vous le mécanisme NavBoost évoqué plus haut : Google considère comme un signal négatif les clics qui reviennent aussitôt à la page de résultats. Une page lente ou instable en produit davantage. Améliorer vos Core Web Vitals protège, en pratique, votre taux de clics. Si vous voulez comprendre le calcul qui détermine ce qu'est un bon résultat, la formule du taux de clics et ses valeurs de référence valent un coup d'œil rapide : une page rapide et stable est l'un des moyens les moins coûteux de protéger ce chiffre.
Prioriser les corrections : un cadre simple
Plutôt que de corriger chaque URL signalée dans l'ordre où Search Console les liste, suivez cette séquence :
- Choisissez d'abord les modèles de page liés au chiffre d'affaires ou aux prospects : pages produit, pages de service, pages de destination.
- Vérifiez les données de terrain avant les données de laboratoire. Le rapport de Search Console et les données de terrain CrUX reflètent des visites réelles ; les outils de laboratoire comme Lighthouse ne simulent qu'une seule exécution.
- Identifiez la métrique précise qui échoue. LCP, INP et CLS appellent chacun une correction différente, et un ticket générique « rendre ça plus rapide » fait perdre du temps aux développeurs.
- Testez une URL représentative du groupe avant de modifier tout le modèle.
- Validez dans un outil de laboratoire avant la mise en production, puis validez la correction dans Search Console ensuite.
- Surveillez pendant quelques semaines. Les données de terrain mettent du temps à refléter une correction déployée.
FAQ
Quelle est la dernière actualité sur les Core Web Vitals en 2026 ?
Le changement récent le plus important reste le remplacement, le 12 mars 2024, de First Input Delay par Interaction to Next Paint. Depuis, la plupart des « actualités » ont consisté en analyses de la documentation Google divulguée, qui confirme comment le comportement de clic et les Core Web Vitals interagissent, plutôt qu'en une nouvelle métrique officielle.
Google a-t-il retiré les Core Web Vitals du classement ?
Non. Google a répété à plusieurs reprises que les Core Web Vitals sont un signal parmi beaucoup d'autres, et que la pertinence et la qualité du contenu pèsent toujours davantage. De mauvais Core Web Vitals n'empêcheront pas une page de se classer, mais ils peuvent la faire passer derrière un concurrent plus rapide lorsque tout le reste est à égalité.
Combien de temps faut-il pour qu'une correction apparaisse dans Search Console ?
Les données de terrain nécessitent un nouvel échantillon de visites réelles après la mise en production d'une correction, ce qui prend généralement de deux semaines à un mois avant que le statut ne soit mis à jour dans le rapport Core Web Vitals.
PageSpeed Insights est-il la même chose que le rapport Core Web Vitals de Search Console ?
Non. PageSpeed Insights teste une URL à la fois et combine données de laboratoire et données de terrain. Le rapport de Search Console regroupe de nombreuses URL par modèle en utilisant uniquement des données de terrain issues de visites réelles, ce qui est préférable pour prioriser les corrections sur l'ensemble d'un site.
L'INP remplace-t-il entièrement les Core Web Vitals, ou seulement une métrique ?
L'INP n'a remplacé que le FID. LCP et CLS sont inchangés. Les trois Core Web Vitals actuels sont LCP, INP et CLS.
Que faire dès maintenant
Ouvrez dès aujourd'hui votre rapport Core Web Vitals dans Search Console, triez par statut et choisissez le groupe d'URL « Poor » lié à votre modèle de page le plus fréquenté. Passez une page de ce groupe dans le Website Speed Test gratuit pour confirmer laquelle des trois métriques, LCP, INP ou CLS, échoue réellement avant de briefer un développeur. Si vous voulez voir ce que révélerait un audit technique et Core Web Vitals complet de votre site, parlez à l'équipe et obtenez un rapport exemple bâti autour de vos propres URL. Voilà l'actualité Core Web Vitals qui fait réellement bouger le classement : non pas une nouvelle métrique à courir après, mais un seul modèle de page corrigé.
Ressources / Références
Sources
À propos de l'auteur
SearchBlueprint a recherché, rédigé et noté cet article avec la chaîne de production de contenu que nos clients utilisent sur leurs propres sites. La note affichée dans la signature est celle que notre moteur de contenu a attribuée à cette page avant sa publication. Rien ici n'est relu à la main, et c'est tout l'intérêt : c'est le résultat du produit, publié là où chacun peut le vérifier.