Core Web Vitals pour les boutiques en ligne : LCP, INP et CLS expliqués

Ce que mesurent LCP, INP et CLS, les seuils au 75e centile, données de laboratoire ou de terrain, et les correctifs courants sur Shopify et WooCommerce.

Rédaction FixReports15 min de lecture

Les Core Web Vitals (Signaux Web essentiels) sont trois métriques de Google qui décrivent l’expérience réelle des visiteurs sur une page : le Largest Contentful Paint (LCP) pour le chargement, l’Interaction to Next Paint (INP) pour la réactivité et le Cumulative Layout Shift (CLS) pour la stabilité visuelle. Une page est validée lorsqu’au moins 75 % des visites se situent dans la plage « bonne » : LCP de 2,5 secondes au maximum, INP de 200 millisecondes au maximum et CLS inférieur ou égal à 0,1, mesurés séparément sur mobile et sur ordinateur. Sur les boutiques en ligne, les mauvais résultats s’expliquent généralement par des images de bannière principale et de produit trop lourdes ou chargées en différé, des scripts d’applications et de suivi, des polices web, ainsi que des bandeaux ou des widgets d’avis qui poussent le contenu vers le bas après l’affichage de la page.

Points clés

Quels sont les seuils des Core Web Vitals ?

Une page respecte les Core Web Vitals lorsque le 75e centile de ses chargements se situe dans la plage « bonne » pour les trois métriques.

MétriqueCe qu’elle mesureBonÀ améliorerMauvais
LCPTemps nécessaire à l’affichage de la plus grande image, vidéo ou du plus grand bloc de texte visible dans la fenêtre2,5 s ou moinsPlus de 2,5 s et jusqu’à 4,0 sPlus de 4,0 s
INPTemps écoulé entre un clic, un appui ou une pression de touche et l’affichage de l’image suivante200 ms ou moinsPlus de 200 ms et jusqu’à 500 msPlus de 500 ms
CLSAmpleur des déplacements inattendus du contenu visible0,1 ou moinsPlus de 0,1 et jusqu’à 0,25Plus de 0,25

Seuils tirés des guides de web.dev sur le LCP (s’ouvre dans un nouvel onglet), l’INP (s’ouvre dans un nouvel onglet) et le CLS (s’ouvre dans un nouvel onglet), en octobre 2026.

Le 75e centile signifie que le résultat reflète la plupart des visiteurs, et pas seulement les plus rapides, et Google distingue le mobile et l’ordinateur (s’ouvre dans un nouvel onglet). PageSpeed Insights valide une page lorsque les trois métriques sont bonnes ; faute de données INP suffisantes, il évalue le LCP et le CLS seuls (documentation de PageSpeed Insights (s’ouvre dans un nouvel onglet)). Google indique que les Core Web Vitals stables ne changeront pas plus d’une fois par an.

Sur une boutique, l’élément LCP est souvent la bannière principale ou l’image principale du produit : c’est pourquoi la gestion des images compte autant.

Pourquoi l’INP a-t-il remplacé le FID en mars 2024 ?

L’INP a remplacé le FID parce que le FID ne mesurait que la première interaction, et seulement une partie de son délai, alors que l’INP prend en compte les interactions sur toute la durée de la visite.

Google a annoncé en mai 2023 que l’INP deviendrait un Core Web Vital, et le changement a pris effet le 12 mars 2024 (s’ouvre dans un nouvel onglet). Le FID ne mesurait que la première interaction, et uniquement son délai d’entrée, sans le temps passé à exécuter les gestionnaires d’événements ni à afficher le résultat. L’INP observe les clics, les appuis et les pressions de touche pendant toute la visite et retient l’interaction la plus longue, en ignorant les valeurs aberrantes ; le défilement et le survol ne comptent pas. Les utilisateurs des API CrUX et PageSpeed Insights avaient jusqu’au 9 septembre 2024 pour effectuer la transition (web.dev (s’ouvre dans un nouvel onglet)).

