Core Web Vitals e-commerce : les erreurs qui coûtent des ventes

Pourquoi les Core Web Vitals sont critiques pour l'e-commerce

Les web vitals ne sont pas qu'un caprice de Google. Ce sont des mesures de l'expérience réelle de vos utilisateurs - et elles ont un impact direct sur vos revenus.

Les seuils officiels (75e percentile des visites réelles) :

Les chiffres parlent d'eux-mêmes :

• Vodafone : LCP amélioré de 31 % → +8 % de ventes
• Farfetch : chaque 100 ms de LCP gagnée → +1,3 % de conversion
• Swappie : LCP + CLS améliorés → +42 % de revenus mobile
• Cdiscount : CWV optimisés → +6 % de CA lors du Black Friday

La performance site e-commerce n'est pas un sujet DevOps. C'est un sujet business.

Depuis mars 2024, INP a remplacé FID dans les Core Web Vitals. Si votre équipe optimise encore FID, vous travaillez sur la mauvaise métrique.

Erreur #1 - Image produit hero non optimisée (LCP)

C'est l'erreur numéro un que je vois sur les sites e-commerce. L'image hero de la page d'accueil ou de la fiche produit est le plus souvent l'élément LCP - et elle est systématiquement mal gérée.

Symptômes typiques :

• Image servie en JPEG 2 Mo sans compression
• Format PNG au lieu de WebP ou AVIF
• Aucun attribut fetchpriority
• loading="lazy" appliqué à l'image above-the-fold

La correction :

<img src="hero.webp" // Always use WebP or AVIF formats
    fetchpriority="high" // Specify priority for the main LCP image
    loading="eager" // This is optional : `eager` is default value
    width="1200" // Specify image sizes
    height="600" 
    alt="Produit vedette"> // SEO and accessibility alternative description

Si l'image est chargée via CSS ou JavaScript (background-image, carousel JS), ajoutez un preload dans le head :

<link rel="preload" as="image" href="hero.webp" fetchpriority="high">

Points clés :

• Convertissez en WebP (ou AVIF pour les navigateurs modernes)
• Compressez à 85-90% de qualité - l'œil ne voit pas la différence
• N'appliquez fetchpriority="high" qu'à une seule image par page
• Sur Shopify, utilisez image_tag avec le paramètre loading: 'eager' pour l'image hero du thème

Un LCP e-commerce bien traité se joue souvent uniquement sur cette image.

Erreur #2 - Carousel de produits qui décale la page (CLS)

Les carousels de produits en homepage sont des bombes à CLS. Le contenu se charge, le carousel s'initialise, et toute la page saute vers le bas. Résultat : CLS > 0,25, utilisateur frustré, clic raté.

Causes fréquentes :

• Hauteur du carousel non réservée avant l'initialisation JS
• Images sans dimensions explicites (width et height)
• Chargement asynchrone du nombre de slides visible

La correction : Réservez l'espace avant que le JS s'exécute :

.carousel-wrapper { min-height: 420px; /* hauteur connue du carousel */ contain: layout; }

Et définissez toujours les dimensions sur les images :

<img src="your-image.webp" width="440" height="440" />

Sur WooCommerce / PrestaShop, les plugins de carousel tiers (Slick, Swiper mal configuré) sont les premiers coupables. Vérifiez que le conteneur a une hauteur fixe dans le CSS avant le chargement du script.

Le CLS e-commerce se règle à 80 % par des dimensions explicites et des espaces réservés. Pas besoin de refactoriser toute l'architecture.

Erreur #3 - Scripts tiers qui bloquent l'interaction (INP)

L'INP e-commerce est la métrique la plus difficile à corriger - et la plus souvent ignorée. Depuis mars 2024, c'est pourtant un Core Web Vital officiel.

Le problème : chaque clic sur "Ajouter au panier", chaque ouverture de menu, chaque interaction déclenche du code JavaScript. Si le main thread est occupé par des scripts tiers, la réponse visuelle dépasse 200 ms. L'utilisateur perçoit le site comme lent.

Chatbots, pixels marketing, A/B testing

J'ai vu cette erreur sur des dizaines de sites e-commerce. Les coupables habituels :

La correction :

1. Chargez les scripts tiers en async - jamais de manière synchrone dans le head. Évitez également le defer : si votre code interne (menu, panier) attend cet événement pour s'initialiser, un 3rd party en defer peut créer un SPOF fonctionnel : le site s'affiche, mais plus rien ne répond au clic.

