Depuis mars 2024, Google a remplacé l’indicateur FID par l’INP dans ses Core Web Vitals. Et depuis 2025, ces métriques sont devenues un facteur de ranking direct dans la nouvelle version de l’algorithme. Concrètement : si votre site échoue aux Core Web Vitals, vous perdez des positions, peu importe la qualité de votre contenu. Voici le guide complet pour passer le test en 2026.

Que sont vraiment les Core Web Vitals ?

Les Core Web Vitals sont trois métriques que Google utilise pour mesurer l’expérience utilisateur réelle d’un site. Pas la performance théorique : la vraie expérience, telle que la vivent vos visiteurs avec leur téléphone et leur connexion variable.

Les trois métriques actuelles sont :

LCP (Largest Contentful Paint) : temps avant que le plus gros élément visible (image, titre, vidéo) soit affiché
INP (Interaction to Next Paint) : délai entre une interaction (clic, tap) et le retour visuel
CLS (Cumulative Layout Shift) : stabilité visuelle, mesure les éléments qui « sautent » pendant le chargement

Il y a aussi 3 métriques complémentaires suivies en arrière-plan : FCP (First Contentful Paint), TTFB (Time to First Byte) et TBT (Total Blocking Time).

Les seuils à atteindre absolument en 2026

Métrique	✅ Bon	⚠️ À améliorer	❌ Mauvais
LCP	< 2,5 s	2,5 - 4 s	> 4 s
INP	< 200 ms	200 - 500 ms	> 500 ms
CLS	< 0,1	0,1 - 0,25	> 0,25
FCP	< 1,8 s	1,8 - 3 s	> 3 s
TTFB	< 800 ms	800 - 1800 ms	> 1800 ms

Important : Google utilise les données du 75e centile sur 28 jours glissants. Cela veut dire que 75 % de vos utilisateurs réels doivent voir des valeurs « Bon » pour que votre site soit considéré comme performant.

LCP : le seuil le plus difficile à atteindre

Le LCP mesure le temps d’affichage du plus gros élément au-dessus de la ligne de flottaison. C’est en général une image hero, un titre H1 dans une bannière, ou une vidéo de fond.

Les causes d’un LCP élevé

1. Image hero non optimisée. Une image en JPEG de 800 KB met 3-4 secondes à charger sur 4G. Convertie en WebP avec compression adaptée, elle fait 80 KB et charge en 0,3 s.

2. Lazy loading mal placé. Si vous mettez loading="lazy" sur l’image hero, elle ne charge qu’après le premier render — catastrophe pour le LCP. Utilisez loading="eager" et fetchpriority="high" sur les images critiques.

3. Polices web bloquantes. Une @font-face qui charge en synchrone bloque le render. Utilisez font-display: swap et préchargez la police critique avec <link rel="preload">.

4. Hébergement lent. Un TTFB > 800 ms signe un hébergeur sous-dimensionné ou mal configuré. Bien souvent, le passage à un hébergeur edge (Netlify, Cloudflare Pages) divise par 3 le TTFB.

5. JavaScript bloquant. Un script dans le <head> sans defer peut retarder le LCP de plusieurs secondes. Utilisez <script defer> ou <script async> selon le cas.

Comment optimiser le LCP

Convertir toutes les images en WebP ou AVIF (Astro le fait automatiquement)
Servir les images en taille adaptée via <img srcset> ou <picture>
Mettre fetchpriority="high" sur l’image hero
Précharger la police principale : <link rel="preload" as="font" type="font/woff2" crossorigin>
Utiliser un CDN edge global
Inliner le CSS critique (Astro inlineStylesheets: 'auto')

INP : la métrique qui a remplacé FID

L’INP a remplacé le FID en mars 2024. Il mesure la réactivité globale du site sur l’ensemble des interactions, pas seulement la première. C’est une métrique beaucoup plus exigeante.

Les causes d’un INP élevé

1. Trop de JavaScript exécuté au chargement. Un site WordPress moyen charge 1 à 2 MB de JavaScript. Le navigateur met du temps à parser et exécuter, ce qui rend le site « gelé » au moindre clic.