Chaque interaction comporte trois phases : le délai d’entrée (l’attente pendant que des scripts occupent le navigateur), la durée de traitement (l’exécution des gestionnaires) et le délai de présentation (l’affichage de l’image suivante) (web.dev (s’ouvre dans un nouvel onglet)).

Sur une boutique, ces interactions sont le sélecteur de variantes, les boutons de quantité, l’ajout au panier, le tiroir du panier, les filtres et les menus. Une page pouvait réussir le FID grâce à un premier appui rapide et paraître lente lorsqu’un visiteur ouvrait les filtres plus tard.

Quelle est la différence entre données de laboratoire et données de terrain ?

Les données de laboratoire proviennent d’un test unique réalisé dans des conditions fixes, tandis que les données de terrain sont collectées auprès de vrais visiteurs au fil du temps, et Google recommande de s’appuyer sur les données de terrain pour décider quoi corriger en premier (web.dev (s’ouvre dans un nouvel onglet)).

Données de laboratoireDonnées de terrain
SourceUn chargement de page simulé (Lighthouse, Chrome DevTools, la section laboratoire de PageSpeed Insights)De vrais visiteurs sous Chrome (Chrome UX Report), ou votre propre outil de mesure des utilisateurs réels (RUM)
ConditionsAppareil et réseau fixes. Le test mobile par défaut de Lighthouse (s’ouvre dans un nouvel onglet) utilise le profil « Slow 4G » (aller-retour de 150 ms, 1,6 Mbit/s en téléchargement) et un processeur ralenti 4xLes appareils, réseaux et lieux de vos visiteurs, quels qu’ils soient
INPNon mesuré lors d’un simple chargement de page. Le Total Blocking Time (TBT) en donne une approximation grossièreMesuré à partir de vraies interactions
Idéal pourDéboguer et vérifier une modification avant sa mise en ligneSavoir ce que les visiteurs obtiennent réellement

Le TBT additionne la part de chaque tâche du thread principal qui dépasse 50 ms ; web.dev recommande moins de 200 ms sur un matériel mobile moyen, mais précise qu’il ne remplace pas l’INP (web.dev (s’ouvre dans un nouvel onglet)).

Trois particularités du Chrome UX Report (CrUX) comptent pour les boutiques :

  • Il s’agit d’une moyenne glissante sur 28 jours (s’ouvre dans un nouvel onglet), mise à jour chaque jour.
  • Il couvre Chrome sur ordinateur et sur Android pour les utilisateurs qui remplissent les conditions de collecte de Chrome. Chrome sur iOS est exclu : une boutique dont les clients utilisent surtout un iPhone ne voit donc des données de terrain que pour une partie de son audience (méthodologie (s’ouvre dans un nouvel onglet)).
  • Les pages et les origines n’apparaissent que si elles sont publiquement détectables et suffisamment populaires : une boutique à faible trafic peut donc n’avoir que des données au niveau de l’origine, voire aucune.

Le tableau de bord des performances web (s’ouvre dans un nouvel onglet) de Shopify indique lui aussi le LCP, l’INP et le CLS d’utilisateurs réels au 75e centile, mais sur 30 jours au lieu de 28 : attendez-vous à quelques écarts avec CrUX.

Qu’est-ce qui ralentit le LCP sur les pages d’une boutique ?

