Core Web Vitals : LCP, INP, CLS expliqués et comment les corriger

31 mars 2026 · 12 min de lecture

Les Core Web Vitals sont les métriques officielles de Google pour mesurer l'expérience utilisateur sur le web. Depuis qu'ils sont devenus un facteur de classement en juin 2021, ils ont fondamentalement transformé la façon dont les développeurs, les SEO et les propriétaires de sites abordent les performances des pages. Ce guide complet détaille chaque métrique, explique ce qui cause de mauvais scores et fournit des corrections concrètes et actionnables que vous pouvez mettre en œuvre immédiatement.

Que vous optimisiez un site e-commerce, une plateforme de contenu ou une application SaaS, comprendre et améliorer les Core Web Vitals n'est plus optionnel—c'est essentiel pour la visibilité dans les recherches et la satisfaction des utilisateurs.

Que sont les Core Web Vitals ?

Les Core Web Vitals (CWV) sont un ensemble de trois métriques spécifiques que Google considère comme essentielles pour offrir une bonne expérience utilisateur. Ils mesurent trois dimensions critiques des performances de page qui impactent directement la façon dont les utilisateurs perçoivent et interagissent avec votre site web.

Les trois Core Web Vitals sont :

• Largest Contentful Paint (LCP) — Mesure les performances de chargement en suivant quand le plus grand élément de contenu visible s'affiche
• Interaction to Next Paint (INP) — Mesure l'interactivité en évaluant la rapidité avec laquelle la page répond à toutes les interactions utilisateur
• Cumulative Layout Shift (CLS) — Mesure la stabilité visuelle en quantifiant les décalages de mise en page inattendus pendant le chargement de la page

Contrairement aux tests synthétiques en laboratoire qui s'exécutent dans des environnements contrôlés, Google évalue les Core Web Vitals en utilisant des données réelles d'utilisateurs Chrome réels via le Chrome User Experience Report (CrUX). Cela signifie que votre site doit bien fonctionner pour de vrais utilisateurs sur de vrais appareils avec des conditions réseau variables—pas seulement dans votre environnement de développement.

L'évolution des Core Web Vitals

Les Core Web Vitals ne sont pas statiques. Google incluait à l'origine le First Input Delay (FID) comme métrique d'interactivité, mais l'a remplacé par Interaction to Next Paint (INP) en mars 2024. Ce changement reflète l'engagement de Google à mesurer ce qui compte réellement pour les utilisateurs, pas seulement ce qui est facile à mesurer.

Le passage de FID à INP était significatif car FID ne mesurait que la première interaction, tandis qu'INP évalue toutes les interactions tout au long du cycle de vie de la page. Cela fournit une vue plus complète de la réactivité et corrèle mieux avec la frustration des utilisateurs.

Pourquoi les Core Web Vitals sont importants pour le SEO et les affaires

Les Core Web Vitals font partie des signaux d'expérience de page de Google, qui incluent également la compatibilité mobile, la sécurité HTTPS et l'absence d'interstitiels intrusifs. Bien que la pertinence du contenu et l'autorité dominent toujours les classements, les CWV agissent comme un briseur d'égalité—lorsque deux pages sont également pertinentes, celle avec de meilleures performances gagne.

Mais l'impact s'étend bien au-delà des classements de recherche. Les performances affectent directement vos résultats financiers :

Des études de cas réelles démontrent ces impacts. Lorsque Vodafone a amélioré son LCP de 31%, ils ont constaté une augmentation de 8% des ventes. Lorsque Yahoo Japan a réduit le CLS de 0,2, la durée de session a augmenté de 15%. Ce ne sont pas des gains marginaux—ce sont des améliorations qui transforment les affaires.

La réalité du mobile d'abord

Avec l'indexation mobile-first de Google, vos scores Core Web Vitals mobiles sont ce qui compte le plus. Les appareils mobiles ont généralement des processeurs plus lents, moins de mémoire et des conditions réseau plus variables que les ordinateurs de bureau, ce qui rend l'optimisation plus difficile mais aussi plus critique.

Les utilisateurs mobiles sont également moins indulgents. Une étude de Google a révélé que 53% des utilisateurs mobiles abandonnent les sites qui mettent plus de 3 secondes à charger. De mauvais Core Web Vitals contribuent directement à ces taux d'abandon.

Largest Contentful Paint (LCP)

Le Largest Contentful Paint mesure le temps nécessaire pour que le plus grand élément de contenu visible s'affiche dans la fenêtre d'affichage. Il s'agit généralement d'une image héros, d'une vignette vidéo, d'un grand bloc de texte ou d'une image d'arrière-plan. Le LCP est le Core Web Vital le plus intuitif car il correspond directement à la perception de l'utilisateur de « quand cette page s'est-elle chargée ? »

Seuils LCP

Quels éléments comptent comme LCP ?

Tous les éléments de votre page ne sont pas éligibles pour être l'élément LCP. Seuls ces types d'éléments sont considérés :

