Core Web Vitals : LCP, INP, CLS, et ce que l’on corrige d’abord

Trois mesures, trois seuils, deux sources de données et deux outils gratuits. Voici ce que les Core Web Vitals disent d’une boutique en ligne, ce qu’ils pèsent pour Google, et l’ordre dans lequel nous reprenons des pages lentes.

Sur une boutique, la vitesse se joue d’abord sur téléphone, en trois moments : la photo du produit qui tarde à paraître, le bouton d’achat qui répond avec retard, la page qui saute au moment du toucher. Les Core Web Vitals mettent un chiffre sur chacun de ces moments.

Notre note SEO on page : ce que Google regarde sur une page les présente en quelques lignes, parmi tout ce que Google lit sur une page. Celle-ci les déroule mesure par mesure, jusqu’aux corrections.

1. 1Le LCP : la photo du produit s’affiche
2. 2L’INP : la page répond au toucher
3. 3Le CLS : la page bouge sous le doigt

1Que sont les Core Web Vitals ?

Les Core Web Vitals sont trois indicateurs que Google publie pour mesurer l’expérience d’une page : son chargement, sa réactivité et sa stabilité. Google les a présentés en mai 2020, sur son site web.dev ; le 12 mars 2024, l’INP a remplacé le FID comme mesure de la réactivité.

Ce seuil se lit au 75e centile : trois visites sur quatre doivent l’atteindre. Chaque mesure se range dans l’un de trois états.

La mesure la plus lente l’emporte : dans Search Console, un groupe de pages prend l’état de sa moins bonne mesure. Une fiche qui se charge vite mais saute au moment du toucher reste « Médiocre » ; c’est donc chaque mesure, l’une après l’autre, qu’il faut regarder.

2Le LCP, ou le temps d’affichage du contenu principal

Le LCP mesure le temps qu’il faut pour afficher le plus grand élément visible à l’écran, depuis le début du chargement. Sur une fiche produit, c’est presque toujours la photo principale ; sur une catégorie, la bannière ou la première rangée de vignettes ; sur un article, parfois un bloc de texte.

web.dev découpe ce temps en quatre parts : la réponse du serveur, le délai avant que le navigateur demande l’image, son téléchargement, puis son affichage. Sur les boutiques, deux causes reviennent : une photo trop lourde, et une photo que le thème charge « en différé », comme si elle se trouvait en bas de la page. La documentation de web.dev demande l’inverse pour l’image du LCP : la déclarer dans le HTML, la charger tout de suite, et lui donner la priorité.

<!-- avant : un fichier lourd, chargé en différé -->
<img src="/photos/suspension-lin-2400.jpg" loading="lazy"
   alt="Suspension en lin beige, abat-jour conique">

<!-- après : un fichier léger, ses dimensions, la priorité -->
<img src="/photos/suspension-lin-1000.webp"
   width="1000" height="1000"
   fetchpriority="high"
   alt="Suspension en lin beige, abat-jour conique">

Les photos situées plus bas gardent leur chargement différé : il réserve la connexion à ce que le client voit d’abord. Sur la fiche, le gain se joue donc sur une seule image, la première.

3L’INP, ou le temps de réponse au toucher

L’INP mesure le temps qui sépare un geste du client, un clic, un toucher ou une touche du clavier, de l’affichage qui suit à l’écran. Il observe toutes les interactions de la visite et retient la plus lente, en écartant les valeurs extrêmes ; le défilement et le survol restent hors du calcul.

Sur une boutique, les gestes qui comptent sont ceux qui vendent : ajouter au panier, choisir une taille, ouvrir un filtre, déplier le menu. Quand le navigateur est occupé à exécuter du JavaScript, le geste attend son tour. Les scripts tiers en sont souvent la source : la fenêtre de discussion, le module d’avis, les pixels publicitaires, les balises accumulées dans un gestionnaire de balises. web.dev conseille de retirer le code inutile et de relire ces balises à intervalles réguliers.

un clic qui tarde,
c’est un panier qui hésite

Lighthouse, l’outil de test de Google, charge la page seul, en l’absence de tout visiteur : il mesure le LCP et le CLS, et remplace l’INP par un indicateur voisin, le Total Blocking Time, le temps pendant lequel la page reste occupée. L’INP réel se lit dans les données de vos visiteurs.

4Le CLS, ou la stabilité de la page

Le CLS mesure les déplacements inattendus de la mise en page : un bloc qui apparaît et pousse le reste, au moment où le client allait toucher un bouton. Son score combine la part de l’écran qui bouge et la distance du saut. web.dev retient la plus forte salve de déplacements sur toute la durée de la visite, et laisse de côté ceux qui suivent de moins d’une demi-seconde un geste du client.

Sur une boutique, quatre causes reviennent : des images dont les dimensions manquent dans le code, un module d’avis ou de recommandations inséré après coup, un bandeau (cookies, livraison, promotion) qui s’ouvre en haut de page, et une police de caractères qui remplace la police de secours en changeant la longueur des lignes.

Les polices ont leur propre réglage. web.dev conseille la règle font-display: optional, une police de secours proche de la police choisie, ajustée avec size-adjust, et le préchargement des polices utiles au premier affichage.

