Comment auditer les Core Web Vitals en 2026 (et ce qui a changé depuis que l’INP a remplacé le FID)

TL;DR : En 2026, les Core Web Vitals sont LCP, INP et CLS. FID a été abandonné et INP l’a remplacé le 12 mars 2024. Le poids dans l’algorithme est moindre que ce que beaucoup de SEO prétendent (la documentation Google rappelle que la pertinence prime sur l’expérience de page), mais l’impact UX est bien réel et l’audit reste rentable. Voici le guide d’audit que je remets aux clients : trois seuils, un outillage en deux temps (lab + terrain), une liste de correctifs classés par retour sur effort et un rythme trimestriel qui évite de mobiliser l’ingénierie sur les mauvais chantiers.

J’effectue chaque trimestre des audits de sites pour un portefeuille de sites mid-market chez mindnow et seojuice.io. À chaque fois, quelqu’un me demande s’il faut lancer un sprint de plus sur les Core Web Vitals. La réponse honnête est généralement non. Le protocole a changé en 2024, le poids de classement est faible et la plupart des contenus que vous lisez sur les CWV surestiment le gain de trafic. L’audit reste indispensable : des pages lentes font toujours fuir la conversion et INP est vraiment différent de FID. Cet article est le playbook d’audit. Ce n’est pas un tutoriel d’optimisation d’INP ; l’équipe web.dev le fait mieux que moi. C’est la couche d’interprétation qui vient au-dessus.

Ce qui a changé dans les Core Web Vitals entre 2024 et 2026

Le changement principal : First Input Delay (FID) a été déprécié et Interaction to Next Paint (INP) est devenu un Core Web Vital officiel le 12 mars 2024. L’équipe Chrome l’a annoncé directement :

« INP deviendra officiellement un Core Web Vital et remplacera FID le 12 mars de cette année. » Jeremy Wagner et Rick Viscomi, web.dev blog, mars 2024

Si votre modèle d’audit extrait encore FID, il récupère une métrique obsolète. Search Console a supprimé FID le même jour. PageSpeed Insights affiche désormais INP. La librairie JavaScript Web Vitals v4 a déprécié la mesure FID. Les outils de lab qui continuent à reporter FID servent encore au triage, mais pas aux décisions de classement.

Pourquoi ce remplacement ? FID ne mesurait que la première interaction sur une page, et seulement son délai d’entrée. Un site pouvait afficher un premier clic rapide et bloquer ensuite à chaque tap. La métrique était aussi « bidouillable » : ne rien différer au premier chargement, puis tout charger à la seconde interaction. INP comble ces deux lacunes en échantillonnant toutes les interactions et en comptant le délai complet jusqu’au prochain paint :

« INP améliore FID en observant toutes les interactions d’une page, depuis le délai d’entrée, le temps d’exécution des gestionnaires d’événements, jusqu’à ce que le navigateur peigne le frame suivant. » Jeremy Wagner et Barry Pollard, web.dev, Interaction to Next Paint

Conséquence pratique pour les audits : la plupart des sites verts sur FID passent en jaune ou rouge sur INP. Le changement est mécanique, ce n’est pas que votre site s’est dégradé. Prévenez les parties prenantes avant d’annoncer une note en baisse.

Deux évolutions plus discrètes sont également arrivées entre 2024 et 2026. CrUX, la source de données terrain derrière le rapport CWV de Search Console, a augmenté sa profondeur d’échantillonnage, de sorte que les seuils au 75e percentile se basent sur plus de sessions. LCP a gagné un diagnostic par sous-partie (TTFB, délai de chargement de la ressource, délai de rendu de l’élément) dans PageSpeed Insights, la meilleure avancée diagnostique depuis des années.

Les trois métriques actuelles et leurs seuils d’audit

Trois métriques, un seul tableau de seuils, appliqué au 75e percentile du trafic réel, distinctement pour mobile et desktop. La page canonique de web.dev est explicite sur le rôle :

« Les Core Web Vitals sont le sous-ensemble des Web Vitals qui s’applique à toutes les pages web, doit être mesuré par tous les propriétaires de site et est mis en avant dans tous les outils Google. » Philip Walton, web.dev, Web Vitals

Le couperet du 75e percentile est l’élément que beaucoup d’opérateurs ratent. Vous n’avez pas besoin que chaque session passe sous le seuil, seulement les trois quarts. La queue la plus lente (appareils, réseaux, pages) peut rester dans la bande jaune et l’URL obtient quand même la mention « Bon » dans CrUX.

