Core Web Vitals pour E-commerce : Guide Pratique

Depuis mai 2021, les Core Web Vitals (CWV) sont un facteur de ranking officiel de Google. Pour les sites e-commerce, l'impact est double : SEO + conversions. Une amélioration de 0,1 seconde du temps de chargement augmente le taux de conversion de 8 %.

Les 3 Core Web Vitals expliqués

Google évalue l'expérience utilisateur avec 3 métriques quantifiables :

1. LCP : Largest Contentful Paint

Mesure : temps pour afficher le plus grand élément visible dans la zone au-dessus de la ligne de flottaison.

• ✅ Bon : <2.5 secondes
• ⚠️ À améliorer : 2.5-4 secondes
• ❌ Mauvais : >4 secondes

Pour les e-commerces, le LCP est souvent l'image produit principale ou le hero banner de la homepage.

2. INP : Interaction to Next Paint (remplace FID)

Mesure : délai entre une interaction utilisateur (clic, tap) et la mise à jour visuelle de la page.

• ✅ Bon : <200 millisecondes
• ⚠️ À améliorer : 200-500 ms
• ❌ Mauvais : >500 ms

L'INP remplace le FID (First Input Delay) depuis mars 2024. Il est plus strict car il mesure toutes les interactions, pas seulement la première.

3. CLS : Cumulative Layout Shift

Mesure : stabilité visuelle de la page. Quantifie les décalages inattendus d'éléments pendant le chargement.

• ✅ Bon : <0.1
• ⚠️ À améliorer : 0.1-0.25
• ❌ Mauvais : >0.25

Problème classique e-commerce : une bannière promo qui se charge après et décale tout le contenu vers le bas.

Outils de mesure : comprendre vos métriques

Google fournit des outils gratuits pour auditer vos Core Web Vitals. Attention toutefois à la distinction données lab vs données terrain.

PageSpeed Insights (PSI)

URL : https://pagespeed.web.dev/

• Données terrain (Field Data) : basées sur le Chrome UX Report, utilisateurs réels des 28 derniers jours
• Données lab (Lab Data) : simulation Lighthouse sur connexion 4G bridée
• Recommandations spécifiques : liste des opportunités d'optimisation avec impact estimé

Google Search Console

Rapport Signaux web essentiels : vue d'ensemble de toutes vos URL groupées par statut (Bon/À améliorer/Mauvais).

• Identifie les groupes d'URL problématiques
• Basé sur les données CrUX (utilisateurs Chrome réels)
• Mise à jour quotidienne avec latence d'environ une semaine
• Seuil minimal : URL avec trafic suffisant (données anonymisées)

Lighthouse (Chrome DevTools)

Audit local dans votre navigateur Chrome : F12 → Onglet Lighthouse → Generate report.

• Données lab uniquement (simulation)
• Très utile pour tester avant/après une optimisation
• Mode mobile recommandé : Google privilégie le mobile-first indexing

Chrome UX Report (CrUX)

Dataset BigQuery public avec toutes les métriques CWV agrégées. Pour utilisateurs avancés (requêtes SQL).

Optimiser le LCP : affichage rapide du contenu principal

Le LCP est souvent le plus gros problème des e-commerces. Quatre axes d'optimisation majeurs :

