Core Web Vitals pour l'e-commerce : corriger LCP, INP et CLS
Les pages produits lentes coûtent des conversions. Voici ce que LCP, INP et CLS signifient vraiment pour les boutiques en ligne, et les correctifs à plus fort impact pour chaque métrique.
Vous avez lancé PageSpeed Insights sur votre page produit. Trois jauges rouges vous fixent en retour. Le score est de 41. La page se charge lentement sur votre téléphone de test aussi, mais vous ne savez pas laquelle des trois métriques vous coûte réellement des ventes — ni laquelle corriger en premier.
Les Core Web Vitals sont les trois métriques de chargement et d'interaction que Google publie pour chaque site. Elles affectent le classement à la marge. Elles affectent la conversion bien davantage. Pour une boutique en ligne où chaque seconde de délai grignote la confiance au moment du clic d'achat, l'impact sur la conversion seul justifie de les corriger, même avant de prendre en compte le SEO.
Les trois métriques, en bref
- LCP (Largest Contentful Paint) mesure le temps que met l'élément visible le plus grand à finir de se charger — généralement l'image hero de votre produit. Bon : moins de 2,5 secondes. Mauvais : plus de 4 secondes.
- INP (Interaction to Next Paint) mesure la réactivité de votre page aux taps et clics. Elle a remplacé FID en mars 2024. Bon : moins de 200 ms. Mauvais : plus de 500 ms.
- CLS (Cumulative Layout Shift) mesure à quel point les éléments sautent à mesure que la page se charge. Bon : moins de 0,1. Mauvais : plus de 0,25.
Le guide de web.dev sur les Core Web Vitals couvre les définitions formelles ; le reste de cet article se concentre sur ce qu'il faut faire à leur sujet sur une boutique réelle.
Pourquoi l'e-commerce est plus durement touché que les blogs
Un article de blog, c'est du texte, peut-être une image hero, peut-être une intégration. Une page produit, c'est une image hero, une galerie de miniatures, un widget d'avis, un carrousel de recommandations, une bulle de chat, une popup d'upsell, un tiroir panier, l'analytique pour trois plateformes, un enregistreur de heatmap et un framework d'A/B test. Chacun de ces éléments livre du JavaScript. Chacun se dispute le thread principal.
Une vitrine Shopify typique en 2026 livre une combinaison de :
- Klaviyo (capture d'email, popups)
- Privy ou OptinMonster (exit-intent)
- Smile.io ou Loyalty Lion (widget de fidélité)
- Yotpo ou Judge.me (avis)
- Tidio ou Gorgias (chat)
- Hotjar ou Microsoft Clarity (enregistrement de session)
- GA4, Meta Pixel, TikTok Pixel (analytique)
Chacun semble gratuit quand vous l'installez. Aucun ne l'est. Le coût apparaît d'abord dans l'INP, puis dans le LCP, puis dans votre taux de conversion.
Correctifs LCP pour les pages produits
Le LCP sur une page produit est presque toujours l'image hero. Trois changements par ordre d'impact :
1. Servez le bon format et la bonne taille. Un PNG de 4000×4000 sortant directement de votre photographe produit pèse 6 Mo. La même image au format WebP ou AVIF correctement dimensionné aux dimensions réellement rendues fait souvent moins de 150 Ko. Shopify et WooCommerce gèrent tous les deux cela si vous arrêtez d'écraser leur redimensionnement.
2. Préchargez l'image hero. Ajoutez un indice de preload dans le <head> pour que le navigateur commence à la récupérer avant de parser le reste de la page :
<link rel="preload" as="image"
href="/products/wallet-hero.webp"
imagesrcset="/products/wallet-hero-400.webp 400w,
/products/wallet-hero-800.webp 800w,
/products/wallet-hero-1200.webp 1200w"
imagesizes="(max-width: 768px) 100vw, 50vw">
3. Ne lazy-loadez pas les images au-dessus de la ligne de flottaison. loading="lazy" sur votre image hero est de loin le tueur de LCP le plus courant sur les pages produits. Lazy-loadez les miniatures et les images de galerie sous la ligne de flottaison ; jamais la première image visible.
Référence : Optimize LCP sur web.dev.
Correctifs INP pour les pages produits
L'INP est le domaine où la plupart des boutiques souffrent le plus. Le schéma est constant : la page semble chargée, l'utilisateur tape « Ajouter au panier », et il y a un gel de 600 ms avant qu'il ne se passe quoi que ce soit. Ce gel, c'est du JavaScript qui tourne sur le thread principal.
1. Différez les scripts non critiques. Ajoutez defer ou chargez via async tout ce qui n'est pas nécessaire pour afficher le bouton d'achat. Widgets d'avis, bulles de chat, moteurs de recommandation — tous devraient se charger après que la page est interactive, pas pendant.
2. Auditez sans pitié les widgets tiers. La plupart des boutiques embarquent deux widgets qui font le même travail (deux outils d'analytique, deux fournisseurs de popups). Choisissez-en un. Supprimez l'autre. Chaque widget supplémentaire s'accumule.
3. Remplacez les widgets d'avis lourds par des notes rendues côté serveur. Un widget d'avis qui hydrate 500 avis dans le DOM côté client est un coupable d'INP du top 3. Rendez la note agrégée et les trois meilleurs avis côté serveur ; chargez la liste complète des avis paresseusement quand l'utilisateur défile jusqu'à elle.
Pour les boutiques basées sur Next.js / React, la documentation React sur l'hydratation lourde et le SSR en streaming de Next.js sont les bons terriers de lapin à explorer.
Correctifs CLS pour les pages produits
Le décalage de mise en page est le moins cher des trois à corriger et le plus embarrassant à laisser cassé. Trois changements :
1. Définissez des dimensions explicites sur chaque image. Incluez toujours les attributs width et height (ou la CSS aspect-ratio) pour que le navigateur réserve l'espace avant que l'image ne se charge :
<img src="/products/wallet.webp"
width="800" height="800"
alt="Hand-stitched leather wallet, front view">
2. Utilisez font-display: swap avec précaution. Un Flash of Unstyled Text décale la mise en page lorsque la police personnalisée se charge. Soit vous préchargez la police, soit vous utilisez font-display: optional pour empêcher les échanges tardifs.
3. Réservez l'espace pour les intégrations. Les widgets d'avis, les carrousels de recommandation et les emplacements publicitaires qui s'injectent au-dessus du contenu existant provoquent des décalages en cascade. Enveloppez-les dans un conteneur à hauteur fixe pendant leur chargement.
Référence : Optimize CLS.
Comment EshopAuditor fait remonter ces problèmes
Le score CWV d'EshopAuditor reflète la performance de votre page d'accueil, mesurée par Google PageSpeed Insights en stratégies Mobile et Desktop. Le reste des pages explorées est analysé pour la structure HTML, le schema, les métadonnées et les problèmes SEO on-page — mais sans exécution de Lighthouse page par page. Lighthouse par page est coûteux en calcul à exécuter à grande échelle ; le CWV de la page d'accueil est le signal indicatif du profil de performance typique du site.
Le CWV de la page d'accueil est indicatif, pas exhaustif : si votre page d'accueil est lente, vos pages produits sont presque toujours plus lentes (même thème, mêmes widgets, même charge de scripts). Pour un CWV exact par page sur l'ensemble de votre catalogue, complétez ce rapport avec la vue Core Web Vitals de Google Search Console, qui utilise les données de terrain CrUX d'utilisateurs réels sur chaque URL pour laquelle Google a des impressions.
La vérité inconfortable sur le CWV et le classement
Google a été clair : les Core Web Vitals sont un signal de classement, mais mineur. Deux pages au contenu de qualité comparable, sur une requête où le CWV est proche, verront le CWV agir comme un tie-breaker. Voilà.
Ce que les Core Web Vitals affectent dramatiquement, c'est le taux de conversion. Un délai d'une seconde sur le LCP ne vous fait pas tomber de la page 1 à la page 2 de Google. Mais cela nuit mesurablement au taux de passage en caisse — et sur le trafic e-commerce, cette baisse de conversion dépasse généralement de loin tout gain ou toute perte SEO. Sur un trimestre de trafic, l'écart paye votre outillage, votre budget pub et votre temps plusieurs fois.
Corrigez les Core Web Vitals parce qu'ils rendent votre boutique plus rentable, pas parce que Google le dit. Le gain SEO est un bonus.
Lancez un audit gratuit de votre boutique sur eshopaudit.io — aucune inscription requise pour la première analyse.