2. Listeners synchrones lourds. Un onclick qui déclenche une fonction de 500 ms sans requestIdleCallback bloque le rendering.

3. Animations CSS coûteuses. Animer width, height, top, left provoque des reflows du layout. Utilisez plutôt transform et opacity qui sont accélérés par le GPU.

4. Tracking publicitaire. Google Ads, Meta Pixel, Hotjar, etc. injectent du JS lourd qui dégrade l’INP. Chargez-les via Google Tag Manager avec async ou en différé.

Comment optimiser l’INP

Réduire le bundle JavaScript : Astro charge 0 KB de JS par défaut, c’est l’idéal
Charger les scripts non-critiques en différé : <script defer> ou IntersectionObserver
Utiliser des Web Workers pour les traitements lourds
Animer uniquement avec transform et opacity
Limiter le nombre de scripts tiers (analytics, chat, ads)

CLS : la stabilité visuelle

Le CLS mesure les déplacements imprévus d’éléments pendant le chargement. C’est ce qui fait qu’on clique sur un bouton et qu’au dernier moment, une bannière de cookie apparaît et on clique sur autre chose.

Les causes d’un CLS élevé

1. Images sans dimensions. Une <img> sans width et height ne réserve pas son espace tant qu’elle n’est pas chargée. Quand elle apparaît, tout ce qui est en dessous descend brutalement.

2. Polices web qui changent de taille. Le FOUT (Flash of Unstyled Text) ou le FOIT (Flash of Invisible Text) provoquent un repositionnement quand la police custom finit de charger.

3. Bannières de cookies positionnées en haut. Si la bannière apparaît après 1-2 secondes en haut de page, tout le contenu descend. Préférez une bannière en bas en position: fixed.

4. Iframes ou widgets sans dimensions. Un widget Twitter, une carte Google Maps, un lecteur YouTube sans dimensions provoquent un CLS élevé.

5. Annonces dynamiques qui s’insèrent. Les ad units AdSense sans data-ad-format="auto" peuvent provoquer des shifts.

Comment optimiser le CLS

Toujours spécifier width et height sur les images et iframes
Utiliser font-display: optional pour éviter les FOUT (au détriment de la robustesse multi-langue)
Précharger les polices critiques
Réserver l’espace pour les contenus dynamiques avec un placeholder de la taille attendue
Bannière de cookies en position: fixed plutôt qu’insérée en flow

Comment tester votre site ?

Plusieurs outils complémentaires sont à votre disposition.

PageSpeed Insights (gratuit, Google)

https://pagespeed.web.dev — l’outil officiel. Il combine deux mesures : les données de terrain (CrUX, vraies données utilisateurs des 28 derniers jours) et les données de laboratoire (test simulé en environnement contrôlé).

Si vos données de terrain sont absentes, c’est que votre site n’a pas encore assez de trafic. Dans ce cas, Google se base sur les données labo, ce qui est moins fiable mais reste exploitable.

Search Console > Expérience > Signaux Web essentiels

Une fois votre site dans Search Console, vous accédez à un rapport mensuel sur les Core Web Vitals de l’ensemble de vos pages, avec catégorisation Bon / À améliorer / Mauvais et URLs concernées. C’est l’outil de pilotage indispensable.

Chrome DevTools > Performance + Lighthouse

Pour un audit profond, ouvrez DevTools (F12), onglet Lighthouse, mode mobile, exécutez l’audit. Vous obtenez un rapport détaillé avec recommandations prioritaires. C’est ce qu’utilisent les développeurs au quotidien.

WebPageTest (gratuit, plus avancé)

https://www.webpagetest.org — permet de tester depuis différentes localisations géographiques (Paris, Berlin, NYC, Tokyo) avec différents profils de connexion (4G lente, 4G rapide, fibre). Idéal pour détecter les problèmes de CDN.

Combien de temps pour passer les Core Web Vitals ?

Cela dépend de la situation initiale.

Site déjà bon (score Lighthouse > 80) : 1 à 2 jours d’optimisations ciblées suffisent généralement pour passer dans le vert sur les 3 métriques.