Étape d’audit pour chaque métrique. LCP : extraire les sous-parties LCP dans PageSpeed Insights. Si TTFB dépasse 800 ms, le correctif est côté serveur ou CDN, pas front-end. Si le délai de rendu d’élément domine, précharger l’image ou injecter le CSS critique. INP : ouvrir la page sur un Android milieu de gamme, interagir avec tout élément cliquable, et surveiller dans l’onglet Performance les tâches longues > 50 ms. L’interaction la plus lente fait foi. CLS : faire défiler la page sur une connexion lente. Si des décalages surviennent lors du swap de police ou du chargement d’une image above-the-fold, réserver l’espace (CSS aspect-ratio) ou utiliser font-display : swap avec une police de secours métriquement compatible.

Un antipattern d’audit à abandonner : optimiser le score Performance Lighthouse comme proxy des CWV. Ce score est un composite pondéré de métriques lab incluant Speed Index et Total Blocking Time, qui ne sont pas des Core Web Vitals. Un site peut obtenir 95 en Performance et quand même échouer les CWV en données terrain, car Lighthouse simule un seul profil d’appareil alors que les CWV mesurent chaque visiteur réel.

Comment Google utilise réellement les CWV dans le classement

Lisez la documentation « page experience » de Google. La phrase clé est directe :

« Google Search cherche toujours à afficher le contenu le plus pertinent, même si l’expérience de page est médiocre. » Google Search Central, documentation Page Experience

Cette phrase se cache dans la FAQ sous « Quelle est l’importance de l’expérience de page pour le classement ? ». C’est pourtant le point le plus important, souvent ignoré. Pertinence et autorité dominent. L’expérience de page n’est qu’un signal parmi d’autres, utilisé quand la pertinence est à peu près équivalente.

Le même document nuance toutefois : Google confirme que « Les Core Web Vitals sont utilisés par nos systèmes de classement », puis précise aussitôt : « Il n’existe pas un unique signal. Nos systèmes principaux analysent une variété de signaux alignés sur l’expérience globale de la page. » (Deux citations de la même documentation Page Experience.)

Comment lire ces trois phrases ensemble : les CWV sont pris en compte, mais leur pondération est faible. Il n’existe pas de score d’expérience de page unique qui renverse votre position ; c’est un cluster de signaux qui aide Google à départager des pages similaires. Cadrez-le franchement auprès des parties prenantes : améliorer les CWV d’une page au contenu faible et sans backlinks ne la sauvera pas. En revanche, une page au contenu solide et aux backlinks forts, déjà en position 4 ou 5, peut raisonnablement espérer gagner une ou deux positions après quelques mois. Les maths passent d’abord par la pertinence.

Pour une vue plus large des signaux de classement, notre article sur l’audit de confiance des signaux de classement couvre le reste du système. Les CWV ne sont qu’un panneau du tableau de bord. Traitez-les comme tels.

Ce que regardent vraiment les moteurs de recherche IA

Protocole différent. Google AI Mode, ChatGPT browse, Perplexity et l’outil web de Claude sont des systèmes de récupération-puis-synthèse. Ils vont chercher votre page, la parsouvent pour le contenu pertinent, puis la citent ou la paraphrasent. La vitesse de page au sens CWV n’apparaît pas dans leurs critères ; la récupération est côté serveur et leur budget de requête est large comparé à un utilisateur réel.

Ce qui les intéresse : réactivité serveur (un TTFB de 30 s fera expirer le crawler), HTTPS, contenu rendu sans JavaScript (ou exécutable par le fetcher), données structurées exploitables et HTML sémantique clair. Cela recoupe les CWV sur le TTFB, mais le reste relève d’un autre audit. Optimiser INP pour ChatGPT browse est du temps perdu : l’agent n’interagit pas avec votre page.

Implication pratique pour l’audit 2026 : conservez un objectif unique de TTFB (< 800 ms) qui sert aux deux audits. Décorrélez INP et CLS des travaux pour la recherche IA ; ils vivent sur des listes de priorité distinctes. Si votre trafic bascule vers des sessions référées par l’IA, mieux vaut investir l’heure d’ingénierie dans la « renderability » du contenu et les données structurées que dans le gain de 50 ms sur une interaction.

Outils pour mesurer les Core Web Vitals en 2026

Le jeu d’outils s’est consolidé depuis 2022. Six outils couvrent la chaîne lab + terrain dont la plupart des opérateurs ont besoin.

Workflow en deux passes. Commencez par PageSpeed Insights sur une URL unique pour obtenir lab et terrain côte à côte. Le chiffre lab montre ce qui est techniquement atteignable sur un device propre ; le chiffre terrain indique l’expérience réelle de vos utilisateurs. S’ils divergent, le terrain prévaut pour le classement et l’écart devient le diagnostic. Lab vert + terrain rouge = votre base d’utilisateurs est sur un hardware ou un réseau plus lent que vos machines de dev.

