Sommaire
EN BREF
- LCP, INP et CLS sont les trois métriques officielles de Google depuis mars 2024
- Un score PageSpeed vert ne garantit pas de bons résultats dans la Search Console
- Google utilise les données terrain réelles (CrUX), pas les données de laboratoire
- INP remplace FID et est bien plus exigeant sur les sites à forte interactivité
Un site peut afficher un score PageSpeed de 95 et échouer sur ses Core Web Vitals dans la Search Console. Ce n'est pas un paradoxe. C'est la conséquence d'une confusion très répandue entre données de laboratoire et données terrain. Google ne vous juge pas sur votre score Lighthouse. Il vous juge sur l'expérience réelle de vos visiteurs, capturée via le Chrome UX Report. Comprendre cette distinction change radicalement la façon de prioriser ses optimisations.
Ce que Google mesure vraiment sur vos pages
Vue de l'onglet Core Web Vitals dans la Google Search Console (GSC), qui vous indiquez l'écart entre les attentes de Google et la performance technique de vos pages web
Avant de parler de seuils et d'optimisations, regardons comment des sites en production gèrent concrètement leurs signaux de performance Web. Les enseignements ne viennent pas toujours des géants.
Un éditeur de logiciel B2B français, avec un trafic mensuel de 80 000 sessions, a réduit son LCP de 4,8 secondes à 2,1 secondes en une seule intervention : supprimer le lazy-loading sur l'image hero de sa homepage et ajouter l'attribut fetchpriority="high". Aucun refactoring. Aucun CDN supplémentaire. Résultat : passage de "Mauvais" à "Bon" dans le rapport Search Console Signaux Web en six semaines, délai correspondant à la mise à jour du CrUX.
Un site de e-commerce dans le secteur de l'outillage professionnel (environ 15 000 produits) présentait un score CLS supérieur à 0,3 sur mobile. La cause n'était pas les images. C'était une bannière de cookies chargée sans espace réservé, qui repoussait tout le contenu au-dessus de la ligne de flottaison à chaque visite. Correction en deux lignes CSS. Le score CLS est passé sous 0,05 en un cycle CrUX.
Un cabinet de conseil parisien souffrait d'un INP supérieur à 600 ms sur sa page d'accueil, uniquement sur mobile. L'origine était un script de chat en ligne qui bloquait le thread principal pendant le chargement, retardant toute réponse aux interactions utilisateur. Le simple fait de différer ce script via defer a ramené l'INP à 180 ms.
Le pattern commun à ces trois cas : la correction était chirurgicale, pas systémique. Ce que ces sites ont en commun, c'est qu'ils ont d'abord identifié la bonne métrique défaillante dans la Search Console, puis remonté à la cause racine avec PageSpeed Insights, avant d'intervenir. Ce séquençage est transposable immédiatement à n'importe quel site.
La leçon terrain : les Core Web Vitals se corrigent métrique par métrique, pas globalement. Tenter d'améliorer "la performance" en général est une perte de temps. Identifier la métrique rouge dans vos données terrain, c'est là que commence le vrai travail.
LCP, INP, CLS : ce que chaque métrique mesure et pourquoi elle compte
Non, ce ne sont pas des partis politiques ! Ces acronymes sont généreusement offerts par Google, soucieux de simplifier la liste de ses exigences techniques sur vos sites : LCP, FID, CLS.
Trois métriques. Trois dimensions distinctes de l'expérience utilisateur. Elles ne se compensent pas entre elles. Un site excellent sur le LCP peut être disqualifié par un CLS catastrophique. Voici comment Google les définit, ce qu'ils mesurent réellement, et pourquoi chacun mérite une attention séparée.
LCP (Largest Contentful Paint) : la vitesse perçue, pas la vitesse technique
LCP — Largest Contentful Paint
Temps écoulé entre le début du chargement de la page et l'affichage du plus grand élément visible dans le viewport.
< 2,5 s
Bon
< 4 s
À améliorer
≥ 4 s
Mauvais
Éléments mesurés : image hero, bloc de texte principal, vidéo poster
Causes fréquentes : lazy-load sur l'image hero, serveur lent, CSS bloquant
Levier prioritaire :
fetchpriority="high" sur l'image LCP, préconnexion CDN, suppression du lazy-load au-dessus de la ligne de flottaisonLe LCP ne mesure pas quand la page est "chargée". Il mesure quand l'utilisateur perçoit que la page est prête à être utilisée. Cette nuance est fondamentale. Un site peut avoir un Time to First Byte (TTFB) de 80 ms et un LCP de 5 secondes si l'image principale est découverte tard dans le processus de rendu.
La cause la plus fréquente et la moins évidente : l'attribut loading="lazy" appliqué sans discernement à toutes les images, y compris celle qui sera l'élément LCP. Le navigateur la découvre, attend, puis déclenche le chargement tardivement. Résultat : un LCP dégradé sur une image qui était pourtant prioritaire.
Autre piège courant : l'image hero servie via CSS background-image. Le navigateur ne peut pas précharger une image déclarée en CSS aussi efficacement qu'une balise <img>. Si l'élément LCP de votre page est un background CSS, vous limitez structurellement vos possibilités d'optimisation.
Notre avis : RECOMMANDÉ avec méthode
Le LCP est la métrique la plus actionnable des trois. Les gains sont souvent spectaculaires pour un effort limité. Mais attention : identifier le bon élément LCP requiert de tester sur mobile en conditions réseau réelles, pas sur un écran 4K avec une fibre 1 Gb. L'élément LCP mobile est rarement le même qu'en desktop. Traiter l'un sans l'autre fausse toute l'analyse.
INP (Interaction to Next Paint) : le successeur de FID qui change tout
INP — Interaction to Next Paint
Délai entre une interaction utilisateur (clic, toucher, saisie clavier) et la prochaine mise à jour visuelle de la page. Remplace FID depuis mars 2024.
< 200 ms
Bon
< 500 ms
À améliorer
≥ 500 ms
Mauvais
Différence clé avec FID : FID mesurait le délai avant la première interaction seulement. INP mesure toutes les interactions sur toute la session.
Causes fréquentes : thread principal bloqué, scripts tiers lourds, gestionnaires d'événements non optimisés
Levier prioritaire : découpage des tâches longues (> 50 ms),
defer ou async sur les scripts tiers, utilisation de scheduler.postTask()FID mesurait uniquement le délai avant la première interaction sur la page. Un site pouvait avoir un FID parfait tout en étant totalement gelé lors d'une navigation dans un menu ou d'un filtre produit. C'est exactement ce problème qu'INP corrige. INP capture la pire interaction observée sur l'ensemble de la session, au 98e percentile des données terrain.
Cette évolution est sévère pour les sites riches en JavaScript. Un composant de filtre de recherche qui met 700 ms à répondre visuellement après un clic est désormais mesuré et signalé. Avant mars 2024, ce type d'interaction n'entrait pas dans le calcul. Des sites qui se croyaient conformes ont découvert un INP rouge dans leur Search Console sans avoir rien changé sur leur site.
La distinction entre délai d'entrée, durée de traitement et délai de présentation est au cœur du diagnostic INP. Le délai d'entrée (temps d'attente avant que le navigateur commence à traiter l'interaction) est souvent la part la plus longue, et elle est directement liée à l'occupation du thread principal par d'autres tâches.
Notre avis : À SURVEILLER EN PRIORITÉ sur les sites à forte interactivité
INP est la métrique qui va surprendre le plus d'équipes dans les mois à venir. Les sites e-commerce avec filtres dynamiques, les SaaS avec interfaces riches, et les sites utilisant des CMS JavaScript sont particulièrement exposés. Un INP mauvais n'est pas toujours visible à l'oeil nu : l'interface semble répondre, mais avec un délai imperceptible pour l'humain, parfaitement perceptible pour Google.
CLS (Cumulative Layout Shift) : l'ennemi silencieux de l'UX
CLS — Cumulative Layout Shift
Score mesurant l'instabilité visuelle de la page : somme de tous les décalages de mise en page inattendus pendant le chargement et la navigation.
< 0,1
Bon
< 0,25
À améliorer
≥ 0,25
Mauvais
Éléments déclencheurs : images sans dimensions, iframes publicitaires, polices web avec FOUT, bandeau cookies sans espace réservé
Particularité : le CLS est cumulatif sur toute la durée de la session, y compris les interactions utilisateur
Levier prioritaire : attributs
width et height sur toutes les images, aspect-ratio en CSS, font-display: optional pour les polices critiquesLe CLS est le seul des trois Core Web Vitals qui n'est pas une mesure de temps. C'est un score de stabilité. Il se calcule en multipliant la fraction d'impact (quelle part du viewport est affectée) par la fraction de distance (de combien l'élément s'est déplacé). Un score de 0 signifie que rien ne bouge. Un score de 1 signifie que tout le viewport a été déplacé sur toute sa hauteur.
La source de CLS la plus sous-estimée : les polices web chargées sans stratégie définie. Quand le navigateur affiche d'abord une police système puis la remplace par la police web, le texte change de taille et repousse les éléments adjacents. Ce phénomène, appelé FOUT (Flash of Unstyled Text), génère un CLS mesurable que beaucoup d'équipes n'associent pas à la performance Web.
Depuis 2022, Google a modifié le calcul du CLS pour les pages à navigation longue. Les décalages générés par les interactions utilisateur (scroll, clic) sont désormais séparés des décalages non sollicités. Cette nuance est importante : un accordéon qui s'ouvre et repousse le contenu n'est plus pénalisé de la même façon qu'une pub qui se charge soudainement.
Notre avis : RECOMMANDÉ comme premier chantier sur les sites avec publicité ou polices web
Le CLS est souvent le levier le plus rapide à traiter et le plus rentable en termes de qualité perçue. Un utilisateur qui voit le contenu sauter sous ses yeux abandonne. Ce n'est pas une métrique abstraite : c'est la traduction chiffrée d'une frustration réelle. Et contrairement au LCP, les corrections CLS ne nécessitent généralement pas de refonte d'architecture.
Voici un tableau de synthèse des trois métriques pour avoir une vue d'ensemble avant de passer aux outils de mesure.
| Métrique | Ce qu'elle mesure | Seuil Good | Cause principale | Levier prioritaire |
|---|---|---|---|---|
| LCP | Vitesse d'affichage du plus grand élément visible | < 2,5 s | Lazy-load sur l'image hero, serveur lent | fetchpriority="high", suppression du lazy-load hero |
| INP | Réactivité aux interactions tout au long de la session | < 200 ms | Thread principal bloqué par des scripts tiers | Découpage des tâches longues, scripts en defer |
| CLS | Stabilité visuelle de la mise en page | < 0,1 | Images sans dimensions, polices web, publicités | Attributs width/height, font-display: optional |
Aucune de ces trois métriques ne se compense avec une autre. Google exige que les trois soient dans le vert pour considérer une URL comme ayant une bonne expérience de page. Passons maintenant à la question qui piège le plus d'équipes : comment les mesurer correctement.
Les outils pour mesurer vos Core Web Vitals sans se tromper de source
Mesurer ses Core Web Vitals avec le mauvais outil, c'est optimiser pour une réalité qui n'existe pas. Cette confusion est la source de la grande majorité des déceptions post-optimisation.
Données terrain vs données laboratoire : la distinction que 80 % des équipes ratent
Les données de laboratoire (lab data) simulent une visite dans des conditions contrôlées : un appareil fictif, une connexion normalisée, un navigateur vierge. C'est ce que produit Lighthouse, que ce soit via PageSpeed Insights ou Chrome DevTools. Ces données sont reproductibles et utiles pour le débogage. Elles ne reflètent pas ce que vivent vos visiteurs réels.
Les données terrain (field data), aussi appelées données réelles, proviennent du Chrome UX Report (CrUX). Ce dataset agrège les performances mesurées sur les visites réelles d'utilisateurs Chrome sur votre site, au cours des 28 derniers jours. C'est cette source que Google utilise pour évaluer vos Core Web Vitals dans le cadre du classement. Un score Lighthouse de 95 ne vous protège pas d'un CrUX rouge.
La conséquence pratique : si votre Search Console indique un LCP "Mauvais" sur des URLs précises, c'est sur ces données terrain qu'il faut agir. PageSpeed Insights vous donne les deux sources superposées, ce qui permet d'identifier les écarts. Un écart important entre lab et terrain signale souvent des scripts tiers ou des contenus dynamiques invisibles au test de laboratoire.
PageSpeed Insights, Search Console, Web Vitals extension : quel outil pour quoi faire
Chaque outil a un rôle précis dans le workflow d'optimisation des Core Web Vitals. Les utiliser dans le bon ordre évite de perdre du temps sur des faux positifs.
La Search Console (rapport Signaux Web) est votre point d'entrée. Elle agrège les données CrUX par groupe d'URLs et signale les pages "Mauvaises" ou "À améliorer". C'est ici que vous priorisez les chantiers. Limitation : elle ne donne pas les valeurs exactes par URL, seulement des groupes et des statuts.
PageSpeed Insights analyse une URL précise et fournit à la fois les données terrain CrUX (si disponibles) et les données lab Lighthouse. C'est l'outil de diagnostic par URL. Il identifie quel élément est le LCP, quelles tâches bloquent l'INP, quels éléments génèrent du CLS.
La Web Vitals extension Chrome mesure vos métriques en temps réel pendant votre navigation sur le site, dans votre propre contexte de navigateur. Utile pour reproduire un problème INP sur une interaction spécifique. À utiliser pour valider un correctif avant de le pousser en production.
Google Analytics 4 peut également collecter des données Web Vitals via l'API web-vitals.js, pour croiser performance et comportement utilisateur (taux de rebond, conversions par segment de performance). C'est une couche d'analyse avancée, pas un outil de diagnostic.
Le workflow recommandé : Search Console pour prioriser, PageSpeed Insights pour diagnostiquer, Web Vitals extension pour valider. Utiliser ces outils dans cet ordre évite de corriger des URLs sans impact sur les données terrain qui comptent pour Google.
Le Piège du Score Vert
Voici un phénomène que nous observons régulièrement en audit et qui n'a pas encore de nom dans la littérature SEO. Nous l'appelons le Piège du Score Vert.
Comprendre le piège des Core Web Vitals
En tant que développeur senior, nous sommes facilement victime du Piège du Score Vert. Sous ce nom étrange, il est question d'une situation dans laquelle une équipe optimise son score PageSpeed Lighthouse jusqu'à 90 ou 100, considère le sujet des Core Web Vitals comme traité, et découvre plusieurs semaines plus tard que ses données terrain dans la Search Console restent rouges ou oranges.
Le temps et les ressources investis dans l'optimisation du score lab ne produisent aucun effet sur le classement si les données CrUX ne s'améliorent pas.
Pire. l'équipe développe une fausse confiance qui retarde le vrai diagnostic de plusieurs mois. Sur un site e-commerce, chaque semaine de sous-performance CWV a un coût mesuré en taux de conversion.
Éviter ce problème piège dans votre workflow
Pour éviter de tomber dans le panneau, comparez dans PageSpeed Insights la section "Données de terrain" (CrUX) avec la section "Diagnostics Lighthouse". Si les valeurs terrain sont significativement plus mauvaises que les valeurs lab, vous êtes dans le Piège du Score Vert. Vérifiez aussi dans la Search Console si des URLs marquées "BAD" correspondent à des pages que vous croyez optimisées.
Définir comme KPI principal les données CrUX, pas le score Lighthouse. Documenter les valeurs terrain avant et après chaque optimisation. Attendre un cycle CrUX complet (28 jours) avant de valider qu'une correction a eu l'effet attendu sur les données réelles.
Optimisations concrètes par métrique : le Protocole LIC
Nous proposons ici une méthodologie structurée en trois étapes pour aborder l'optimisation des Core Web Vitals dans un ordre logique de priorité et d'impact. Ce n'est pas un standard de l'industrie : c'est une transmission pédagogique issue de nos audits terrain.
Le Protocole LIC (Largest, Interactivité, Cumul) suit l'ordre dans lequel les métriques impactent la perception utilisateur :
Étape 1 : Améliorez le LCP
Tout d'abord notre expertise nous montre qu'il faut avant tout accélérer l'élément LCP. Commencez ainsi par ouvrir PageSpeed Insights sur votre page principale.
Identifiez l'élément LCP dans la section "Diagnostics". Si c'est une image, assurez-vous qu'elle est servie en balise <img> (pas en CSS background), que l'attribut loading="lazy" est absent, et ajoutez fetchpriority="high". Si votre image est hébergée sur un CDN externe, ajoutez une directive de préconnexion dans le <head>.
PageSpeed Insights données lab, attention, ce ne sont pas des données terrain CrUX pour les Core Web Vitals
Astuce de Pro : VOTRE SITE NE SE RÉSUME PAS À SA HOMEPAGE
Nombreux sont les développeurs qui se concentre sur l'optimisation technique de la page principale. N'oubliez pas que votre site exploite en général plusieur type de vues ou de template selon la typologie (et la finalité !) des pages.
Ainsi la home n'aura pas les mêmes composants, qu'une catégorie, qu'une landing page, ou qu'un article de blog. Si les performances sont un critère pour vous (ndlr: et ce sera le cas dès que votre GSC ne parvient plus à indexer 100% de votre sitemap.xml) : vérifiez bien les Core Web Vitals de chacun de vos templates !
Étape 2 : Déroulez une session de navigation
Ici, on va réduire la pression sur le thread principal. Pour ce faire, nous allons auditer le chargement d'une page web de votre site en enregistrant une sessions directement dans les outils de debug de votre navigateur Internet.
Pour l'exemple, nous allons lancer les DevTools sur Google Chrome. Vous pouvez l'ouvrir avec le raccourci F12 puis vous diriger vers l'onglet Performance.
Google Chrome (DevTools) : vu comme ça, ça paraît très compliqué, mais en réalité c'est accessible, pas de panique.
Enregistrez une session de navigation et laissez la page se charger entièrement. Vous pourrez ensuite identifier les tâches longues (blocs rouges au-dessus de la timeline). Les tâches de plus de 50 ms bloquent le thread et dégradent l'INP. Auditez les scripts tiers chargés au démarrage. Un script de chat, un pixel publicitaire ou un tag manager mal configuré peut à lui seul générer plusieurs centaines de millisecondes de blocage.
Étape 3 : Ne laissez rien au hasard (Dev only)
Figer les espaces avant le chargement des ressources. Pour chaque image dans votre HTML, ajoutez les attributs width et height correspondant aux dimensions réelles affichées. Pour les iframes publicitaires ou de vidéo, définissez un espace réservé via aspect-ratio en CSS. Pour vos polices web, utilisez font-display: swap ou, mieux, font-display: optional pour éviter tout décalage.
Voici les blocs de code pour les interventions les plus fréquentes :
<!-- Étape 1 : optimisation LCP image hero -->
<img
src="hero.jpg"
alt="Description de l'image principale"
width="1200"
height="600"
fetchpriority="high"
>
<!-- Préconnexion CDN dans le head -->
<link rel="preconnect" href="https://cdn.exemple.com">
<link rel="dns-prefetch" href="https://cdn.exemple.com"> /* Étape 3 : espace réservé pour iframe vidéo (CLS) */
.video-wrapper {
aspect-ratio: 16 / 9;
width: 100%;
overflow: hidden;
}
/* Police web sans décalage */
@font-face {
font-family: 'MaPolice';
src: url('mapolice.woff2') format('woff2');
font-display: optional;
} Aidez-moi à appliquer le Protocole LIC sur mon site Preuves de terrain et limites à connaître
En 2025, une analyse du rapport CrUX Technology Report publiée par l'équipe Chrome a montré que les sites WordPress non optimisés présentent un taux de passage "Good" sur le LCP inférieur de 15 points à la médiane globale. Ce n'est pas une fatalité liée au CMS, mais à des thèmes chargés sans optimisation des images critiques.
John Mueller (Google Search Relations) a rappelé à plusieurs reprises que les Core Web Vitals sont un signal de départage, pas un multiplicateur. Sur une requête très compétitive, deux pages avec un contenu équivalent verront la mieux notée sur les CWV l'emporter. Sur une requête peu concurrentielle, un site avec un CLS catastrophique peut tout à fait se maintenir en première position grâce à la pertinence de son contenu.
La limite honnête de cette approche : améliorer ses Core Web Vitals ne remplace pas une stratégie de contenu solide ni un profil de liens de qualité. Les CWV sont une condition nécessaire à la compétitivité sur les requêtes disputées, pas une condition suffisante. Un site avec un score LCP parfait et un contenu pauvre n'a aucune chance face à un concurrent avec un contenu exhaustif et un LCP légèrement sous-optimal.
Questions/FAQ sur les Core Web Vitals :
Les Core Web Vitals sont-ils un facteur de classement direct pour Google ?
Oui, mais avec des nuances importantes. Google les a intégrés comme signal de classement dans le cadre du Page Experience Update depuis 2021. Ils agissent comme un facteur de départage entre pages de pertinence équivalente. Ils ne compensent pas un contenu faible et n'effacent pas un déficit de backlinks. Sur les requêtes très compétitives, ils peuvent faire la différence entre la position 3 et la position 6.
FID a-t-il vraiment été supprimé et remplacé par INP ?
Oui, officiellement depuis mars 2024. Le First Input Delay (FID) ne fait plus partie des Core Web Vitals officiels. Il est remplacé par l'Interaction to Next Paint (INP). La différence fondamentale : FID mesurait uniquement le délai avant la première interaction sur la page. INP mesure la réactivité sur toutes les interactions tout au long de la session, au 98e percentile. C'est structurellement plus exigeant.
Faut-il cibler un score PageSpeed de 100 pour avoir de bons Core Web Vitals ?
Non. C'est précisément le Piège du Score Vert. Google utilise les données terrain du Chrome UX Report (CrUX) pour évaluer vos Core Web Vitals, pas le score Lighthouse. Un site peut avoir 100 en lab et rater ses métriques terrain. L'objectif est d'obtenir LCP, INP et CLS dans le vert dans le rapport Signaux Web de la Search Console, indépendamment du score PageSpeed.
Ce que ce cours ne couvre pas encore
Les trois actions à retenir de ce cours sont claires. Identifier la métrique rouge dans vos données CrUX via la Search Console. Diagnostiquer la cause racine avec PageSpeed Insights sur l'URL concernée. Appliquer le correctif ciblé et valider après un cycle de 28 jours.
Ce cours ne couvre pas l'optimisation du Time to First Byte (TTFB), qui conditionne le LCP en amont et relève de l'infrastructure serveur, du cache et du CDN. Il ne traite pas non plus de l'optimisation JavaScript avancée pour les frameworks modernes comme Next.js ou Nuxt, où les problèmes d'INP prennent une forme différente liée au rendu côté client.
Les signaux utilisateurs au sens large, taux de rebond, temps passé, profondeur de scroll, sont le prolongement naturel des Core Web Vitals dans la logique de Google. Une bonne expérience technique sans engagement réel ne suffit pas. Si vous voulez aller plus loin sur la façon dont Google interprète ces signaux comportementaux dans son algorithme de classement, la prochaine étape logique est là.
Si vous voulez auditer vos Core Web Vitals et identifier précisément les pages qui freinent votre visibilité, nous pouvons en parler ensemble pendant 20min ?