1. Optimisation des images (élément LCP #1)

Si votre LCP est une image produit ou un hero banner :

• Formats modernes : WebP (80-90 % plus léger que JPEG) ou AVIF (encore mieux)
• Compression : TinyPNG, Squoosh, ImageOptim pour réduire sans perte visible
• Dimensions adaptées : ne servez pas une image 3000x3000 px pour un affichage 800 px
• Preload de l'image LCP : `<link rel="preload" as="image" href="hero.webp">`
• Priority hint : `<img fetchpriority="high">` sur l'image LCP
• CDN avec cache : Cloudflare, Fastly pour servir depuis le edge le plus proche

2. Réduire le temps de réponse serveur (TTFB)

Le Time To First Byte impacte directement le LCP. Si votre serveur met 2 secondes à répondre, impossible d'atteindre un LCP <2,5 s.

• Hébergement performant : évitez les mutualisés bas de gamme, préférez un VPS ou un serveur dédié
• Cache serveur : Varnish, Redis pour servir du HTML précalculé
• CDN : distribuez vos assets statiques mondialement
• Base de données : index SQL optimisés, requêtes N+1 éliminées
• TTFB cible : <200 ms idéal, <600 ms acceptable

3. Éliminer les ressources bloquantes

CSS et JavaScript bloquent le rendu par défaut. Stratégies pour les charger sans bloquer le LCP :

• CSS critique inliné : extraire le CSS above-the-fold et l'injecter dans le <head>
• Async/defer pour JS : `<script defer>` ou `<script async>` selon la dépendance
• Code splitting : charger seulement le JS nécessaire par page
• Minification : CSS et JS minifiés (remove whitespace, comments)
• Tree-shaking : éliminer le code non utilisé (Webpack, Vite)

4. Utiliser un CDN

Un Content Delivery Network réduit la latence en servant vos ressources depuis un serveur géographiquement proche de l'utilisateur.

• Réduction typique du TTFB : 30 à 70 %
• Services : Cloudflare (gratuit/payant), Fastly, AWS CloudFront
• Bénéfice majeur pour les audiences internationales

Optimiser l'INP : réactivité aux interactions

L'INP mesure la réactivité de votre site. Un INP élevé signifie des utilisateurs frustrés : les clics ne répondent pas immédiatement.

Principales causes de mauvais INP

• Main thread JavaScript bloqué : tâches longues qui monopolisent le thread
• Event handlers lourds : traitement coûteux dans onClick, onScroll
• Re-rendus React massifs : composants qui se re-rendent inutilement
• Scripts tiers : chat, analytics exécutés de façon synchrone

Techniques d'optimisation INP

• Décomposer les tâches longues : setTimeout pour rendre la main au main thread
• Debounce/throttle : limiter la fréquence des handlers (scroll, resize)
• Web Workers : déporter les calculs lourds hors du main thread
• Code splitting par route : ne charger le JS que lorsqu'il est nécessaire
• Limiter le JavaScript tiers : désactiver les scripts non critiques (A/B testing, heatmaps)
• Lazy loading de composants : React.lazy() pour les modals et carrousels

Optimiser le CLS : stabilité visuelle

Le CLS pénalise les pages dont les éléments « sautent » pendant le chargement. Frustrant pour l'utilisateur, qui clique sur le mauvais bouton.

Causes courantes de CLS élevé

• Images sans dimensions : le navigateur ne réserve pas l'espace avant chargement
• Publicités/embeds : bannières qui s'insèrent après le contenu initial
• Fonts web : FOIT (Flash of Invisible Text) ou FOUT (Flash of Unstyled Text)
• Injections dynamiques : bannières promo, notifications qui décalent le contenu
• Animations : transitions CSS mal maîtrisées

Solutions pour stabiliser la mise en page

• Toujours spécifier width et height sur les images : `<img width="800" height="600">`
• Aspect-ratio CSS : réserver l'espace avant le chargement `.img-container { aspect-ratio: 16/9; }`
• Précharger les fonts critiques : `<link rel="preload" as="font" href="font.woff2">`
• font-display: swap : évite le FOIT, affiche la police système puis bascule
• Réserver l'espace pour les ads : conteneur avec min-height fixe
• Éviter d'insérer du contenu au-dessus : notifications/bannières en position sticky ou fixed

Exemple HTML pour images responsives sans CLS :

```html <img src="produit.jpg" alt="..." width="800" height="600" style="max-width: 100%; height: auto;"> ```

Le navigateur calcule automatiquement le ratio et réserve l'espace, même en responsive.

Chargement des fonts : éviter le FOIT/FOUT

Les polices web créent souvent du CLS et ralentissent le LCP. Stratégie optimale :

• Preload des polices critiques : `<link rel="preload" as="font" type="font/woff2" href="/fonts/main.woff2" crossorigin>`
• font-display: swap : affiche immédiatement la police système, bascule quand la police personnalisée est prête
• Limiter le nombre de polices : 2 familles max, 2 à 3 graisses max
• Subsetting : ne charger que les caractères utilisés (latin uniquement pour un site FR)
• Hébergement local : ne pas dépendre de Google Fonts (latence + RGPD)

CSS avec font-display :

```css @font-face { font-family: "MyFont"; src: url("/fonts/myfont.woff2") format("woff2"); font-display: swap; } ```

Lazy loading : charger les images hors écran

Le lazy loading natif permet de ne charger les images que quand elles entrent dans le viewport.

• Attribut HTML : `<img loading="lazy">` (support navigateur 95 %+)
• Ne PAS lazy-load l'image LCP : elle doit charger immédiatement
• Seuil de chargement : 1000 à 1500 px avant l'entrée dans le viewport
• À combiner avec aspect-ratio : évite le CLS au moment du chargement

Sur une fiche produit avec 15 images, lazy-loadez les images 3 à 15. Les 2 premières (hero + zoom) doivent charger immédiatement.

Optimisation JavaScript : code splitting et defer

Le JavaScript est souvent le principal coupable des mauvais CWV sur les e-commerces modernes (React, Vue, etc.).

Code splitting par route

Ne chargez que le JS nécessaire pour la page courante :

• React.lazy() + Suspense : lazy loading de composants
• Dynamic imports : `import("./module").then(...)` pour charger à la demande
• Route-based splitting : chaque route a son propre bundle
• Vendor splitting : séparer node_modules du code app

Defer et async

• defer : télécharge en parallèle, exécute après le HTML parse (ordre préservé)
• async : télécharge et exécute dès que prêt (ordre non garanti)
• Recommandation : defer pour vos scripts, async pour analytics/ads indépendants

CDN et cache : servir rapidement les assets

Un CDN bien configuré améliore tous les CWV en réduisant la latence.

• Images, CSS, JS : cache longue durée (1 an) avec versioning
• HTML : cache court (5-10min) ou pas de cache + revalidation
• Headers cache optimaux : `Cache-Control: public, max-age=31536000, immutable` pour assets hashés
• Compression Brotli : 15 à 20 % de mieux que Gzip, supporté par tous les navigateurs modernes

Checklist Core Web Vitals pour e-commerce

• ✅ LCP <2,5 s : image hero optimisée (WebP/AVIF), préchargée, fetchpriority=high
• ✅ INP <200 ms : JS optimisé, pas de tâches longues bloquantes, code splitting
• ✅ CLS <0,1 : dimensions sur toutes les images, font-display: swap, pas d'injection dynamique above fold
• ✅ TTFB <600 ms : hébergement performant, cache serveur, CDN
• ✅ Images : formats modernes, compression, lazy loading (sauf LCP)
• ✅ Polices : préchargement, subsetting, 2 familles maximum
• ✅ CSS : critique inliné, reste async/defer
• ✅ JS : defer, code splitting, limitation des scripts tiers
• ✅ Mesure : PageSpeed Insights (Field Data), Search Console, monitoring continu
• ✅ Mobile-first : optimiser d'abord le mobile (75 %+ du trafic e-commerce)

Appliquez ces optimisations progressivement, mesurez avec PSI après chaque changement, puis surveillez l'évolution dans Search Console sur 4 à 6 semaines.