5Données de terrain ou de laboratoire : CrUX et Lighthouse

Les Core Web Vitals se mesurent de deux façons, et la différence compte pour une boutique. Les données de terrain viennent du Chrome UX Report, le CrUX : les visites réelles des 28 derniers jours, faites avec Chrome par des utilisateurs qui partagent leurs statistiques d’usage. Les données de laboratoire viennent de Lighthouse, qui charge la page une fois, sur un appareil et une connexion simulés.

Une limite du terrain mérite d’être connue : le CrUX compte seulement Chrome, sur ordinateur et sur Android. Les visites faites sur iPhone, avec Safari comme avec Chrome, en restent à l’écart. Si une grande part de vos ventes passe par des iPhone, le rapport décrit le reste de votre clientèle, et le test de Lighthouse sert de complément.

6Où lire ses Core Web Vitals ?

Deux outils gratuits de Google suffisent pour commencer : Search Console pour l’ensemble du site, PageSpeed Insights pour une adresse précise.

Le rapport range les pages en groupes d’adresses semblables, avec une adresse d’exemple pour chacun et la valeur du groupe pour la mesure en cause. Sur une boutique, un groupe correspond souvent à un modèle : les fiches produits, les catégories, les articles. Deux détails comptent : seules les pages indexées y figurent, et les données vont à l’adresse visitée telle quelle, là où les autres rapports regroupent les doubles sous l’adresse canonique. Une variante en ?variant= peut donc y apparaître seule.

PageSpeed Insights prend ensuite le relais, adresse par adresse. En haut, les mesures des vrais visiteurs sur 28 jours, celles de la page ou, à défaut, de tout le site ; plus bas, le diagnostic de Lighthouse, qui nomme l’élément du LCP, les scripts qui occupent la page et les éléments qui bougent.

7Que pèsent les Core Web Vitals dans le classement Google ?

Les Core Web Vitals comptent dans le classement, avec un poids de départage. Google l’écrit dans sa documentation sur l’expérience sur la page, mise à jour le 22 septembre 2026 : ses systèmes de classement les utilisent. Il y ajoute qu’il cherche toujours à montrer le contenu le plus pertinent, même quand l’expérience laisse à désirer, et qu’un bon rapport dans Search Console laisse la première place à gagner par ailleurs.

Nous traitons donc la vitesse comme un départage entre des pages également utiles, et d’abord comme une affaire de ventes, à sa place dans notre travail pour vendre plus en ligne.

Le gain se lit d’abord dans les ventes. Google publie sur web.dev des études de cas, à lire comme telles : des entreprises étrangères, souvent une page et une période.

Le même test relève 53,37 % de revenu par visiteur en plus. La boutique, qui vend des produits du quotidien, avait allégé ses images et son JavaScript, et réservé la place de ses images avant leur chargement.

8Ce qu’une boutique corrige d’abord

Une boutique corrige d’abord ses modèles de pages, dans cet ordre : les images, les mises en page qui bougent, les scripts tiers, les polices. Le rapport range les pages par groupes ; la cause se trouve donc le plus souvent dans le modèle commun, le thème ou une application, et une correction faite sur le modèle profite à des centaines de fiches. Nous commençons par le rapport mobile et par les groupes qui portent le chiffre d’affaires : les fiches produits, puis les catégories.

1. 1Les imagesLa photo principale des fiches et la bannière des catégories : au bon format (WebP ou AVIF), à la bonne taille, chargées en priorité. Les photos plus bas sur la page gardent leur chargement différé.
2. 2Les mises en page qui bougentDes dimensions pour chaque image, une place réservée aux modules d’avis et de recommandations, des bandeaux posés par-dessus la page.
3. 3Les scripts tiersL’inventaire de ce que chargent le thème, les applications et le gestionnaire de balises : chaque script répond à un besoin nommé, les autres partent, et ceux qui peuvent attendre se chargent après l’affichage.
4. 4Les policesDeux ou trois fichiers, préchargés, avec une police de secours proche, pour que le remplacement passe inaperçu.
5. 5Le suivi dans Search ConsoleUne fois le modèle corrigé, le bouton Démarrer le suivi du rapport lance une surveillance de 28 jours sur les adresses concernées.

Voici cet ordre appliqué à une boutique imaginaire, du rapport au résultat.

Avant de lancer le suivi, nous passons cette liste. Cochez au fil de votre relecture.

Une fiche rapide doit aussi être bien lue : son prix, son stock et ses avis passent par les données structurées, que détaille notre note Données structurées : ce qu’elles apportent dans Google et aux IA. Et pour le texte de la fiche elle-même, notre note Fiche produit SEO prend le relais.

Questions fréquentes

Sur le même sujet

SEO on page : ce que Google regarde sur une page Référencement naturel Pour comprendre Lire la note Données structurées : ce qu’elles apportent dans Google et aux IA Référencement naturel Pour agir Lire la note Référencement Shopify : ce que la plateforme fait seule, ce qui reste à faire Référencement naturel Pour agir Lire la note