Sur les boutiques, un LCP lent s’explique généralement par une image principale trop lourde, découverte tardivement, ou volontairement retardée par le chargement différé ou par une animation.

  • Chargement différé de l’image LCP. web.dev recommande de ne jamais le faire (web.dev (s’ouvre dans un nouvel onglet)). Son analyse de pages WordPress a constaté un LCP au 75e centile plus lent sur les sites utilisant le chargement différé natif, et le fait de ne pas différer les images situées au-dessus de la ligne de flottaison a supprimé cette régression (web.dev (s’ouvre dans un nouvel onglet)).
  • Image découverte tardivement. Une bannière principale définie comme background-image en CSS, ou injectée par un script de diaporama, ne figure pas dans le HTML que le navigateur analyse en premier. Shopify déconseille les arrière-plans CSS pour le contenu de la bannière principale ainsi que les effets de fondu sur l’image LCP (Shopify (s’ouvre dans un nouvel onglet)).
  • Priorité basse. Les images se chargent en priorité basse tant que la mise en page n’est pas terminée : Shopify recommande donc fetchpriority="high" sur l’image LCP (Shopify (s’ouvre dans un nouvel onglet)). web.dev précise que l’appliquer à plus d’une ou deux images en réduit l’utilité (web.dev (s’ouvre dans un nouvel onglet)).
  • CSS et scripts bloquant le rendu. Les feuilles de style volumineuses et les scripts synchrones placés dans le <head> retardent le rendu même après l’arrivée de l’image (web.dev (s’ouvre dans un nouvel onglet)).
  • Poids des fichiers et polices. Utilisez des formats modernes, srcset et sizes, ainsi qu’un CDN. Pour les polices web, choisissez une valeur font-display autre que auto ou block.
<!-- Main product image: real src in the HTML, eager, high priority -->
<img src="/images/linen-shirt-1200.webp"
     srcset="/images/linen-shirt-600.webp 600w, /images/linen-shirt-1200.webp 1200w"
     sizes="(min-width: 990px) 50vw, 100vw"
     width="1200" height="1500"
     fetchpriority="high"
     alt="Natural linen shirt, front view">

<!-- Gallery images below the first screen: lazy -->
<img src="/images/linen-shirt-back-600.webp" loading="lazy"
     width="600" height="750" alt="Natural linen shirt, back view">

Qu’est-ce qui rend l’INP lent sur les pages d’une boutique ?

Sur les boutiques, un INP lent signifie généralement qu’il y a trop de JavaScript sur le thread principal, dont une grande partie provient des applications, des balises de suivi et des fonctionnalités du thème : les appuis doivent donc attendre.

Si un client appuie sur « Ajouter au panier » pendant que des scripts d’avis, de chat et d’analyse d’audience s’exécutent encore, l’appui attend. Un sélecteur de variantes qui réaffiche tout le formulaire produit allonge la durée de traitement. Les méga-menus géants et les grilles de collection comportant de nombreuses pastilles augmentent le délai de présentation.

web.dev recommande de fractionner les tâches longues et de rendre la main au thread principal, de mettre à jour l’écran d’abord et de différer le reste, et de réduire la taille du DOM (web.dev (s’ouvre dans un nouvel onglet)). Shopify ajoute des étapes propres aux boutiques : auditer chaque application, pixel et script du thème, différer ce qui n’est pas critique, charger les fonctionnalités au moment de l’interaction et désactiver les extraits anti-scintillement des tests A/B lorsqu’aucun test n’est en cours (Shopify (s’ouvre dans un nouvel onglet)).

Qu’est-ce qui provoque des décalages de mise en page sur les fiches produit et les pages de collection ?

Sur les boutiques, les décalages de mise en page proviennent surtout de contenus qui apparaissent ou changent de taille après le premier rendu : images sans dimensions, barres d’annonce et bandeaux cookies, widgets d’avis, blocs d’applications et changements de police.

web.dev cite comme causes courantes les médias aux dimensions inconnues, le contenu ajouté au-dessus du contenu existant, les widgets tiers qui se redimensionnent d’eux-mêmes et les polices web dont la taille diffère de celle de leur police de secours (web.dev (s’ouvre dans un nouvel onglet)). Sur une boutique, cela correspond à une barre de livraison gratuite insérée en haut de page, à des notes en étoiles qui se chargent après le titre, à un message de paiement en plusieurs fois sous le prix et à des carrousels de recommandations. Shopify signale que les contenus en pop-up peuvent aussi provoquer des décalages (Shopify (s’ouvre dans un nouvel onglet)).

