Votre site est lent et vous ne le savez pas : anatomie d'un site e-commerce à 4 secondes

4 secondes. C’est le temps que vous donnez à vos clients pour partir.

Quand un directeur e-commerce me dit “notre site est rapide”, je lui demande de sortir son téléphone et d’ouvrir sa homepage en 4G.

La réaction est toujours la même : un silence gêné.

72% des sites e-commerce français que j’ai audité ces 2 dernières années ont un LCP (Largest Contentful Paint) supérieur à 3 secondes sur mobile. Google considère ça comme “mauvais”. Vos clients aussi.

Et le pire ? Chaque seconde au-delà de 2,5 secondes vous coûte entre 7 et 12% de conversion selon les données Google. Un site à 4 secondes de LCP perd potentiellement 30 à 40% de son chiffre d’affaires comparé à un site à 1,5 seconde.

L’audit qui a tout changé

Je vais vous raconter l’audit d’un site e-commerce réel. Un retailer mode avec 15 millions d’euros de CA annuel, 2 millions de visiteurs par mois, et un site Shopify Plus customisé.

Leur conviction : “Notre site est correct, on a fait des optimisations l’an dernier.”

Nos mesures (Lighthouse sur mobile, 4G simulée) :

• LCP : 4,2 secondes (mauvais — seuil Google : 2,5s)
• FID/INP : 380ms (mauvais — seuil : 200ms)
• CLS : 0,32 (mauvais — seuil : 0,1)
• Score Lighthouse : 28/100

Ils étaient choqués. Parce qu’en fibre depuis leur bureau parisien, le site semblait rapide.

Première leçon : ne testez jamais votre site depuis votre bureau. Testez depuis un smartphone en 4G, ou utilisez les données réelles de vos utilisateurs (CrUX data dans Search Console).

Coupable n°1 : Les images (1,8 seconde gaspillée)

La page d’accueil chargeait 47 images dont 38 n’étaient pas visibles sans scroller. Poids total : 12 Mo.

Ce qu’on a trouvé

• Le hero banner : un JPEG de 2,4 Mo (4000x2000 pixels) alors que l’espace d’affichage fait 375x200 sur mobile
• Aucun lazy loading : toutes les images chargées immédiatement, même celles en bas de page
• Format JPEG partout : aucune image en WebP ou AVIF
• Pas de srcset ni de sizes : la même image géante servie sur mobile et desktop

Les corrections

• Conversion en WebP avec fallback JPEG : réduction de 40% du poids
• Lazy loading natif (loading="lazy") sur toutes les images sauf le hero
• Responsive images avec srcset : 3 tailles (mobile 400px, tablet 800px, desktop 1600px)
• Le hero en AVIF optimisé : de 2,4 Mo à 85 Ko

Gain : 1,8 seconde de LCP récupérée.

Coupable n°2 : Le JavaScript (1,2 seconde gaspillée)

Le site chargeait 3,2 Mo de JavaScript au premier chargement. Dont une bonne partie n’était jamais exécutée.

Ce qu’on a trouvé

• Hotjar, Google Tag Manager, Facebook Pixel, Pinterest Tag, TikTok Pixel, Criteo — 6 scripts tiers totalisant 800 Ko
• Un slider en homepage qui importait une librairie de 250 Ko pour afficher… 3 images
• Du jQuery (87 Ko) chargé pour un seul composant qui utilisait $('.menu').toggle()
• Des polyfills pour IE11 toujours inclus (IE11 est mort depuis 3 ans)

Les corrections

• Scripts tiers chargés en defer et regroupés dans GTM avec un délai de 3 secondes après le load
• Remplacement du slider par du CSS pur (scroll-snap) : de 250 Ko à 2 Ko
• Suppression de jQuery : les 10 lignes réécrites en vanilla JS
• Suppression des polyfills IE11
• Code splitting agressif : chaque page ne charge que son propre JS

Gain : 1,2 seconde récupérée sur le TBT (Total Blocking Time) et l’INP.

Coupable n°3 : Les web fonts (600ms gaspillées)

Le site utilisait 5 variantes de Google Fonts chargées depuis googleapis.com.

Ce qu’on a trouvé

• 5 fichiers de police : Regular, Medium, SemiBold, Bold, ExtraBold
• Chargement depuis un domaine tiers (connection DNS + TLS handshake)
• Pas de font-display: swap : le texte était invisible pendant le chargement des polices (FOIT)
• Un layout shift de 0,15 quand les polices finissaient par charger

Les corrections

