Core Web Vitals : les vrais seuils et les faux amis

Les Core Web Vitals sont sans doute le sujet SEO où l’on lit le plus de bêtises. Métriques inventées de toutes pièces pour faire du « 2026 », articles qui parlent encore du FID, mort depuis mars 2024, promesse du Lighthouse 100/100 qui va te propulser en top 1.

Ce guide reprend ce qui se passe vraiment, à partir des sources officielles, et de ce que je vois toutes les semaines chez mes clients. Je les aborde avec ma casquette de consultant SXO, parce que ces trois métriques ne notent que la qualité perçue du chargement et de la réactivité : une page rapide qui ne convertit pas reste une page ratée.

Les 3 métriques et leurs seuils officiels

Trois métriques, trois seuils, trois tranches. Le tableau ci-dessous est celui à garder sous la main pendant tout un chantier de performance.

Source officielle : web.dev/articles/vitals. Ces seuils n’ont bougé ni en 2025 ni en 2026, quoi que tu aies pu lire ailleurs.

Ce que « passer » les CWV veut vraiment dire

Un site passe ses Core Web Vitals quand, pour une URL donnée, le 75e percentile des visites Chrome des 28 derniers jours affiche des valeurs dans le vert. C’est la définition officielle de Google, et elle a deux conséquences concrètes.

D’abord, ce ne sont pas tes données à toi qui comptent, mais celles de tes vrais visiteurs, remontées par Chrome vers le CrUX report. Un test solo dans Lighthouse à l’heure creuse ne pèse rien.

Ensuite, il faut que 75 % de tes visites soient bonnes. Pas 50 %, pas 60 %. C’est un seuil sévère, et c’est exactement pour ça que les sites moyens échouent.

Les fake news qui circulent en 2026

Trois affirmations que tu croiseras dans des articles récents, et qui sont fausses :

• « Le seuil LCP est passé à 2,0 secondes. » Non, il est toujours à 2,5 s, et aucun communiqué officiel n’annonce le contraire.
• « Google a introduit deux nouvelles métriques nommées Engagement Reliability et Visual Stability Index. » Non, ces métriques n’existent pas. Zéro trace sur web.dev ou sur developer.chrome.com.
• « Le TTFB est devenu un facteur de ranking officiel. » Non. Il est plus visible dans PageSpeed Insights, ça oui, mais ça reste une composante technique qui influence le LCP, pas un critère de classement.

INP a remplacé FID : ce que ça change vraiment

Deux ans après le remplacement officiel, une bonne moitié des articles francophones sur le sujet parlent encore de FID. C’est gênant quand tu essaies d’améliorer une métrique qui n’existe plus.

Pourquoi Google a fait ce changement

FID mesurait uniquement le délai entre le premier clic ou tap et le moment où le navigateur commençait à traiter l’événement. Deux limites majeures : il ne prenait en compte que la première interaction, et il ne mesurait que le début du traitement, jamais sa totalité.

INP corrige les deux. Il regarde toutes les interactions de la session, retient la pire (au 98e percentile sur les pages à nombreuses interactions) et calcule la durée complète, depuis l’input jusqu’à ce que le frame suivant soit peint à l’écran.

Résultat : INP est beaucoup plus dur à passer que FID ne l’était. Sur les sites chargés en JavaScript côté client, on découvre souvent qu’on est en orange ou en rouge alors qu’on se croyait tranquille depuis des années.

Les trois composantes d’INP à connaître

Quand tu débugges un INP mauvais, décompose systématiquement en trois blocs :

• Input delay : le temps entre l’action de l’utilisateur et le moment où le navigateur peut commencer à traiter. Souvent bloqué par une long task JavaScript déjà en cours.
• Processing time : le temps que met ton code à traiter l’événement. Handler lourd, calcul synchrone, rendu React trop massif.
• Presentation delay : le temps entre la fin du traitement et l’affichage du résultat à l’écran. Souvent négligé, souvent coupable.

Un INP en rouge est rarement dû à une seule cause : c’est un empilement des trois blocs, et il faut regarder chacun via Chrome DevTools, onglet Performance, section Interactions.

Field data et lab data : la confusion qui coûte cher

C’est le piège numéro 1 des Core Web Vitals, et celui qui fait le plus de dégâts en agence comme en freelance.

Ce que Lighthouse mesure

Lighthouse, que tu l’ouvres dans Chrome DevTools, sur PageSpeed Insights ou dans une CI GitHub Actions, exécute un test unique, dans un environnement simulé, à un moment donné. C’est ce qu’on appelle du lab data.