Les décalages qui surviennent dans les 500 ms suivant une action de l’utilisateur ne comptent pas, mais ceux qui se produisent pendant le défilement comptent, et les outils de laboratoire les manquent souvent (web.dev (s’ouvre dans un nouvel onglet)). Donnez aux images des attributs width et height ou une propriété CSS aspect-ratio, réservez de l’espace pour les widgets, affichez les bandeaux en surimpression, réduisez les décalages dus au changement de police avec size-adjust, et animez avec transform plutôt qu’avec top ou left.

/* Reserve space for a reviews summary that loads after the page */
.product-reviews-summary { min-height: 24px; }

/* Keep product cards from jumping while images load */
.product-card img { width: 100%; height: auto; aspect-ratio: 4 / 5; }

Comment améliorer les Core Web Vitals sur Shopify ?

Sur Shopify, l’essentiel des gains vient du chargement immédiat et prioritaire de la première image, de l’allègement des scripts d’applications et de la vérification du résultat dans les rapports de performances web de l’interface d’administration.

Consultez les données dans votre interface d’administration

Un résumé s’affiche sur la page Online Store > Themes, et les rapports complets sur le LCP, l’INP et le CLS se trouvent sous Analytics > Reports. Les données peuvent avoir jusqu’à 36 heures de retard, et le mode privé doit être désactivé (centre d’aide Shopify (s’ouvre dans un nouvel onglet)).

Contrôlez le chargement des images en Liquid

Le filtre image_tag charge en différé les images des sections situées plus bas dans la page, sauf si vous définissez preload (référence de image_tag (s’ouvre dans un nouvel onglet)) : chargement immédiat pour les sections 1 à 3, différé à partir de la section 4. Comme section.index vaut nil dans l’éditeur de thème, testez avec > 3 plutôt qu’avec <= 3 :

{%- if section.index == 1 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'eager', fetchpriority: 'high', widths: '600, 900, 1200, 1600', sizes: '100vw' }}
{%- elsif section.index > 3 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'lazy', sizes: '100vw' }}
{%- else -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: sizes: '100vw' }}
{%- endif -%}

Dans les grilles de produits, Shopify suggère de ne charger immédiatement que les premières cartes (par exemple forloop.index <= 4) (Shopify (s’ouvre dans un nouvel onglet)). Utilisez preload: true avec parcimonie ; Shopify recommande de ne précharger qu’une ou deux ressources découvertes tardivement.

Supprimez ce que laissent les applications

Désactivez les intégrations d’applications inutilisées sous Online Store > Edit theme > App embeds (centre d’aide Shopify (s’ouvre dans un nouvel onglet)). Désinstaller une application supprime ses blocs d’applications, mais les applications qui ont modifié directement les fichiers du thème peuvent laisser du « code fantôme » (ghost code) qui, selon Shopify, peut nuire à la qualité et aux performances (Shopify (s’ouvre dans un nouvel onglet)). Shopify indique aussi que les balises de script (script tags) cesseront de fonctionner le 1er mars 2027. Pour les polices, Shopify recommande son propre CDN ou les polices système plutôt que des services de polices externes (Shopify (s’ouvre dans un nouvel onglet)).

Comment améliorer les Core Web Vitals sur WooCommerce ?