Pour des rapports clients récurrents et le suivi des tendances, le SEOJuice Lighthouse Score Checker lance un vrai scan page-par-page et vous fournit une URL partageable plus les données historiques ; c’est notre outil interne pour suivre la progression sans relancer Lighthouse manuellement à chaque cycle. La question plus large de l’interprétation du score Lighthouse (seuil de passage, composition des catégories) est détaillée dans notre décryptage du score SEO Lighthouse.

Si vous voulez voir comment les métriques CWV corrèlent réellement avec le trafic sur une population de pages, notre calculateur CWV Impact affiche les corrélations agrégées de plus de 164 000 pages auditées. Le résultat confirme le discours de Google : les corrélations existent mais restent modérées, variables selon la métrique. CLS est la plus faible ; LCP et INP sont plus fortes mais en-deçà de ce que prétendent beaucoup de contenus marketing.

Correctifs courants classés par retour

Les heures d’ingénierie sont comptées. Classez les correctifs selon l’impact sur votre pire métrique, pas selon la facilité de déploiement. Voici la liste de priorité tirée de sept ans d’audits CWV.

Tier 1, temps de réponse serveur. Si TTFB dépasse 800 ms, tout correctif front-end part avec un handicap. Placez un CDN devant votre origine. Cachez la réponse HTML quand c’est possible. Sortez les requêtes base de données du chemin critique de rendu. Un gain de 400 ms sur le TTFB déplace souvent le LCP de 600 ms, car les chargements de ressources aval suivent en cadence.

Tier 1, stratégie image. L’élément LCP est généralement une image. Préchargez-la avec un hint de haute priorité. Servez des tailles responsives via srcset. Utilisez AVIF ou WebP avec fallback JPEG. Lazy-loadez toutes les autres images avec l’attribut natif loading="lazy". Ne lazy-loadez surtout pas l’image LCP : c’est la bourde la plus fréquente en audit CWV.

Tier 2, hygiène JavaScript. Différez les scripts non critiques. Segmentez vos bundles. Auditez les tags tiers : la plupart des sites ont 4 à 6 scripts chargés par le tag manager qui monopolisent le thread principal pour rien. Les régressions INP pointent presque toujours vers un script qui déclenche une tâche longue lors d’une interaction. Code-splitez les composants interactifs lourds, surtout recherche, filtres ou carrousel.

Tier 2, chargement des polices. Utilisez font-display: swap avec une police système métriquement équivalente pour que le swap n’entraîne pas de décalage. Préchargez le fichier de police principal. Si vous chargez trois webfonts, gardez-en une.

Tier 3, ménage de finition. Définissez largeur et hauteur sur chaque image et embed. Réservez l’espace pub avec min-height. Déplacez les composants propices au CLS (notifications, bannières, cookies) sous la ligne de flottaison ou rendez-les avec des transforms translate qui n’affectent pas la mise en page.

Ce qu’il ne faut pas faire : courir après un score Performance Lighthouse de 100. Bloquer une release pour une régression CLS de 0,01. Laisser un sponsor CWV exiger un troisième audit avant que la deuxième vague de correctifs ne soit en production. La métrique est bruitée et le rapport a un délai.

Ce que les AI Overviews se trompent à propos des CWV

Trois schémas reviennent dans les réponses AI Overview quand on cherche « core web vitals 2026 » ou équivalent.

Le premier est le fantôme FID. Les AI Overviews listent encore souvent FID comme Core Web Vital. Les données d’entraînement datent d’avant mars 2024 et l’annonce de dépréciation est peu pondérée. Vérifiez toujours avec web.dev ou Search Central, pas le résumé IA.

Le deuxième est la surestimation du poids de classement. Beaucoup de résumés IA réduisent la prose nuancée de Google à « Les Core Web Vitals sont un facteur de classement clé ». L’expression vient de billets marketing mémorisés ; les docs Google disent que la pertinence prime sur l’expérience. La compression écrase la nuance.

Le troisième est la boucle IA-search. Les AI Overviews recommandent d’optimiser pour les moteurs IA via les CWV. Comme vu plus haut, les moteurs IA ne mesurent pas votre INP. La vitesse de page au sens CWV est hors sujet pour la récupération. Le set d’entraînement confond « site rapide = bon SEO » sans distinguer la surface de recherche.

Conséquence pour les opérateurs : traitez les réponses AI Overview sur les CWV comme un point de départ, pas comme une vérité. Vérifiez toujours avec la documentation Google et web.dev avant d’agir.