C’est utile pour déboguer, et même très utile : Lighthouse te dit précisément quelle image est en cause pour ton LCP, quel script bloque ton INP, où ton CLS se joue. En revanche son score n’est pas ce que Google note. Un site à 100/100 peut afficher ses trois CWV au rouge dans la Search Console, et j’en croise tous les mois.

Ce que Google mesure réellement

Google note du field data, autrement dit des données de terrain : les mesures collectées passivement par Chrome sur les vrais utilisateurs de ton site, agrégées dans le CrUX report. Fenêtre glissante de 28 jours, ségrégation mobile et desktop, calcul au 75e percentile.

Ces données arrivent dans ton PageSpeed Insights, section « Discover what your real users are experiencing », et dans le rapport Core Web Vitals de ta Search Console. C’est ça, et rien que ça, qui compte pour le classement.

Comment lire PageSpeed Insights sans se tromper

Un rapport PageSpeed Insights, c’est deux blocs. En haut le field data, ce que voit Google. En bas le lab data, ce que tu vois si tu testes maintenant. La règle tient en une phrase : le bloc du haut te dit si tu passes, le bloc du bas te dit comment corriger.

Attention aussi au cas des pages à faible trafic, pour lesquelles le CrUX peut être vide. Il faut alors regarder les données à l’échelle de ton origine, c’est-à-dire de ton domaine entier, plutôt que de l’URL testée.

Par où commencer : mon ordre d’attaque

Un audit CWV avec 40 recommandations n’aide personne. L’ordre ci-dessous est celui que j’applique chez mes clients, et il vaut autant que les corrections elles-mêmes.

Le LCP en premier

C’est la métrique la plus corrélée aux taux de conversion, la plus visible dans PageSpeed Insights, et souvent la plus rapide à corriger. C’est donc celle qui embarque le plus vite les développeurs comme les décideurs.

L’INP ensuite

C’est la métrique la plus échouée en 2026, surtout sur les stacks JavaScript lourds, et la plus longue à corriger. Autant s’y attaquer quand le LCP est déjà sécurisé et que le budget est encore chaud. Prévois du temps développeur, pas deux heures un vendredi soir.

Le CLS en dernier

C’est la plus mécanique : quelques width, height, aspect-ratio et c’est plié. En 2026, 81 % des pages mobiles passent déjà le CLS, il est souvent réglé avant même qu’on commence. Seule exception, un site où le CLS est catastrophique au-delà de 0,5 : là je passe en premier, parce que c’est visuellement insupportable et que ça décrédibilise tout le reste.

LCP : où mettre son argent, où ne pas

Trois leviers font l’immense majorité du travail. Le reste relève de la marge.

• fetchpriority="high" sur l’image LCP. Une ligne de code, pour un gain de 200 à 500 ms observé sur mes missions. À combiner avec un <link rel="preload"> quand l’image est chargée en CSS.
• Format AVIF, WebP en repli. Plus d’excuse au JPEG : AVIF réduit le poids de 30 à 50 % face au WebP, et de 50 à 70 % face au JPEG. Cloudflare Polish, Cloudinary et Vercel Image Optimization le font automatiquement.
• Un CDN sérieux. Un TTFB au-dessus de 800 ms plombe mécaniquement ton LCP. Cloudflare, Fastly ou Vercel Edge, ça ne se discute plus.

INP : pourquoi ton React te fait mal

On rentre dans le dur. L’INP est la métrique qui demande le plus de temps développeur, et elle se travaille en trois chantiers.

• Découper les long tasks. Une tâche JavaScript qui bloque le thread principal plus de 50 ms fige toute interaction. Outils : scheduler.postTask() pour découper explicitement, requestIdleCallback pour ce qui peut attendre, un Web Worker pour tout calcul lourd comme un parsing, un tri ou un filtre.
• Alléger les event handlers. Un onClick qui re-render 500 composants React n’est pas gratuit. useMemo sur les listes lourdes, React.memo sur les composants stables, et sur Next.js App Router, des Server Components pour tout ce qui n’a pas besoin d’être interactif côté client.
• Réduire la charge d’hydratation. Sur Next.js, Nuxt ou SvelteKit, l’hydratation initiale peut faire exploser ton INP dans les trois premières secondes. La vraie réponse consiste à envoyer moins de JavaScript au client : React Server Components, Server Actions, îlots interactifs Astro, tout ce qui allège la facture fonctionne.

