Core Web Vitals : LCP, INP, CLS — ce que Google mesure vraiment
Pas des métriques de labo, des mesures sur vos vrais utilisateurs. Voici ce que chaque signal signifie, pourquoi il compte et comment l'améliorer.
- Les Core Web Vitals mesurent l'expérience de vos vrais utilisateurs — pas un scénario de laboratoire. C'est la différence fondamentale avec le score PageSpeed.
- INP a remplacé FID en mars 2024. Si vous parlez encore de FID, votre information est périmée.
- Les CWV sont un signal de classement Google, mais pas le seul. Un contenu de qualité avec des CWV corrects battra toujours un site ultra-optimisé avec du contenu médiocre.
Quand on parle de performance web et de SEO, les Core Web Vitals (CWV) sont souvent mentionnés mais rarement bien compris. La plupart des propriétaires de sites WordPress les confondent avec le score PageSpeed Insights. Ce sont deux choses différentes.
Les Core Web Vitals sont des métriques qui mesurent l'expérience réelle de vos visiteurs. Pas une simulation dans un environnement contrôlé — vos vrais utilisateurs, sur leurs vrais appareils, avec leurs vraies connexions.
Ce guide démystifie les trois métriques : LCP, INP et CLS. On va voir ce que chacune mesure exactement, quels sont les seuils à connaître, pourquoi elles ont été créées et comment vous pouvez les améliorer concrètement.
L'origine des Core Web Vitals : pourquoi Google les a créés
Avant 2020, Google utilisait des métriques techniques disparates pour évaluer l'expérience utilisateur : First Contentful Paint, Speed Index, Time to Interactive... Utiles, mais difficiles à interpréter et souvent déconnectées de ce que l'utilisateur perçoit vraiment.
En mai 2020, Google a lancé les Core Web Vitals : un ensemble de trois métriques standardisées, centrées sur trois dimensions fondamentales de l'expérience : le chargement, l'interactivité et la stabilité visuelle.
Ces métriques sont collectées via le Chrome UX Report (CrUX), qui agrège des données anonymisées de vrais utilisateurs Chrome sur les 28 derniers jours. Quand votre site a suffisamment de trafic Chrome, vous disposez d'un miroir fidèle de l'expérience réelle.
Depuis juin 2021, les Core Web Vitals font partie des signaux de classement Google via la mise à jour "Page Experience". Ce n'est pas le seul signal — le contenu reste roi — mais c'est le seul directement lié à l'expérience technique de vos visiteurs.
LCP — Largest Contentful Paint : la vitesse perçue
LCP — Largest Contentful Paint : la vitesse perçue
Le LCP mesure le temps nécessaire pour afficher le plus grand élément visible de la page dans la zone d'affichage. En pratique, il s'agit le plus souvent d'une image héro, d'une grande photo, ou d'un titre principal.
C'est la métrique qui correspond le mieux à la perception utilisateur de "la page est chargée". Ce n'est pas quand le premier pixel s'affiche (FCP), ni quand tout est entièrement interactif (TTI) — c'est quand le contenu principal est visible.
Seuils LCP
- Bon : moins de 2,5 secondes
- À améliorer : entre 2,5 et 4 secondes
- Critique : plus de 4 secondes
Causes fréquentes d'un LCP dégradé
- Serveur lent (TTFB élevé) : si le serveur met 2 secondes à répondre, le LCP ne peut pas être bon. C'est le premier goulot d'étranglement à corriger.
- Images non optimisées : une image héro non compressée, en format JPEG/PNG au lieu de WebP, sans dimensionnement correct est souvent la cause principale.
- Ressources bloquant le rendu : CSS et JavaScript chargés en synchrone qui retardent l'affichage du contenu.
- Rendu côté client (CSR) : les sites construits avec des frameworks JavaScript comme React ou Vue en mode CSR doivent exécuter le JS avant d'afficher quoi que ce soit.
INP — Interaction to Next Paint : la réactivité réelle
INP — Interaction to Next Paint : la réactivité réelle
L'INP (Interaction to Next Paint) a officiellement remplacé le FID (First Input Delay) en mars 2024. C'est le changement le plus important dans les Core Web Vitals depuis leur lancement.
Là où le FID ne mesurait que le délai de la toute première interaction, l'INP mesure la latence de toutes les interactions tout au long de la session : clics, tapotements, frappes au clavier. Il retient le 98e percentile — ce qui signifie qu'une seule interaction lente peut suffire à dégrader le score.
En pratique, l'INP mesure le temps entre le moment où l'utilisateur interagit (clic, tap, touche) et le moment où le navigateur affiche la prochaine mise à jour visuelle. C'est la réactivité perçue.
Seuils INP
- Bon : moins de 200 millisecondes
- À améliorer : entre 200 et 500 millisecondes
- Critique : plus de 500 millisecondes
Causes fréquentes d'un INP dégradé
- JavaScript lourd sur le thread principal : des calculs longs, des boucles complexes ou des opérations de rendu DOM excessives bloquent le thread et retardent la réponse.
- Tâches longues (Long Tasks) : toute tâche JS qui s'exécute plus de 50 ms sur le thread principal est considérée comme longue et peut affecter l'INP.
- Scripts tiers : analytics, chatbots, publicités, plugins de réseaux sociaux — chaque script tiers ajoute de la charge sur le thread principal.
- Gestionnaires d'événements lourds : des event listeners qui déclenchent des recalculs de style ou des repaints complexes à chaque interaction.
CLS — Cumulative Layout Shift : la stabilité visuelle
CLS — Cumulative Layout Shift : la stabilité visuelle
Le CLS mesure la stabilité visuelle de la page pendant son chargement. Il quantifie à quel point les éléments bougent de façon inattendue — ce phénomène frustrant où vous allez cliquer sur un bouton et le contenu se décale juste avant votre clic.
Techniquement, le CLS est le produit de la fraction d'impact (quelle portion de l'écran a bougé) par la fraction de distance (de combien l'élément s'est déplacé). C'est une valeur sans unité, et non un temps.
Depuis 2021, Google a affiné la mesure du CLS pour utiliser les "session windows" : il ne mesure plus la somme de tous les décalages, mais le pire groupe de décalages qui se produisent dans un intervalle de 1 seconde, séparés d'au moins 5 secondes.
Seuils CLS
- Bon : moins de 0,1
- À améliorer : entre 0,1 et 0,25
- Critique : plus de 0,25
Causes fréquentes d'un CLS dégradé
- Images sans dimensions : si les balises <img> n'ont pas d'attributs width et height, le navigateur ne réserve pas d'espace et le contenu se décale quand l'image se charge.
- Contenu injecté dynamiquement : bannières de cookies, pop-ups, publicités chargées après le rendu initial qui poussent le contenu vers le bas.
- Polices web (FOUT/FOIT) : quand une police web se charge et remplace la police de substitution, le changement de métrique peut décaler le texte et les éléments environnants.
- Animations et transitions CSS non optimisées : utiliser transform et opacity au lieu de top/left/width/height pour les animations évite les recalculs de layout.
Comment mesurer vos Core Web Vitals
Il existe deux catégories d'outils pour mesurer les CWV : les outils de terrain (données réelles) et les outils de laboratoire (simulation). Pour le SEO, ce sont les données de terrain qui comptent — mais les outils de labo sont indispensables pour le diagnostic.
- Google Search Console : onglet "Expérience de page" — affiche vos CWV agrégés par URL et par catégorie (mobile/desktop). C'est la source officielle utilisée par Google pour le classement.
- PageSpeed Insights (section "Données terrain") : affiche les CWV des 28 derniers jours pour une URL spécifique si le trafic est suffisant.
- CrUX Dashboard (Looker Studio) : tableau de bord officiel Google qui visualise l'évolution de vos CWV dans le temps. Très utile pour suivre l'impact de vos optimisations.
- Chrome DevTools (onglet Performance / Lighthouse) : audit local avec les métriques CWV simulées. Idéal pour diagnostiquer les problèmes avant déploiement.
- PageSpeed Insights (section "Données lab") : Lighthouse hébergé par Google. Pratique mais les valeurs diffèrent des données terrain.
- Bibliothèque web-vitals JS : intégrez-la dans votre code pour mesurer les CWV réels de vos visiteurs et les envoyer à votre propre analytics.
Comment Orilyt intègre les Core Web Vitals
Orilyt utilise les données de l'API PageSpeed Insights pour nourrir trois tests critiques dans chaque audit. Ces tests sont directement liés aux facteurs qui influencent vos Core Web Vitals.
- Test #01 — TTFB (Time to First Byte) : mesure le temps de réponse du serveur. Un TTFB supérieur à 800 ms est le premier ennemi du LCP. Si le serveur est lent, rien d'autre ne peut compenser.
- Test #02 — Poids de page : analyse le poids total des ressources chargées. Des images lourdes et non optimisées sont la première cause d'un LCP dégradé sur WordPress.
- Test #03 — Mobile Friendly : vérifie que le site est correctement adapté aux mobiles. Les CWV sont mesurés séparément sur mobile et desktop — et c'est la version mobile qui pèse le plus dans le classement.
Chaque test inclut une recommandation FIA (Fait, Impact, Action) : un constat factuel tiré des données, son impact sur l'expérience utilisateur et le SEO, et une action corrective concrète. C'est ce qui transforme un score abstrait en argument de vente pour vos clients.
CWV en 2026 : un signal qui dure
Les Core Web Vitals sont devenus un standard de l'industrie web. Même au-delà du SEO, ils représentent les trois dimensions fondamentales d'une bonne expérience : est-ce que ça charge vite, est-ce que ça réagit vite, est-ce que c'est stable ?
Pour les freelances et les agences web, maîtriser les CWV est un avantage compétitif réel. C'est une façon de parler de performance en termes d'expérience utilisateur plutôt qu'en chiffres techniques. Vos clients comprennent "votre site se décale quand il charge" mieux que "votre CLS est à 0,28".
Orilyt vous donne les données nécessaires pour avoir cette conversation. Chaque audit intègre les métriques PageSpeed avec des recommandations prêtes à présenter — sans avoir à décrypter vous-même les rapports Lighthouse ou Search Console.