Core Web Vitals : LCP, INP, CLS — le guide complet
Qu'est-ce que les Core Web Vitals ?
Les Core Web Vitals sont 3 métriques définies par Google qui mesurent l'expérience perçue par l'utilisateur sur une page web. Elles sont intégrées à l'algorithme de classement depuis mai 2021 (Page Experience Update) et mesurées sur le terrain réel via les Chrome User Experience Reports (CrUX).
| Métrique | Abbréviation | Seuil « bon » | Seuil « médiocre » | Ce que ça mesure |
|---|---|---|---|---|
| Largest Contentful Paint | LCP | ≤ 2,5 s | ≥ 4,0 s | Temps d'affichage du plus grand élément |
| Interaction to Next Paint | INP | ≤ 200 ms | ≥ 500 ms | Latence perçue lors d'une interaction |
| Cumulative Layout Shift | CLS | ≤ 0,1 | ≥ 0,25 | Stabilité visuelle (décalages de mise en page) |
Les valeurs sont calculées sur le percentile 75 des sessions (mobile + desktop combinés) sur 28 jours glissants. Une page est « bonne » si 75 % des visites sont sous le seuil « bon ».
LCP : Largest Contentful Paint
Le LCP mesure le temps entre le début du chargement de la page et l'affichage du plus grand élément de contenu dans le viewport : une image hero, un bloc de texte principal, une vidéo, un bloc <div> avec du texte.
Causes fréquentes d'un LCP élevé
| Cause | Impact typique | Correction |
|---|---|---|
| TTFB élevé (serveur lent) | +1 à 3 s | Hébergement performant, CDN, cache PHP (OPcache), HTTP/2 ou HTTP/3 |
| Image hero non optimisée | +1 à 4 s | WebP/AVIF, dimensions correctes, fetchpriority="high" |
| CSS/JS bloquant le rendu | +0,5 à 2 s | Minification, defer sur les scripts, CSS critique inline |
| Redirections en chaîne | +0,3 à 1 s | Supprimer les hops intermédiaires |
| Font loading lent | +0,5 à 1,5 s | font-display: swap, préchargement de la police, sous-ensemble de glyphes |
Optimisations à fort impact
- Précharger l'élément LCP :
<link rel="preload" as="image" href="hero.webp">dans le<head>. - Réduire le TTFB : viser < 800 ms. CDN (Cloudflare, Bunny), cache page (Varnish, LiteSpeed), OPcache PHP.
- Optimiser l'image hero : format AVIF (meilleur ratio qualité/poids), taille adaptée au viewport, pas de lazy loading sur l'image LCP.
- Éliminer les ressources bloquantes :
<script defer>, CSS critique inline, le reste enmedia="print" onload".
INP : Interaction to Next Paint
L'INP (introduit en mars 2024 en remplacement de FID) mesure la latence perçue lors de toutes les interactions de la session : clics, taps, appuis sur les touches du clavier. C'est la pire latence d'interaction de la session (pas la moyenne) qui est retenue.
Causes fréquentes d'un INP élevé
| Cause | Impact typique | Correction |
|---|---|---|
| Script JS long qui bloque le main thread | +100 à 500 ms | Fractionner en chunks, requestIdleCallback, Web Workers |
| Manipulation DOM lourde au clic | +50 à 300 ms | Différer les mises à jour DOM, requestAnimationFrame |
| Librairie tierce (analytics, chat, A/B test) | +50 à 200 ms | Charger après le LCP, defer, ou remplacer par une solution plus légère |
| Long tasks > 50 ms | +50 à 400 ms | Identifier via Performance Panel (Chrome DevTools), découper |
Optimisations à fort impact
- Identifier les long tasks : Chrome DevTools → Performance → chercher les tâches > 50 ms sur le main thread.
- Différer le JS non critique :
<script defer>outype="module"(implicitement defer). - Utiliser
requestIdleCallbackpour les tâches non urgentes (analytics, pré-chargement, tracking). - Externaliser les calculs lourds : Web Workers pour le traitement de données, le rendu de graphiques.
- Limiter les librairies tierces : chaque script de tracking ou de chat ajoute de la latence. N'en garder que 2-3 maximum.
CLS : Cumulative Layout Shift
Le CLS mesure l'instabilité visuelle d'une page : la somme des décalages non intentionnels d'éléments pendant le chargement. Un CLS élevé signifie que l'utilisateur clique sur un bouton qui « saute » avant d'arriver sous le curseur — source de frustration et de clics erronés.
Causes fréquentes d'un CLS élevé
| Cause | Impact typique | Correction |
|---|---|---|
| Images sans dimensions (width/height) | 0,1 à 0,4 | Toujours définir width et height (ou aspect-ratio en CSS) |
| Publicités / bannières insérées dynamiquement | 0,1 à 0,5 | Réserver un espace fixe (min-height) avant le chargement |
| Polices web qui chargent tard (FOUT) | 0,05 à 0,2 | font-display: swap + préchargement, ou size-adjust |
| Contenu injecté au-dessus du fold | 0,1 à 0,3 | Éviter les popups, bannières cookies qui poussent le contenu |
Éléments position: fixed qui apparaissent | 0,05 à 0,15 | Prévoir l'espace dans le layout initial |
Optimisations à fort impact
- Dimensions explicites sur toutes les images et vidéos :
<img src="…" width="800" height="450">oustyle="aspect-ratio: 16/9". - Réserver l'espace pour les publicités, les embeds (YouTube, Instagram) et les bannières :
div.ad-slot { min-height: 250px; }. - Précharger les polices critiques :
<link rel="preload" as="font" type="font/woff2" crossorigin href="…">. - Éviter les insertions au-dessus du fold : les bannières cookies doivent être en
position: fixedoustickyen bas, pas en insertion dans le flux.
Comment Google mesure : terrain vs labo
Il existe 2 types de données, et seule la première compte pour le classement :
| Type | Source | Période | Compte pour le ranking ? |
|---|---|---|---|
| Field data (terrain) | Chrome User Experience Reports (CrUX) — utilisateurs réels de Chrome | 28 jours glissants, percentile 75 | Oui |
| Lab data (labo) | PageSpeed Insights, Lighthouse, WebPageTest — simulation sur appareil standard | Instantané | Non (diagnostic uniquement) |
Implication pratique : un score Lighthouse à 100/100 ne garantit pas de bons Core Web Vitals terrain. Si vos utilisateurs réels (mobile, réseau 3G/4G, appareils bas de gamme) ont un LCP de 4 s, c'est ce chiffre qui compte. Le labo sert à diagnostiquer, le terrain à mesurer.
Seuil de qualification : Google ne calcule les CWV terrain que si la page a au moins 100 sessions CrUX sur 28 jours (ou 20 % des sessions du site si c'est moins). Sur un petit site en construction, les données terrain peuvent être indisponibles — dans ce cas, Google n'applique pas la pénalité (mais ne donne pas de bonus non plus).
Impact sur le classement
Les Core Web Vitals sont un facteur de classement parmi d'autres, pas un facteur dominant. L'impact réel :
- Sur les requêtes à forte concurrence (top 100 mots-clés) : un écart de CWV peut faire la différence entre la position 8 et la position 12. C'est un tiebreaker.
- Sur les requêtes à faible concurrence (longue traîne) : l'impact est négligeable. Le contenu et les backlinks priment.
- Sur le CTR : un site lent a un taux de rebond 32 % plus élevé au-delà de 3 s (Google, 2016). L'impact indirect sur l'engagement est plus fort que l'impact direct sur le classement.
- Sur le GEO : les IA ne « mesurent » pas les CWV, mais un site lent est moins bien indexé (timeout du crawler) et moins cité (l'utilisateur qui clique sur la source part avant que la page ne charge → signal négatif).
Plan d'optimisation par métrique
Si le LCP est mauvais (> 2,5 s)
- Vérifier le TTFB dans GSC (onglet CWV → colonne TTFB). Si > 800 ms → problème serveur/CDN.
- Identifier l'élément LCP (PageSpeed Insights → « LCP » → élément en surbrillance).
- Optimiser cet élément : image → WebP/AVIF + preload ; texte → CSS critique inline ; vidéo → poster image + lazy load.
- Supprimer les redirections avant la page cible.
Si l'INP est mauvais (> 200 ms)
- Ouvrir Chrome DevTools → Performance → enregistrer une session d'interaction (clics, scroll).
- Identifier les long tasks (> 50 ms) sur le main thread.
- Pour chaque long task : fractionner, différer, ou externaliser (Web Worker).
- Auditer les scripts tierces : supprimer ou différer ceux qui ne sont pas critiques.
Si le CLS est mauvais (> 0,1)
- Ouvrir Chrome DevTools → Performance → onglet « Layout Shift » (ou PageSpeed Insights → « CLS »).
- Identifier les éléments qui causent le shift (image sans dimensions, popup, police).
- Corriger : ajouter width/height, réserver l'espace, précharger la police.
Outils de diagnostic
| Outil | Type | Usage |
|---|---|---|
| Google Search Console → Améliorations → Core Web Vitals | Terrain | Vue d'ensemble par page, tendance 28 j, filtre mobile/desktop |
| PageSpeed Insights (pagespeed.web.dev) | Labo + Terrain | Diagnostic page par page, éléments LCP/CLS identifiés, suggestions |
| Chrome DevTools → Performance | Labo (local) | Long tasks, layout shifts, TTFB, waterfall de chargement |
| CrUX Dashboard (cruxdashboard.org) | Terrain | Données brutes CrUX, comparatif entre domaines |
| WebPageTest (webpagetest.org) | Labo (multi-geo) | Test depuis différentes localisations (Paris, New York, Tokyo), vidéo du chargement |
| Lighthouse (intégré à DevTools) | Labo | Score global 0-100, audit détaillé (accessibilité, SEO, PWA) |
Workflow recommandé : GSC pour identifier les pages à problème → PageSpeed Insights pour le diagnostic détaillé → Chrome DevTools pour l'investigation fine (long tasks, layout shifts) → re-tester dans GSC après correction (attendre 28 jours pour le terrain).
Checklist Core Web Vitals
| # | Point de contrôle | Statut |
|---|---|---|
| 1 | LCP ≤ 2,5 s sur mobile (GSC, percentile 75) | ☐ |
| 2 | INP ≤ 200 ms sur mobile | ☐ |
| 3 | CLS ≤ 0,1 sur mobile | ☐ |
| 4 | TTFB < 800 ms (CDN + cache actif) | ☐ |
| 5 | Image hero en WebP/AVIF avec preload | ☐ |
| 6 | Toutes les images ont width/height (ou aspect-ratio) | ☐ |
| 7 | Pas de long task > 50 ms sur le main thread | ☐ |
| 8 | Scripts tierces : max 2-3, chargées en defer | ☐ |
| 9 | Polices : font-display: swap + preload | ☐ |
| 10 | Pas d'insertion de contenu au-dessus du fold (bannières, popups) | ☐ |
| 11 | Espace réservé pour les publicités / embeds | ☐ |
| 12 | GSC : onglet CWV vérifié mensuellement | ☐ |
Pour le contexte plus large, voir notre page SEO technique. Pour la vitesse de chargement en général, voir Vitesse de chargement. Pour la vue d'ensemble, voir le guide complet du SEO.
Débloquez vos Core Web Vitals
Audit SEO gratuit : nous analysons vos LCP, INP et CLS sur les 5 pages clés et vous livrons un plan d'optimisation priorisé avec les corrections à fort impact.
Demander mon audit gratuit