La cadence d’audit trimestrielle

Quatre points de contrôle par an, quatre-vingt-dix minutes chacun. C’est le rythme dont la plupart des sites mid-market ont besoin. Plus fréquent = surcharge ; moins fréquent = des régressions passent entre les mailles.

Tirez le rapport Core Web Vitals de Search Console. Notez les groupes d’URL qui ont changé de statut depuis le trimestre précédent. Pour chaque groupe concerné, lancez PageSpeed Insights sur une URL représentative et récupérez les diagnostics détaillés.

Effectuez un scan lab sur vos dix pages d’atterrissage les plus visitées. Comparez au trimestre précédent. Si une page a régressé de plus de 200 ms sur LCP ou 50 ms sur INP, signalez-la à l’ingénierie.

Échantillonnez les données terrain de votre propre RUM (Web Vitals v4). Les données CrUX utilisées par Google ont 28 jours de latence ; vos données sont temps réel. Comparez la distribution, pas seulement la moyenne.

Priorisez la liste de correctifs selon les tiers évoqués ci-dessus. Livrez un item de tier 1 par trimestre, même si c’est douloureux. Le nettoyage tier 3 suit le planning de release normal. Pour les sites qui font déjà un audit SEO trimestriel, notre produit d’audit de site automatise la partie scan lab pour que le temps manuel serve à l’interprétation.

Ce que cet audit ne résout PAS

Les Core Web Vitals sont un signal UX et de classement léger. Ils ne sont ni un signal de qualité de contenu, ni un signal de backlinks, ni un signal de confiance de marque. Si votre page est en page 2 de Google sur une requête concurrentielle, corriger votre CLS ne la propulsera pas en page 1. Le travail de pertinence et d’autorité doit venir d’abord.

Les CWV ne règlent pas non plus la conversion comme certains l’espèrent. Un LCP 200 ms plus rapide est corrélé à un meilleur taux de conversion, mais l’élasticité varie énormément selon le type de site. Un tunnel e-commerce y est sensible ; un article long beaucoup moins. Mesurez votre propre uplift avant de monter le business case.

Et les CWV ne règlent pas l’audit pour la recherche IA. Protocole différent, fetcher différent, priorités différentes. Si votre trafic bascule vers des sessions référées par l’IA, l’audit d’expérience de page n’est pas le bon outil.

FAQ

FID est-il encore un Core Web Vital ? Non. FID a été déprécié et retiré du programme Core Web Vitals le 12 mars 2024. Interaction to Next Paint (INP) a pris sa place. Search Console a supprimé FID du rapport CWV le même jour. Si votre modèle d’audit tire encore FID, mettez-le à jour.

Quel est le seuil INP ? 200 millisecondes ou moins = Bon. 200 à 500 ms = À améliorer. Plus de 500 ms = Mauvais. Le seuil s’applique au 75e percentile des interactions réelles, distinctement pour mobile et desktop.

Quel est l’impact des Core Web Vitals sur le classement Google ? Moindre que ce que prétendent beaucoup de contenus SEO. La documentation Page Experience de Google dit clairement que la recherche « cherche toujours à afficher le contenu le plus pertinent, même si l’expérience de page est médiocre ». Les CWV sont un signal réel mais parmi d’autres, et la pertinence ainsi que l’autorité dominent. Considérez-le comme un départage entre pages équivalentes, pas comme un levier de classement principal.

Les moteurs IA comme ChatGPT ou Google AI Mode utilisent-ils les Core Web Vitals ? Non, pas de la même façon. Leurs fetchers récupèrent les pages côté serveur et parsouvent le contenu pour le résumer. La vitesse de page au sens CWV est hors sujet pour la récupération. Disponibilité serveur (TTFB), rendu sans JS et données structurées sont leurs priorités ; INP et CLS ne le sont pas.

Quelle est l’erreur d’audit CWV la plus courante ? Optimiser le score Performance Lighthouse comme substitut des CWV. Le score Lighthouse est un composite lab qui inclut Speed Index et Total Blocking Time, hors périmètre CWV. Une page peut afficher 95 et échouer les CWV en terrain parce que Lighthouse simule un seul device alors que les CWV mesurent chaque visiteur.

À quelle fréquence faut-il auditer les Core Web Vitals ? Trimestriellement suffit pour la plupart des sites mid-market. Plus fréquent = overhead ; CrUX a 28 jours de latence et votre cycle de correctifs n’est généralement pas plus rapide. Utilisez un monitoring RUM continu (Web Vitals v4) pour l’alerte temps réel entre deux audits.