Sur WooCommerce, vérifiez que les extensions ne remplacent pas la priorisation des images de WordPress, mettez tout en cache sauf le panier et la page de paiement, et supprimez les scripts chargés partout sans nécessité.

  • Conservez la gestion des images du cœur de WordPress. Depuis WordPress 6.3 (publié le 8 août 2023), le cœur ajoute fetchpriority="high" à l’image LCP probable (d’au moins 50 000 pixels carrés par défaut) et n’applique pas le chargement différé aux trois premières images du contenu (Make WordPress Core (s’ouvre dans un nouvel onglet)). Si une extension d’optimisation ajoute son propre chargement différé, vérifiez qu’elle exclut la bannière principale et l’image principale du produit.
  • Mettez en cache les pages, pas les paniers. Le guide de WooCommerce recommande une mise en cache des pages côté serveur ou par extension et un CDN, tout en laissant les pages de panier et de paiement hors cache (documentation développeurs WooCommerce (s’ouvre dans un nouvel onglet)).
  • Vérifiez les fragments de panier. Depuis WooCommerce 7.8, le script des fragments de panier (cart fragments) ne se charge que là où un widget Panier est présent, mais certains thèmes intègrent ce widget en dur. Le bloc Mini-panier n’utilise pas les fragments de panier (blog développeurs WooCommerce (s’ouvre dans un nouvel onglet)).
  • Repérez les extensions lourdes. WooCommerce suggère Query Monitor pour identifier les extensions lentes, ainsi que le report du JavaScript non critique.

Si votre mise en page affiche plus de trois images au-dessus de la ligne de flottaison, vous pouvez relever le seuil de WordPress :

// functions.php: skip lazy loading for the first 4 content images (default is 3)
add_filter( 'wp_omit_loading_attr_threshold', function () {
    return 4;
} );

Combien de temps faut-il pour que les corrections se voient ?

Les tests en laboratoire montrent immédiatement l’effet d’une correction, mais les données de terrain mettent jusqu’à quatre semaines environ à le refléter entièrement, car CrUX fait la moyenne des 28 jours précédents.

Exécutez le test en laboratoire plusieurs fois avant et après une modification, car les résultats varient d’une exécution à l’autre, puis surveillez les données de terrain dans PageSpeed Insights, le rapport Core Web Vitals de Search Console ou les rapports de Shopify. Une analyse gratuite donne une première lecture en une minute environ. Le Rapport Performance exécute un test mobile en laboratoire avec bridage (4G lente, processeur ralenti 4x) et y ajoute les données de terrain du Chrome UX Report, y compris l’INP lorsque Google dispose d’assez de données pour votre boutique.

Foire aux questions

Les Core Web Vitals influencent-ils le classement dans Google ?

Google indique que les Core Web Vitals sont utilisés par ses systèmes de classement, mais que de bons scores ne garantissent pas les premières positions et qu’il affiche toujours le contenu le plus pertinent, même lorsque l’expérience sur la page est médiocre (Google Search Central (s’ouvre dans un nouvel onglet)).

Pourquoi PageSpeed Insights n’affiche-t-il aucune donnée de terrain pour ma boutique ?

CrUX n’inclut que les pages et les origines publiquement détectables qui comptent suffisamment de visiteurs Chrome éligibles. Une boutique à faible trafic peut n’avoir que des données au niveau de l’origine, voire aucune : appuyez-vous alors sur les tests en laboratoire et sur les rapports de votre plateforme.

Faut-il un score Lighthouse de 90 ou plus pour valider les Core Web Vitals ?

Non. Le score de performance Lighthouse est un résultat de laboratoire, alors que l’évaluation des Core Web Vitals repose sur les données de terrain au 75e centile : une page peut donc être validée avec un score Lighthouse modeste et échouer avec un score élevé.

Faut-il charger toutes les images produit en différé ?

Non. Chargez en différé les images situées sous le premier écran, mais chargez immédiatement la bannière principale et l’image principale du produit, avec fetchpriority="high" sur l’une d’elles.

Pourquoi mes résultats sur mobile sont-ils moins bons que sur ordinateur ?

Google mesure séparément le mobile et l’ordinateur, et les téléphones disposent de processeurs et de réseaux plus lents. Le test mobile de Lighthouse simule ces conditions avec un profil Slow 4G et un processeur ralenti 4x.

Sources

Tous les guides