Site moyen (score 50-80) : 3 à 5 jours de travail dédié, comprenant la conversion des images, le nettoyage du JavaScript, l’optimisation des polices et le passage à un hébergeur edge.

Site catastrophique (score < 50) : généralement, c’est un site WordPress avec 30+ plugins. Soit on fait un nettoyage en profondeur (5-10 jours), soit on refait le site avec une stack moderne (2-4 semaines), ce qui revient parfois moins cher.

L’astuce méconnue : Astro résout 80 % du problème

C’est notre arme secrète chez Fixweb : Astro génère par défaut 0 KB de JavaScript sur les pages statiques. Les Core Web Vitals sont quasi-automatiquement validés.

Vous voulez du chiffre ? Voici les performances moyennes constatées sur nos 50 derniers sites :

LCP moyen : 1,1 s (Google demande < 2,5 s) ✅
INP moyen : 65 ms (Google demande < 200 ms) ✅
CLS moyen : 0,03 (Google demande < 0,1) ✅
Score Lighthouse mobile : 96/100

Sans aucune optimisation manuelle. Pour une équipe technique, ça représente une économie de 10 à 30 heures par site vs. WordPress.

C’est ce qui explique pourquoi nous avons fait ce choix technique pour 100 % de nos projets (détails ici).

Le piège des outils marketing qui détruisent vos CWV

Voici les coupables les plus fréquents que nous voyons en audit. Si vous les utilisez, vérifiez leur impact :

Google Ads conversion tracking : peut ajouter 200-400 ms d’INP
Meta Pixel (Facebook) : 100-200 ms d’INP, parfois plus
Intercom / Crisp / Tidio (chat) : 300-600 ms d’INP, +200 KB de JS
Hotjar / Microsoft Clarity : 100-300 ms d’INP
Pop-ups Sumo / OptinMonster : peuvent dégrader fortement le CLS si mal configurés
Slider Revolution / Layer Slider (WordPress) : la mort du LCP, charge 500-800 KB
Google Tag Manager mal configuré : cumul de tous les autres

La règle : chaque outil tiers doit être benchmarké avant et après. Si la dégradation des CWV est supérieure au bénéfice marketing mesurable, on ne le garde pas.

Surveiller en continu : la vraie clé du succès

Atteindre des bons Core Web Vitals une fois est facile. Les maintenir dans le temps est le vrai défi. À chaque mise à jour de plugin, à chaque ajout de tracking, à chaque image lourde uploadée par un rédacteur, vous risquez de dégrader le score.

Les bonnes pratiques :

Audit Lighthouse mensuel sur les 5 pages les plus importantes
Alertes Search Console activées pour être notifié dès qu’une page passe en « À améliorer »
Budget de performance : pas plus de 200 KB de JS et 500 KB d’images sur une page
Process de validation avant chaque mise en ligne d’évolutions

C’est ce qu’inclut notre forfait maintenance à 49 € HT/mois (voir détails).

Que faire si vous échouez aux Core Web Vitals ?

Si Search Console vous remonte des URLs en rouge, voici l’ordre des actions :

Identifier les pages les plus visitées qui échouent (priorité au trafic, pas aux pages anecdotiques)
Pour chaque page, lancer PageSpeed Insights pour identifier le facteur limitant
Si le problème est l’image hero, la convertir en WebP et la charger en eager
Si le problème est le JavaScript, identifier les scripts les plus lourds et les passer en defer
Si le problème est le TTFB, changer d’hébergeur
Si le problème est généralisé, envisager une refonte technique

Si vous voulez un audit complet, nous proposons un audit Core Web Vitals à 350 € HT comprenant un rapport détaillé, un plan d’action priorisé, et 1 h de coaching avec votre développeur. Demander un audit.

Pour aller plus loin, notre guide des 12 erreurs SEO couvre les autres facteurs de ranking, et notre comparatif technique explique pourquoi certaines stacks sont structurellement plus performantes.

Core Web Vitals performance web Lighthouse PageSpeed

Etienne Aubry

Fondateur de Fixweb · 10+ ans d'expérience web

Core Web Vitals 2026 : passer le test de performance Google

Que sont vraiment les Core Web Vitals ?

Les seuils à atteindre absolument en 2026