Optimisation de la Vitesse de Site pour le E-commerce

Google mesure l'expérience de page via trois Core Web Vitals : Largest Contentful Paint (LCP), Interaction to Next Paint (INP) et Cumulative Layout Shift (CLS). Chaque indicateur capture un aspect différent de l'expérience utilisateur dans votre boutique, et tous trois alimentent l'algorithme de classement de Google.

Le LCP mesure le temps nécessaire pour que le plus grand élément visible s'affiche, généralement une image héro ou une photo produit. Google attend un LCP inférieur à 2,5 secondes. Pour le e-commerce, le principal coupable est l'imagerie produit non optimisée. Une seule image héro de 3 Mo sur une page catégorie peut pousser le LCP au-delà de 4 secondes sur les connexions mobiles.

L'INP a remplacé le First Input Delay en mars 2024 et mesure la réactivité sur toute la session de page, pas seulement la première interaction. Chaque tapotement, clic et saisie clavier compte. Les sites e-commerce peinent ici à cause du JavaScript lourd des outils d'analyse, widgets de chat et moteurs de recommandation. Chaque script tiers monopolise le thread principal, retardant les interactions utilisateur.

Le CLS suit les décalages de mise en page inattendus pendant le chargement. Sur les pages produit, cela se produit couramment lorsque les images se chargent sans dimensions définies, lorsque des badges de prix s'insèrent après le rendu initial, ou lorsque des avis chargés en différé poussent le contenu vers le bas. Google exige un CLS inférieur à 0,1 pour un score satisfaisant.

Les images représentent 50 % à 70 % du poids total des pages sur la plupart des sites e-commerce. Une page catégorie affichant 40 produits avec des images non optimisées peut facilement dépasser 15 Mo. L'optimisation correcte des images seule peut réduire le temps de chargement de moitié.

Convertissez toutes les images produit au format WebP ou AVIF. Le WebP offre des fichiers 25 % à 35 % plus petits que le JPEG à qualité équivalente, et l'AVIF pousse les économies à 50 %. Tous les navigateurs majeurs supportent maintenant le WebP, et le support AVIF couvre plus de 90 % des utilisateurs. Servez l'AVIF avec un fallback WebP en utilisant l'élément HTML picture.

Redimensionnez les images pour correspondre à leurs dimensions d'affichage. Une vignette produit affichée à 300x300 pixels n'a pas besoin d'un fichier source de 2000x2000. Générez plusieurs tailles au moment du build ou via l'API de transformation d'images de votre CDN. Servez des images 1x aux écrans standard et 2x aux écrans Retina avec les attributs srcset.

Implémentez le chargement différé pour les images sous la ligne de flottaison. La première rangée de produits sur une page catégorie devrait charger immédiatement (chargement eager), tandis que tout le reste devrait utiliser loading="lazy". Cela réduit le poids initial de la page de manière spectaculaire. Une boutique de mobilier que nous avons optimisée est passée de 80 images au chargement initial à 12, faisant chuter le LCP de 4,8 secondes à 1,9 secondes.

La boutique e-commerce moyenne charge 20 à 35 scripts tiers : analytics, cartes de chaleur, widgets de chat, plateformes d'avis, moteurs de recommandation, pixels de retargeting et prestataires de paiement. Chaque script bloque le thread principal, retarde l'interactivité et gonfle le poids de page. L'audit et la gestion de ces scripts constituent l'une des améliorations de vitesse les plus impactantes.

Commencez par cataloguer chaque script chargé sur votre boutique. Ouvrez les DevTools de Chrome, allez dans l'onglet Réseau, filtrez par JS et rechargez la page. Triez par taille et temps de chargement. Vous trouverez presque certainement des scripts qui ne sont plus nécessaires, des trackers dupliqués ou des outils installés pour un test et jamais supprimés.

Différez les scripts non critiques avec l'attribut defer ou async. Les pixels d'analytics et de marketing n'ont pas besoin de charger avant le rendu de la page. Déplacez-les sous la ligne de flottaison ou chargez-les après l'événement DOMContentLoaded. Pour les widgets de chat, retardez l'initialisation jusqu'au scroll de l'utilisateur ou après un délai de 5 secondes.

