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 peut augmenter le taux de conversion de 8%.

Ce guide vous explique comment mesurer, comprendre et optimiser les 3 métriques clés : LCP, INP (ex-FID) et CLS.

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. Mais attention : 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 throttlée
• Recommandations spécifiques : liste les opportunités d'optimisation avec impact estimé

Google Search Console

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

• Identifie les groupes d'URLs problématiques
• Basé sur les données CrUX (utilisateurs Chrome réels)
• Mise à jour quotidienne avec latence de ~1 semaine
• Seuil minimal : URLs 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. 4 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 3000x3000px pour un affichage 800px
• 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'avoir un LCP <2.5s.

• Hébergement performant : évitez les mutualisés cheap, préférez un VPS ou 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, queries N+1 éliminées
• TTFB cible : <200ms idéal, <600ms 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 inline : extraire le CSS above-the-fold et l'inliner 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 audiences internationales

Optimiser l'INP : réactivité aux interactions

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

Principales causes de mauvais INP

• JavaScript main thread bloqué : tâches longues qui monopolisent le thread
• Event handlers lourds : traitement complexe dans onClick, onScroll
• Re-rendus React massifs : composants qui se re-rendent inutilement
• Third-party scripts : chat, analytics qui s'exécutent de façon synchrone

Techniques d'optimisation INP

• Décomposer les tâches longues : setTimeout pour yield au main thread
• Debounce/throttle : limiter la fréquence d'exécution des handlers (scroll, resize)
• Web Workers : déporter les calculs lourds hors du main thread
• Code splitting par route : charger le JS seulement quand 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, carousels

Optimiser le CLS : stabilité visuelle

Le CLS pénalise les pages où les éléments "sautent" pendant le chargement. Très frustrant pour l'utilisateur (clic sur le mauvais bouton).

Causes courantes de CLS élevé

• Images sans dimensions : le navigateur ne réserve pas l'espace avant le 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 géré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 font système puis swap
• 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 fonts web créent souvent du CLS et ralentissent le LCP. Stratégie optimale :

• Preload des fonts critiques : `<link rel="preload" as="font" type="font/woff2" href="/fonts/main.woff2" crossorigin>`
• font-display: swap : affiche immédiatement la font système, swap quand la custom font est prête
• Limiter le nombre de fonts : 2 families max, 2-3 weights max
• Subsetting : ne charger que les caractères utilisés (latin uniquement si site FR)
• Héberger localement : 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-1500px avant l'entrée dans le viewport
• Combine avec aspect-ratio : éviter le CLS quand l'image se charge

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% meilleur que Gzip, supporté par tous les navigateurs modernes

Checklist Core Web Vitals pour e-commerce

• ✅ LCP <2.5s : image hero optimisée (WebP/AVIF), preloaded, fetchpriority=high
• ✅ INP <200ms : 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 <600ms : hébergement performant, cache serveur, CDN
• ✅ Images : formats modernes, compression, lazy loading (sauf LCP)
• ✅ Fonts : preload, subsetting, max 2 families
• ✅ CSS : critique inline, reste async/defer
• ✅ JS : defer, code splitting, limiter les third-party
• ✅ Mesure : PageSpeed Insights (Field Data), Search Console, monitoring continu
• ✅ Mobile-first : optimiser d'abord mobile (75%+ du trafic e-commerce)

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