2. Retardez les scripts non critiques après la première interaction utilisateur :

// Charger le chatbot uniquement après le premier clic
document.addEventListener('click', () => {
  loadChatbot();
}, { once: true });

3. Auditez via Chrome DevTools → onglet Performance → cherchez les "Long Tasks" déclenchées par vos scripts tiers

4. Supprimez ce qui n'est pas utilisé - un pixel Pinterest actif sur un site qui ne fait pas de campagnes Pinterest, c'est du gaspillage pur

Sur les sites Shopify avec 15–20 apps installées, le Total Blocking Time dépasse souvent 2 secondes. Chaque app ajoute du JS. Faites le tri.

Erreur #4 - Lazy load sur l'image LCP

Paradoxe fréquent : l'équipe optimise les performances en ajoutant loading="lazy" à toutes les images. Y compris l'image LCP. Résultat : le Largest Contentful Paint explose.

Le problème : loading="lazy" empêche le navigateur de charger l'image tant que l'utilisateur n'est pas proche de la zone. Sur mobile, l'image hero est souvent above-the-fold - elle devrait charger immédiatement. Or, tant que la page n'est pas construite par le navigateur, elle ne sait pas si une image sera visible dans le viewport ou non, ce qui décale le téléchargement de cette dernière.

Règle simple :

• Images above-the-fold → loading="eager", soit la valeur par défaut de l'attribut (+ fetchpriority="high" si l'image est le LCP de la page)
• Images below-the-fold → loading="lazy"

Sur les plateformes comme PrestaShop ou WooCommerce, les thèmes appliquent souvent loading="lazy" à toutes les images via une règle globale. Vérifiez le template de votre image hero et surchargez l'attribut explicitement.

Outil de diagnostic : PageSpeed Insights identifie directement l'élément LCP et signale si loading="lazy" est appliqué à tort.

Erreur #5 - Polices web non préchargées (CLS + LCP)

Les polices web sont une source double de problèmes : elles retardent le LCP (texte invisible pendant le chargement) et génèrent du CLS (le texte se redimensionne quand la police se charge - FOUT).

Symptômes :

• font-display: swap sans preload → CLS visible au chargement
• Polices chargées depuis Google Fonts sans optimisation → requête externe bloquante
• Plusieurs graisses et styles chargés inutilement

La correction :

<!-- Dans le <head>, avant tout autre CSS -->
<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>

Et dans le CSS :

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-var.woff2') format('woff2');
  font-display: optional; /* Évite le FOUT sur les connexions lentes */
}

font-display: optional est plus agressif que swap : si la police n'est pas disponible immédiatement depuis le cache, le navigateur utilise la police système. Zéro CLS, zéro LCP retardé. C'est le bon choix pour les e-commerces qui veulent des web vitals propres.

Conseil pratique : hébergez vos polices en local plutôt que depuis Google Fonts. Une requête externe de moins, une connexion DNS de moins = un LCP amélioré (et une conformité RGPD renforcée).

Erreur #6 - Filtres et tri produits qui génèrent du CLS

Les pages catégories avec filtres dynamiques sont des cas classiques de CLS e-commerce. L'utilisateur arrive, les filtres se chargent en JS, et toute la grille produits descend de 200 px. Score CLS : 0,35. Raté.

Ce qui se passe :

1. Le HTML initial s'affiche sans les filtres
2. Le JS injecte la barre de filtres au-dessus de la grille
3. La grille est poussée vers le bas → layout shift

La correction :

Réservez l'espace pour les filtres dès le rendu initial :

.filters-container { min-height: 56px; /* hauteur connue de la barre de filtres */ }

Ou mieux : rendez les filtres côté serveur (SSR) pour qu'ils soient présents dans le HTML initial. Sur PrestaShop par exemple, des modules de facettes SSR existent et évitent ce problème.

Pour les skeleton loaders sur la grille produits :

.product-grid { min-height: 800px; /* hauteur approximative de la grille */ }

Règle d'or : ne jamais injecter du contenu au-dessus d'un contenu existant après le chargement initial. Si vous devez le faire, réservez l'espace à l'avance.

Erreur #7 - TTFB élevé sur les pages catégories (LCP)

