LCP, INP, CLS : ce que mesure chaque métrique
Trois métriques, trois dimensions distinctes de l'expérience perçue. Le LCP mesure la vitesse de chargement, l'INP la réactivité, le CLS la stabilité visuelle. Aucune ne remplace les autres : une page peut s'afficher vite et rester injouable, ou réagir au doigt et danser sous les yeux. L'audit traite les trois séparément.
LCP — Largest Contentful Paint
Le LCP mesure le temps écoulé jusqu'à l'affichage du plus grand élément visible dans la fenêtre : généralement une image hero, une vidéo ou un bloc de texte volumineux. Seuil de réussite : moins de 2,5 secondes. Au-delà de 4 secondes, la page est jugée lente. Le LCP est dominé par quatre facteurs : le temps de réponse serveur (TTFB), les ressources bloquant le rendu (CSS et JS synchrones), le temps de chargement de la ressource elle-même, et le délai avant que le navigateur ne la découvre.
INP — Interaction to Next Paint
L'INP a remplacé le FID en mars 2024. Il mesure la latence entre une interaction utilisateur (clic, tap, frappe) et le prochain rendu visuel qui en découle. Contrairement au FID qui ne jugeait que la première interaction, l'INP observe toutes les interactions de la session et retient la pire. Seuil : moins de 200 millisecondes. Un INP dégradé révèle presque toujours un thread principal saturé par du JavaScript trop long.
CLS — Cumulative Layout Shift
Le CLS quantifie les décalages visuels inattendus : un bouton qui saute parce qu'une bannière se charge en retard, une image sans dimensions qui repousse le texte. Seuil : moins de 0,1. C'est un score sans unité, calculé sur la fraction de l'écran déplacée multipliée par la distance du déplacement.
Données de labo vs données de terrain
Un audit Core Web Vitals crédible repose sur deux sources complémentaires que l'on confond trop souvent. Les données de laboratoire diagnostiquent, les données de terrain valident.
Les données de laboratoire proviennent d'une visite simulée, dans des conditions standardisées : une machine définie, un réseau bridé, sans cache. Lighthouse en est la source de référence. Leur force est la reproductibilité et le débogage : vous isolez une cause, vous corrigez, vous re-mesurez immédiatement. Leur limite : elles ne reflètent pas votre audience réelle, ses appareils, ses connexions.
Les données de terrain (field data) viennent du Chrome User Experience Report (CrUX) ou de votre propre RUM (Real User Monitoring). Elles agrègent les visites réelles sur 28 jours glissants. C'est cette donnée que Google utilise pour juger une URL, et c'est elle qui s'affiche dans la Search Console.
| Critère | Données de laboratoire | Données de terrain |
|---|---|---|
| Source | Lighthouse, simulation | CrUX, RUM, Search Console |
| Conditions | Standardisées, reproductibles | Appareils et réseaux réels |
| INP mesurable | Non (pas d'interactions réelles) | Oui |
| Usage | Diagnostiquer et déboguer | Valider l'impact réel |
| Verdict Google | Aucun | Détermine la conformité |
Conséquence pratique : ne jugez jamais l'INP sur un score de laboratoire. Lighthouse ne clique sur rien. L'INP n'existe que sur le terrain. Un audit qui annonce un INP « parfait » depuis Lighthouse se trompe d'outil.
Les outils pour mener l'audit
Cinq outils suffisent, chacun pour un usage précis. Le piège est d'en utiliser un seul et de croire l'audit terminé.
Le point de départ. Il regroupe vos URL par statut (bon, à améliorer, médiocre) à partir des données de terrain. Il révèle l'ampleur réelle du problème à l'échelle du site, pas d'une page isolée.
Le seul outil qui affiche labo ET terrain côte à côte pour une URL. Idéal pour confirmer qu'un problème de laboratoire se vérifie chez les vrais utilisateurs.
Pour le diagnostic profond. Il liste les opportunités chiffrées : ressources bloquantes, images surdimensionnées, JS inutilisé. C'est ici que vous trouvez les causes racines.
Pour l'INP et le thread principal. Vous enregistrez une interaction réelle et vous voyez exactement quelle tâche JS bloque le rendu.
Pour mesurer en continu sur vos propres parcours, en conditions réelles, sans attendre l'agrégation CrUX.
La méthode : la Search Console pour cadrer, PageSpeed Insights pour prioriser les pages-types, Lighthouse et le Performance panel pour disséquer chaque métrique. Ne vous noyez pas dans le détail d'une URL avant d'avoir une vue d'ensemble. Cette logique de cadrage avant détail est la même que celle d'un audit SEO complet.
Corriger chaque métrique, par cause racine
Une correction efficace cible la cause dominante, pas tous les symptômes. Chaque métrique a ses leviers propres. On corrige, on re-mesure, on passe au goulot suivant.
Corriger le LCP
Commencez par le TTFB : un serveur lent ou un cache absent plombe tout le reste. Activez le cache, rapprochez la donnée via un CDN, allégez le rendu côté serveur. Ensuite, donnez la priorité à la ressource LCP : fetchpriority="high" sur l'image hero, préchargement (preload) de la police et de l'image critique, suppression du lazy-loading sur l'élément above-the-fold. Enfin, éliminez les ressources bloquant le rendu : CSS critique en ligne, JS non essentiel en defer.
Corriger l'INP
L'INP se gagne sur le thread principal. Découpez les longues tâches JavaScript en morceaux plus courts, différez tout ce qui n'est pas nécessaire à l'interaction immédiate, et déportez les calculs lourds dans un Web Worker. Méfiez-vous des scripts tiers (tags analytics, chat, A/B testing) : ils sont souvent le premier responsable d'un INP dégradé.
Corriger le CLS
Le CLS se règle presque toujours par la réservation d'espace. Déclarez systématiquement width et height (ou aspect-ratio) sur les images et vidéos. Réservez la place des bannières et publicités avant leur chargement. Chargez les polices avec font-display: optional ou préchargez-les pour éviter le décalage du texte (FOIT/FOUT).
Le LCP est de loin la métrique la plus souvent en échec sur les sites français. Le coupable numéro un reste le TTFB, suivi des images hero non optimisées et du JavaScript bloquant. Corriger le serveur avant les images donne presque toujours le meilleur retour.
Un détail structurel pèse sur l'ensemble : les pages rendues uniquement côté client. Les LLM n'exécutent pas le JavaScript, ce qui rend le SSR ou le HTML statique indispensable pour la visibilité IA — et le même rendu serveur améliore mécaniquement le LCP en livrant le contenu sans attendre l'hydratation. Une seule décision d'architecture sert deux objectifs.
Pour structurer cette démarche de bout en bout, notre checklist d'audit SEO 2026 intègre un volet performance directement actionnable.
Impact SEO réel et arbitrage des priorités
Les Core Web Vitals sont un facteur de classement, mais un facteur mineur. Soyons précis pour éviter le surinvestissement comme la négligence. Ils appartiennent au signal d'expérience de page, qui départage des résultats de pertinence comparable. Ils ne compenseront jamais un contenu faible, et un site déjà en zone verte ne gagnera pas de positions en passant de 2,4 à 1,8 seconde de LCP.
L'arbitrage rationnel suit trois règles. Premièrement, sortir de la zone rouge est prioritaire ; passer du vert clair au vert foncé ne l'est pas. Deuxièmement, traitez les gabarits, pas les URL isolées : corriger le template d'une catégorie répare des milliers de pages d'un coup. Troisièmement, l'impact business dépasse souvent l'impact SEO direct — une page plus rapide convertit mieux, et le taux de rebond chute.
Cet équilibre fait partie du travail d'optimisation technique continue que nous menons pour nos clients en tant qu'agence SEO : franchir les seuils, sécuriser le terrain, puis investir là où le levier de croissance est réel. Pour appliquer cette rigueur à votre propre audit, le Pack Templates Audit GEO fournit les grilles de mesure et de priorisation prêtes à l'emploi.
Demandez votre audit GEO gratuit : performance technique, citabilité IA et priorités classées par gain réel.
Questions fréquentes
Les Core Web Vitals sont-ils un facteur de classement Google ?+
Oui, mais un facteur mineur. Ils font partie du signal d'expérience de page, qui départage des résultats de pertinence comparable. Une page lente avec un contenu supérieur peut surclasser une page rapide au contenu faible. Les Core Web Vitals agissent comme un tie-breaker, pas comme un levier de pertinence.
Quelle différence entre le score Lighthouse et les données de la Search Console ?+
Lighthouse mesure une visite simulée en laboratoire, sur une machine et un réseau standardisés. La Search Console affiche les données de terrain (CrUX), agrégées sur les visites réelles des 28 derniers jours, au 75e centile. C'est cette donnée de terrain qui détermine si une URL est jugée conforme par Google.
L'INP a-t-il remplacé le FID ?+
Oui. Depuis mars 2024, l'INP (Interaction to Next Paint) remplace le FID comme métrique de réactivité. L'INP est plus exigeant : il mesure la latence de toutes les interactions d'une page, pas seulement la première, et retient la pire. Beaucoup de sites conformes au FID échouent à l'INP.
Combien de temps avant de voir l'effet d'une correction Core Web Vitals ?+
Les outils de laboratoire montrent l'effet immédiatement. Les données de terrain de la Search Console, elles, sont calculées sur une fenêtre glissante de 28 jours. Il faut donc attendre environ quatre semaines après le déploiement pour voir le statut d'une URL basculer en zone verte.