• Éléments <img>
• Éléments <image> à l'intérieur de <svg>
• Éléments <video> avec des images d'affiche
• Éléments avec des images d'arrière-plan chargées via CSS url()
• Éléments de niveau bloc contenant des nœuds de texte

L'élément LCP peut changer au fur et à mesure que la page se charge. Initialement, il peut s'agir d'un titre de texte, mais une fois votre image héros chargée, celle-ci devient le nouvel élément LCP. Le LCP final est enregistré lorsque l'utilisateur commence à interagir avec la page ou navigue ailleurs.

Problèmes LCP courants et solutions

Problème 1 : Temps de réponse du serveur lents

Si votre Time to First Byte (TTFB) est lent, tout le reste en souffre. Le navigateur ne peut pas commencer le rendu tant qu'il n'a pas reçu le document HTML.

Solutions :

• Utiliser un Content Delivery Network (CDN) pour servir le contenu depuis des emplacements plus proches des utilisateurs
• Implémenter la mise en cache côté serveur avec Redis ou Memcached
• Optimiser les requêtes de base de données et ajouter des index appropriés
• Utiliser HTTP/2 ou HTTP/3 pour le multiplexage et la compression des en-têtes
• Envisager des solutions d'edge computing comme Cloudflare Workers ou Vercel Edge Functions

Problème 2 : Ressources bloquant le rendu

Les fichiers CSS et JavaScript dans le <head> bloquent le rendu jusqu'à ce qu'ils soient téléchargés et traités.

Solutions :

• Intégrer le CSS critique directement dans le HTML pour le contenu au-dessus de la ligne de flottaison
• Différer le CSS non critique en utilisant media="print" onload="this.media='all'"
• Ajouter les attributs async ou defer aux balises script
• Supprimer le CSS et JavaScript inutilisés avec des outils comme PurgeCSS
• Diviser les gros bundles en morceaux plus petits avec le code splitting

Problème 3 : Fichiers image volumineux

Les images non optimisées sont le coupable LCP le plus courant. Une image héros de 5 Mo détruira votre score LCP.

Solutions :

• Compresser les images en utilisant des formats modernes comme WebP ou AVIF (70-90% plus petits que JPEG)
• Implémenter des images responsives avec les attributs srcset et sizes
• Utiliser des CDN d'images qui optimisent et redimensionnent automatiquement les images
• Ajouter fetchpriority="high" à votre image LCP pour prioriser son téléchargement
• Précharger les images LCP avec <link rel="preload" as="image">

Problème 4 : Rendu côté client

Si votre élément LCP est rendu par JavaScript, les utilisateurs doivent attendre que le JS soit téléchargé, analysé et exécuté avant de voir le contenu.

Solutions :

• Utiliser le Server-Side Rendering (SSR) ou la Static Site Generation (SSG)
• Implémenter le streaming SSR avec React Server Components ou des technologies similaires
• Utiliser l'amélioration progressive—rendre une version de base côté serveur, améliorer avec JavaScript
• Envisager l'hydratation partielle pour réduire le temps d'exécution JavaScript

Optimisation LCP avancée

Pour les sites atteignant déjà le seuil de 2,5 secondes, ces techniques avancées peuvent vous pousser dans le niveau de performance supérieur :

Indices de ressources : Utiliser <link rel="preconnect"> pour les origines tierces critiques afin d'établir des connexions tôt. Utiliser <link rel="dns-prefetch"> pour les origines moins critiques.

Indices de priorité : L'attribut fetchpriority indique au navigateur quelles ressources sont les plus importantes. Définir fetchpriority="high" sur votre image LCP et fetchpriority="low" sur les images en dessous de la ligne de flottaison.

103 Early Hints : Ce code de statut HTTP permet aux serveurs d'envoyer des indices de préchargement avant que la réponse principale ne soit prête, donnant au navigateur une longueur d'avance sur le téléchargement des ressources critiques.

Interaction to Next Paint (INP)

L'Interaction to Next Paint mesure la réactivité de votre page aux interactions utilisateur tout au long du cycle de vie complet de la page. Contrairement à son prédécesseur FID, qui ne mesurait que la première interaction, INP évalue chaque clic, tap et pression de touche pour fournir une vue complète de l'interactivité.

INP mesure le temps entre le moment où un utilisateur initie une interaction et le moment où le navigateur affiche la frame suivante montrant le résultat visuel de cette interaction. Cela inclut le délai d'entrée, le temps de traitement et le délai de présentation.

Seuils INP

Comprendre les composants INP

INP se compose de trois phases :

1. Délai d'entrée : Temps entre l'action de l'utilisateur et le moment où les gestionnaires d'événements commencent à s'exécuter (le thread principal doit être disponible)
2. Temps de traitement : Temps passé à exécuter les gestionnaires d'événements et le JavaScript associé
3. Délai de présentation : Temps entre la fin du gestionnaire et le moment où le navigateur affiche la frame suivante

L'interaction la plus lente pendant une