Envisagez d'utiliser un gestionnaire de tags comme Google Tag Manager avec un chargement basé sur des déclencheurs. Au lieu de déclencher chaque script au chargement de page, configurez des déclencheurs pour que les pixels de retargeting ne se déclenchent que sur les pages produit, les widgets de chat chargent après 10 secondes d'inactivité et les widgets d'avis ne chargent que lorsque la section avis entre dans le viewport. Cette approche a réduit le temps de blocage du thread principal de 40 % sur une boutique d'ameublement que nous avons optimisée.

Le Time to First Byte (TTFB) mesure le temps nécessaire à votre serveur pour répondre avec le premier octet de HTML. Google recommande un TTFB inférieur à 800 millisecondes, mais les meilleurs sites e-commerce atteignent moins de 200 millisecondes. Un TTFB lent retarde tout ce qui suit : le rendu, le chargement des ressources et l'interactivité.

Les hébergements mutualisés ne peuvent pas fournir un TTFB constant pour les boutiques de plus de quelques centaines de produits. Les requêtes de base de données nécessaires pour construire des pages catégories avec filtrage, tri et vérifications de stock exigent des ressources dédiées. Passez à un VPS, un serveur dédié ou une plateforme e-commerce gérée qui gère la montée en charge de l'infrastructure.

Implémentez le cache de page complète pour les pages catégorie et produit. La plupart des pages produit changent rarement, et servir une réponse HTML mise en cache élimine entièrement les requêtes de base de données. Varnish, Redis ou la couche de cache intégrée de votre plateforme peuvent réduire le TTFB de 1,5 seconde à moins de 100 millisecondes pour les pages en cache.

Utilisez un CDN avec cache en périphérie pour servir les assets statiques et les pages en cache depuis des emplacements proches de vos clients. Un CDN réduit la latence de 50 % à 80 % pour les visiteurs géographiquement éloignés. Pour les boutiques internationales, c'est essentiel. Un client britannique accédant à une boutique hébergée aux États-Unis sans CDN ajoute 150 à 250 millisecondes de latence à chaque requête.

Le chemin de rendu critique est la séquence d'étapes que le navigateur suit pour convertir HTML, CSS et JavaScript en pixels affichés. Optimiser ce chemin signifie s'assurer que le navigateur peut afficher du contenu significatif le plus rapidement possible, même pendant que des ressources supplémentaires se chargent encore.

Intégrez votre CSS critique directement dans le head HTML. Le CSS critique est l'ensemble minimum de styles nécessaire pour afficher le contenu au-dessus de la ligne de flottaison. Des outils comme Critical ou Penthouse peuvent l'extraire automatiquement. En intégrant 10 à 15 Ko de CSS critique, le navigateur peut peindre la vue initiale sans attendre le téléchargement des feuilles de style externes.

Préchargez les ressources clés que le navigateur découvre tard dans le processus d'analyse. Les polices web, les images héro et les bundles JavaScript critiques doivent utiliser des balises link rel="preload" dans le head HTML. Sans préchargement, le navigateur ne découvre ces ressources qu'après l'analyse des fichiers CSS ou JavaScript, ajoutant des centaines de millisecondes de délai.

Éliminez les ressources bloquant le rendu en différant le CSS et JavaScript non critiques. Chargez votre feuille de style complète de manière asynchrone en utilisant l'astuce media="print" avec un gestionnaire onload qui bascule vers media="all". Cela permet au navigateur de rendre la page en utilisant le CSS critique intégré pendant que la feuille de style complète se télécharge en arrière-plan.

Pour les boutiques Shopify, les templates Liquid du thème et les blocs d'applications injectent souvent des scripts et styles bloquant le rendu. Auditez votre fichier theme.liquid et déplacez les scripts d'applications non essentiels vers un chargement différé. Chaque ressource bloquant le rendu ajoute 100 à 300 millisecondes au rendu initial.