Le TTFB (Time to First Byte) n'est pas un Core Web Vital officiel, mais c'est le premier maillon du LCP. Un TTFB de 2 secondes rend un LCP ≤ 2 s mathématiquement impossible.

Sur les pages catégories e-commerce, le TTFB explose pour des raisons spécifiques :

• Requêtes SQL complexes pour récupérer les produits filtrés
• Aucun cache HTML pour les utilisateurs anonymes
• Rendu serveur complet à chaque requête (pas de CDN)
• Modules tiers qui s'exécutent côté serveur à chaque page

Objectifs TTFB pour les pages catégories :

• < 400 ms : excellent
• 400–600 ms : très bon
• 600–800 ms : acceptable
• > 800 ms : à corriger en priorité

Actions concrètes :

1. Activez le cache HTML pour les pages catégories anonymes - c'est la correction avec le meilleur ratio effort/impact
2. Utilisez un CDN (Cloudflare, Fastly) pour servir les ressources depuis des edge nodes proches des utilisateurs
3. Optimisez les requêtes SQL : indexez les colonnes utilisées dans les filtres (prix, catégorie, stock)
4. Activez le cache objet (Redis, Memcached) pour les requêtes de catalogue répétitives
5. Passez à PHP 8.3+ si vous êtes sur PrestaShop ou WooCommerce - le gain de performance est réel

Sur Shopify ou SFCC, la performance de l'infra est gérée par votre fournisseur. Si votre TTFB est élevé malgré tout, regardez du côté du code de votre site :

• Les Liquid snippets ou de les templates complexes peuvent ralentir le temps de réponse du serveur
• Les développements sur-mesure ou des apps qui injectent du contenu côté serveur peuvent également impacter le TTFB.

Un autre problème régulièrement observé est la localisation de l'infrastructure. Si votre marque est mondiale, une seule infra localisée en Europe sera plus lente pour les utilisateurs en Australie ou en Amérique du Sud à cause de la distance à l'origine.

Comment auditer les Core Web Vitals de votre e-commerce

Avant de corriger quoi que ce soit, mesurez. Les données de terrain (field data) priment toujours sur les données de laboratoire.

Outils indispensables :

Ces outils sont gratuits et librement accessibles. Ils permettent d'obtenir une idée globale de la performance de votre site e-commerce, mais offrent une vision limitée de votre performance :

• Les configurations de tests en laboratoire (Pagespeed notamment) sont bridées, et non personnalisables.
• Les données RUM récoltées par Google ne sont limitées qu'aux visiteurs sous Chrome Android et Chrome sur appareil Desktop.
• Les données de terrain et de labo sont naïves quant à vos problèmes côté serveur.

À côté de ces outils, il est intéressant de faire appel à un expert web performance e-commerce qui pourra utiliser des outils bien plus avancés, notamment de profiling qui permettent d'optimiser les temps de réponse serveur.

Si vous souhaitez commencer par vous-même, voici un processus d'audit webperf recommandé :

1. Search Console → rapport Core Web Vitals → identifiez les pages "Mauvaises" et "À améliorer"
2. Priorisez par impact business : une page catégorie avec 50 000 visites mensuelles vaut généralement plus qu'une page store locator à 500 visites sur la même période.
3. Chrome DevTools → Performance tab → simulez une connexion 4G lente sur mobile

Vous voulez identifier les causes profondes des performances de votre site ? Que vous utilisiez Shopify, PrestaShop, Sylius ou même SalesForce Commerce Cloud, un audit webperf structuré est la méthode la plus rapide pour obtenir des réponses claires.

Pour comprendre en détail le fonctionnement de chaque métrique, la documentation complète sur les Core Web Vitals couvre les mécanismes de mesure et les seuils officiels.

L'optimisation des core web vitals ecommerce n'est pas un projet ponctuel. Mettez en place un monitoring continu pour détecter les régressions avant qu'elles impactent vos ventes.

FAQ

Sources utiles

• Web Vitals - Documentation officielle Google - définitions, seuils et cycle de vie des métriques
• Core Web Vitals et impact business - Études de cas - cas Vodafone, Tokopedia, Redbus, Cdiscount
• Optimiser le LCP - web.dev - guide technique complet
• Optimiser l'INP - web.dev - guide technique complet
• Optimiser le CLS - web.dev - guide technique complet
• PageSpeed Insights - outil de mesure terrain + labo
• Rapport Core Web Vitals - Google Search Console - données réelles par page