Les Core Web Vitals font partie des signaux d'expérience de page que Google prend en compte dans ses systèmes de classement. Ils ne décident pas seuls du classement : la pertinence du contenu reste prioritaire. Mais à pertinence comparable, une page rapide et stable part avec un avantage, et elle offre une meilleure expérience aux visiteurs. Depuis mars 2024, l'INP (Interaction to Next Paint) a remplacé le FID ; les seuils publiés par Google, eux, n'ont pas changé. Ce guide technique détaille comment mesurer, diagnostiquer et optimiser chaque métrique.
Les 3 métriques Core Web Vitals en 2026
LCP (Largest Contentful Paint) — Seuil : ≤ 2,5 secondes
Le LCP mesure le temps nécessaire pour afficher le plus grand élément visible dans le viewport. C'est la métrique qui reflète le mieux la perception de vitesse de chargement par l'utilisateur. Google considère qu'un LCP de 2,5 secondes au plus est « bon », qu'au-delà il est « à améliorer » et qu'au-delà de 4 secondes, l'expérience est « médiocre ».
Les causes les plus fréquentes d'un LCP lent :
- Images non optimisées : format JPEG/PNG au lieu de WebP/AVIF, fichier trop lourd pour sa taille d'affichage, ou image principale chargée en lazy loading, ce qui retarde son affichage
- Ressources bloquantes : CSS et JavaScript qui retardent le rendu initial
- Temps serveur (TTFB) : Un serveur lent ou un CDN mal configuré
- Fonts web : Polices personnalisées qui bloquent l'affichage du texte (FOIT)
INP (Interaction to Next Paint) — Seuil : ≤ 200 ms
INP a remplacé FID en 2024 et mesure la réactivité globale de la page sur toute la durée de la visite — pas seulement la première interaction. Elle est plus exigeante que le FID : elle observe les clics, les touchers et les frappes au clavier, et retient l'une des interactions les plus lentes de la visite.
Les causes les plus fréquentes d'un INP élevé :
- JavaScript lourd sur le thread principal : Scripts tiers (analytics, chat, pub) qui monopolisent le CPU
- Hydratation des frameworks : React, Next.js et les frameworks similaires exécutent beaucoup de JavaScript au chargement pour rendre la page interactive ; une interaction pendant cette phase doit attendre
- Event handlers coûteux : Calculs complexes déclenchés par des clics ou des scrolls
- Rendu coûteux après l'interaction : un DOM très volumineux ou des recalculs de mise en page forcés retardent l'affichage suivant
CLS (Cumulative Layout Shift) — Seuil : ≤ 0,1
Le CLS mesure la stabilité visuelle de la page. Chaque fois qu'un élément se déplace de manière inattendue (une image qui se charge et pousse le texte, une bannière pub qui s'insère), le score CLS augmente. Un CLS supérieur à 0,1 est « à améliorer », et au-delà de 0,25, « médiocre ».
Mesurer : données de terrain et données de laboratoire
Google évalue les Core Web Vitals sur des données de terrain : celles du Chrome User Experience Report (CrUX), recueillies auprès de vrais utilisateurs de Chrome sur les 28 derniers jours. Une page passe l'évaluation quand ses trois métriques sont « bonnes » au 75e centile des visites. Le rapport « Signaux Web essentiels » de la Search Console présente ces données par groupes d'URL ; PageSpeed Insights les affiche pour une URL, à côté d'un test de laboratoire Lighthouse.
Les tests de laboratoire (Lighthouse, Chrome DevTools) servent à diagnostiquer un problème et à vérifier une correction avant sa mise en ligne. Ils ne remplacent pas les données de terrain. Un test Lighthouse classique ne mesure pas l'INP, qui exige de vraies interactions : le Total Blocking Time (TBT) en donne une indication.
Optimiser : les leviers par métrique
- LCP : servir l'image principale dans un format moderne et à la bonne taille, la précharger ou lui donner une priorité de chargement élevée (attribut fetchpriority), réduire le TTFB (cache, CDN) et le CSS qui bloque le rendu
- INP : découper les tâches longues et rendre régulièrement la main au navigateur, différer ou alléger les scripts tiers, limiter le travail déclenché par chaque clic et la taille du DOM
- CLS : donner des dimensions (width et height, ou aspect-ratio) aux images, vidéos et iframes, réserver la place des publicités et des bannières, et choisir des polices de repli proches de la police finale
Comment Zerkado mesure vos Core Web Vitals
L'audit SEO technique de Zerkado mesure en laboratoire le LCP, le CLS et le TBT sur un échantillon de pages, dans un vrai navigateur en affichage mobile, ainsi que le temps de réponse de toutes les pages explorées. Pour chaque problème relevé, il indique la marche à suivre pour le corriger. L'INP exige de vrais visiteurs : le TBT en donne une approximation en laboratoire, et les données de terrain restent à consulter dans la Search Console.
Le module d'audit SEO classe les anomalies par gravité (critique, avertissement, information) et par nombre de pages touchées, pour vous aider à choisir quoi corriger d'abord. Chaque nouvelle exploration du site met à jour les mesures : une page qui ralentit après une mise en production apparaît au passage suivant.
Pour aller plus loin dans l'optimisation technique de votre site, consultez notre guide complet de l'audit SEO technique et notre article sur les erreurs techniques SEO les plus courantes.