• Réduction à 2 variantes (Regular + Bold) — plus que suffisant
• Polices hébergées localement (self-hosted) : suppression du round-trip vers Google
• font-display: swap : le texte s’affiche immédiatement en police système, puis bascule
• Preload de la police principale : <link rel="preload" href="/fonts/inter-regular.woff2" as="font">

Gain : 600ms sur le LCP et CLS réduit de 0,15.

Coupable n°4 : Le serveur (400ms gaspillées)

Le Time to First Byte (TTFB) était à 800ms. Pour un site e-commerce, c’est trop.

Ce qu’on a trouvé

• Pas de CDN correctement configuré (le CDN Shopify était actif, mais les assets custom contournaient le cache)
• Des redirections en chaîne : HTTP > HTTPS > www > page (3 redirections, 150ms chacune)
• Des requêtes API côté serveur non cachées qui interrogeaient la base à chaque page vue

Les corrections

• Configuration correcte du CDN avec cache headers appropriés (max-age 1 an pour les assets versionnés)
• Suppression des redirections chaînées : une seule redirection directe vers la destination finale
• Cache applicatif (Redis) pour les données produits qui ne changent pas toutes les minutes
• Preconnect vers les domaines critiques : CDN, API de paiement, analytics

Gain : TTFB passé de 800ms à 200ms.

Le résultat final

Après 3 semaines de corrections :

Impact business mesuré sur 3 mois :

• Taux de conversion mobile : +23%
• Taux de rebond : -18%
• Pages vues par session : +15%
• CA estimé récupéré : +800 000 euros annualisés pour un investissement de 3 semaines de travail

Les 5 quick wins que vous pouvez faire aujourd’hui

Vous n’avez pas besoin d’un audit complet pour commencer. Ces 5 actions prennent moins d’une journée et couvrent 60% des problèmes :

1. Convertissez vos images en WebP avec un outil comme Squoosh ou le plugin Shopify/WP adapté
2. Ajoutez loading="lazy" sur toutes les images sauf la première visible
3. Différez les scripts tiers : ajoutez defer ou chargez-les après l’interaction utilisateur
4. Vérifiez vos Core Web Vitals dans Google Search Console (données réelles de vos utilisateurs)
5. Supprimez ce que vous n’utilisez plus : polices, librairies JS, plugins, trackers inactifs

Le piège du score Lighthouse

Dernière chose importante : ne vous focalisez pas sur le score Lighthouse.

Lighthouse est un test synthétique en conditions contrôlées. Vos vrais utilisateurs sont sur des smartphones Android milieu de gamme en 4G variable. Les données CrUX (Chrome User Experience Report) dans Search Console reflètent l’expérience réelle.

Un site peut avoir un Lighthouse à 90 et des Core Web Vitals réels médiocres. Et inversement. Optimisez pour les données réelles, pas pour un score.

FAQ

Mon site est sur Shopify, je ne peux pas tout contrôler. Que faire ?

Shopify impose certaines contraintes (leur propre JS framework, les scripts de thème). Mais les leviers restent les mêmes : optimiser les images, limiter les apps Shopify installées (chacune ajoute du JS), choisir un thème léger (Dawn ou Sense), et différer les scripts tiers. Les sites Shopify les plus rapides atteignent un LCP de 1,5 seconde.

Quelle est la différence entre LCP, FCP, et TTFB ?

TTFB (Time to First Byte) mesure la vitesse du serveur. FCP (First Contentful Paint) mesure quand le premier élément visuel apparaît. LCP (Largest Contentful Paint) mesure quand le plus grand élément visible (souvent le hero image) a fini de charger. Le LCP est la métrique la plus corrélée à la perception de vitesse par l’utilisateur.

Les Core Web Vitals impactent-ils vraiment le SEO ?

Oui, mais c’est un signal parmi des centaines. Google ne va pas déclasser un site avec du bon contenu pour un LCP à 3 secondes. En revanche, entre deux sites à contenu équivalent, celui avec de meilleurs Core Web Vitals sera favorisé. L’impact le plus fort est indirect : un site lent = plus de rebond = moins de temps passé = signal négatif pour Google.

À quelle fréquence faut-il auditer les performances ?

Configurez un monitoring continu (SpeedCurve, Calibre, ou simplement les alertes CrUX dans Search Console). Un audit approfondi tous les 6 mois est un bon rythme, plus après chaque refonte majeure ou ajout de fonctionnalité significative. Les performances se dégradent naturellement avec le temps (nouveaux scripts, nouvelles features), il faut donc les surveiller activement.