CLS : les 5 corrections qui suffisent

Le CLS est la métrique la plus mécanique à corriger. Cinq patterns couvrent la quasi-totalité des cas.

• width et height sur toutes les <img> et <video> : le navigateur réserve la place avant même le chargement.
• aspect-ratio en CSS sur les containers dynamiques : plus élégant qu’un min-height quand la taille dépend du contenu.
• min-height sur les blocs publicitaires, embeds et iframes : si tu ne connais pas la taille finale, réserve au moins un plancher.
• font-display: optional : évite le flash de texte non stylisé qui décale tout le layout.
• Animations en transform et opacity : ces deux propriétés ne déclenchent aucun layout shift, contrairement à top, left ou margin.

Les 5 faux amis des Core Web Vitals

C’est la partie que peu d’articles osent aborder : ce qui a l’air de bien faire, mais qui ne change rien, voire aggrave.

1. L’obsession du score Lighthouse

Un Lighthouse à 100/100 ne dit rien de tes vraies performances. Tu peux afficher 100/100 en test et trois CWV au rouge dans la Search Console. Concentre-toi sur le field data, pas sur la satisfaction esthétique du score.

2. La minification agressive

Passer ton JavaScript de 200 Ko à 190 Ko ne sauvera pas ton LCP. Le vrai levier consiste à charger moins de JavaScript, pas à le compresser plus fort.

3. Le lazy loading sur l’image LCP

Contresens classique. Le loading="lazy" doit être appliqué aux images below-the-fold, jamais à l’image LCP. Faire l’inverse fait exploser la métrique que tu cherches à corriger.

4. AMP

Google a discrètement enterré AMP en 2021 en le retirant des critères « top stories ». Y investir aujourd’hui est une perte de temps : un site classique correctement optimisé fait aussi bien, sans les contraintes.

5. Les plugins WordPress tout-en-un

WP Rocket, Perfmatters et LiteSpeed Cache sont utiles quand ils sont configurés proprement. Activés sans regarder, ils cassent souvent plus qu’ils n’aident : combiner le CSS agressivement peut décaler le rendu et faire exploser le LCP, différer tous les scripts peut casser l’INP.

Impact réel sur le ranking : ce que Google ne dit pas franchement

« Est-ce qu’améliorer mes CWV va me faire ranker mieux ? » C’est la question qu’on me pose à chaque premier appel, et la réponse honnête tient en trois points.

Ils départagent, ils ne propulsent pas

Sur un mot-clé compétitif où deux pages ont un contenu et une autorité équivalents, celle qui passe les CWV bat celle qui échoue. Sur un mot-clé où ton concurrent a dix backlinks de qualité et où tu en as deux, corriger ton LCP ne changera rien à ta position. Le netlinking pèse là où la performance ne peut rien.

Ce que 20 000 € de refonte ne rapportent pas

J’ai vu trop de dirigeants investir 20 000 € en refonte technique en espérant un tsunami de trafic, et rester exactement au même niveau. Les CWV valent la peine d’être corrigés parce que l’impact utilisateur est réel, sur le taux de rebond et sur les conversions, ce qui relève du SXO autant que de la performance. Pas parce que Google va te propulser en top 1.

Mobile first, la vraie règle du jeu

Google note le CrUX mobile pour évaluer ta performance dans les résultats mobiles. Un site parfait sur desktop mais mauvais sur mobile est pénalisé. Regarde toujours mobile en premier : si mobile est vert, desktop suivra dans la quasi-totalité des cas, alors que l’inverse n’est jamais vrai.

Quand faire appel à un consultant

Si tu es une petite structure avec un site simple, disons un WordPress de moins de 20 pages, un développeur compétent peut passer tes CWV au vert en une à deux journées. Tu n’as pas besoin d’un consultant SEO pour ça, et je préfère te le dire tout de suite.

Si ton site tourne sur React, Next.js ou Vue, ou si tu dépasses les 500 pages avec un e-commerce actif ou une PWA, la donne change. L’INP demande du temps, l’analyse doit intégrer les vraies données CrUX et pas seulement Lighthouse, et l’ordre de bataille compte autant que les corrections.

C’est ce que je traite dans le cadre d’un audit SEO technique : diagnostic complet, ordre priorisé, propositions concrètes que tes développeurs peuvent implémenter. Si ça t’intéresse, parlons-en 30 minutes, sans engagement.