# Core Web Vitals 2026 : le guide d'expert (LCP, INP, CLS) Core Web Vitals 2026 : seuils exacts, INP en profondeur, ordre de priorisation, faux amis et vraies optimisations. Le guide sans langue de bois. Publié le 2026-08-01 Source : https://abdelseo.fr/blog/core-web-vitals-guide-complet/ --- **Ce qu'il faut retenir** 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](/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. | Métrique | Bon | À améliorer | Mauvais | | :--- | :--- | :--- | :--- | | **LCP** (Largest Contentful Paint) | ≤ 2,5 s | 2,5 à 4,0 s | > 4,0 s | | **INP** (Interaction to Next Paint) | ≤ 200 ms | 200 à 500 ms | > 500 ms | | **CLS** (Cumulative Layout Shift) | ≤ 0,10 | 0,10 à 0,25 | > 0,25 | Source officielle : [web.dev/articles/vitals](https://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. **Alerte** quand un article annonce des « nouveautés Core Web Vitals 2026 », vérifie sur **web.dev** avant d'y croire. Si l'info n'existe pas là-bas, c'est du contenu SEO fabriqué. J'en vois passer chaque semaine. ## 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. **À retenir** si tu es sur React, Next.js ou Vue, ton INP est probablement moins bon que ce que tu crois. **L'hydratation et les gros handlers d'événements** sont les tueurs numéro 1. Regarde avant de me dire que tout roule. ## 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. **Astuce d'expert** commence par la Search Console, pas par Lighthouse. Rapport « Signaux web essentiels », vue mobile en premier : c'est là que tu vois **les URLs groupées qui échouent réellement**. Lighthouse vient ensuite, pour disséquer une URL problématique. ## Par où commencer : mon ordre d'attaque Un [audit](/blog/audit-seo-guide-complet/) 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 `` 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. Client e-commerce mode, LCP à 5,2 s au démarrage. On applique `fetchpriority` sur l'image du bandeau, on bascule les images produit en **AVIF** via Cloudflare Polish, et on remet le tout derrière leur CDN existant, mieux configuré cette fois. Le LCP passe à 2,1 s, pour **deux jours de développement** et pas davantage. C'est ça, un chantier LCP typique : peu de lignes, mais posées au bon endroit. **Astuce d'expert** identifie d'abord **ton** image LCP avant de tout optimiser. Chrome DevTools, onglet Performance, recharge la page et cherche le marqueur LCP. Optimiser une image qui n'est pas la tienne ne change rien à ton score. ## 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. SaaS B2B en Next.js, INP à 780 ms au démarrage. On trace le problème avec DevTools : un handler de recherche global qui **re-render toute l'application à chaque frappe clavier**. Un `useDeferredValue` bien placé, un `startTransition` autour du filtre, et **on tombe à 190 ms**. C'est ça, un chantier INP typique quand on met le doigt sur le bon endroit : la correction est courte, c'est le diagnostic qui prend le temps. **Astuce d'expert** sur un site React, teste toujours l'INP après un scroll ET après une interaction : clic sur un menu, ouverture d'un modal, saisie dans un champ. **Le pire cas se cache dans les interactions les moins visibles**, et c'est précisément ce que Google note au 98e percentile. ## 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 `` et `