Une page lente peut compliquer l’achat : la photo du produit tarde à apparaître, le panier semble ne pas répondre ou le bouton se déplace au moment du clic. Pour corriger le problème, il faut toutefois aller au-delà d’un score PageSpeed et d’une statistique générale sur les conversions.
Les études établissent que la performance a un effet commercial, sans fournir de taux de change entre millisecondes et chiffre d’affaires. Voici comment les lire, puis comment mesurer ta page, identifier la cause technique et répartir les corrections.
Ce que disent vraiment les études
| Étude | Méthode | Résultat rapporté | Ce qu’elle permet de dire |
|---|---|---|---|
| Deloitte, Milliseconds Make Millions (2020) | Observation multi-marques, sites mobiles, quatre semaines | Retail : 0,1 s gagnée associée à +8,4 % de conversions | Association, échantillon large |
| Vodafone | Test A/B, variantes visuellement identiques | LCP amélioré de 31 %, +8 % de ventes | Attribution solide, sur cette page et cette audience |
| Rakuten 24 | Test A/B d’un mois | +33,13 % de conversion, CLS réduit de 92,72 % | Effet d’un ensemble d’optimisations, pas du seul CLS |
| redBus | Travail sur la réactivité d’une page | INP amélioré de 72 %, +7 % de ventes globales | Mesure technique sur une page, mesure commerciale sur tout le site |
| Portent | Observation de 20 sites, dont six e-commerce | Conversion 2,5 fois supérieure à 1 s contre 5 s | Petit échantillon : un ordre de grandeur |
Retiens la colonne de droite : deux tests contrôlés sur un site donné, trois observations multi-sites. Ces chiffres justifient le travail ; ils ne le chiffrent pas. La suite part donc de ta page.
Les Core Web Vitals pour une boutique
Les Core Web Vitals distinguent chargement, réactivité et stabilité visuelle. Ce sont trois problèmes différents, qui ne se corrigent pas avec le même réglage.
| Mesure | Ce qu’elle décrit | Exemple sur une boutique | Seuil « bon » |
|---|---|---|---|
| LCP | Moment d’affichage du plus grand élément visible éligible | Photo principale ou grand bloc de texte | 2,5 secondes ou moins |
| INP | Délai entre une interaction et la prochaine mise à jour visuelle | Réaction à un ajout au panier ou à l’ouverture d’un menu | 200 millisecondes ou moins |
| CLS | Déplacements inattendus de la mise en page | Bandeau qui pousse le bouton d’achat | 0,1 ou moins |
Ces seuils s’évaluent au 75e percentile, en distinguant mobile et ordinateur. L’idée est de regarder une expérience qui reste bonne pour une large part des chargements observés, plutôt que de se satisfaire d’une moyenne qui masque les plus lents.
Le LCP n’est pas toujours la photo produit : les outils indiquent quel élément a été retenu. L’INP mesure la réponse visuelle à l’interaction, pas la durée du traitement métier : un bouton qui affiche instantanément un état de chargement obtient un bon INP pendant que la requête continue.
Le TTFB, temps avant réception du premier octet, complète le diagnostic. Il ne fait pas partie des trois Core Web Vitals, mais une réponse serveur lente peut retarder tout ce qui suit. Compresser une image traite le poids ; un serveur qui tarde à envoyer le document se traite ailleurs.
PageSpeed Insights : laboratoire et terrain
PageSpeed Insights présente deux familles de données. Lighthouse exécute un test dans un environnement simulé. Les données de terrain, lorsqu’elles sont disponibles, proviennent du Chrome UX Report et couvrent une fenêtre glissante de 28 jours.
Le test de laboratoire est utile pour reproduire un problème et examiner le chargement. Son score ne décrit pas chaque visite réelle. À l’inverse, les données de terrain reflètent une population observée, mais ne couvrent pas tous les navigateurs et ne donnent pas toujours le détail de la cause.
Un score élevé en laboratoire et un résultat dégradé sur le terrain ne sont donc pas contradictoires. Tes visiteurs peuvent avoir d’autres appareils, d’autres réseaux, des paniers différents ou des scripts qui ne s’activent qu’après certaines interactions.
Vérifier si les données concernent la page ou tout le domaine
Quand une URL n’a pas assez de données, PageSpeed peut afficher une agrégation au niveau de l’origine. Cette mesure regroupe alors les pages du domaine concerné. Elle n’établit pas que la fiche produit testée possède exactement les mêmes performances.
Si aucune donnée de terrain n’est disponible, cela peut tenir au volume, à la nouveauté de l’URL ou aux critères du jeu de données. C’est une absence de mesure, à combler par un test de laboratoire. Garde les tests de laboratoire, complète-les par des essais sur appareil et, si nécessaire, par une mesure de terrain que ton équipe mettra en place.
Et pour le référencement ?
Google indique que les Core Web Vitals sont utilisés par ses systèmes de classement, mais qu’obtenir de bons résultats ne garantit pas les premières positions. La documentation sur l’expérience de page replace ces signaux parmi les autres critères.
Il n’est pas utile d’opposer SEO et conversion. Une page plus utilisable peut servir les visiteurs et participer à la qualité technique du site. Ce qui serait trompeur, c’est de garantir une position ou un volume de ventes à partir d’un score.
Comparer les plateformes avec prudence
Les rapports publics comme le chapitre e-commerce du Web Almanac 2024 permettent d’examiner des tendances par plateforme. Ils précisent aussi les limites de détection des technologies et de représentativité des données.
Un classement de plateformes ne répond pas à la question « quelle correction faut-il faire sur mon site ? ». Deux boutiques utilisant le même CMS peuvent avoir des thèmes, des applications, des images, des audiences et des hébergements très différents. Une moyenne nationale ou un pourcentage de sites situe un marché ; ton diagnostic se lit sur tes propres URL.
Sur une plateforme hébergée, une partie de l’infrastructure est gérée par l’éditeur, mais le thème et les applications restent des choix importants. Sur un site auto-hébergé, le serveur, le cache et la base de données peuvent demander des contrôles supplémentaires. Avant d’envisager une migration, identifie le goulot d’étranglement de tes pages.
Pour utiliser un benchmark, note sa date, l’appareil, le pays ou la population retenue, les technologies détectées et le nombre de sites. Ne compare pas un chiffre global desktop d’une année avec une mesure mobile française d’une autre.
Chiffrer l’enjeu sans en faire une prévision
Tu peux construire un scénario pour décider du budget à examiner. Par exemple, une boutique fictive à 30 000 sessions, 2 % de commandes par session et 60 € de panier moyen réalise 36 000 € de revenu sur la période. Une hausse relative hypothétique de 5 % du taux représenterait 30 commandes, soit 1 800 € supplémentaires à panier constant.
Ce calcul sert à comprendre la sensibilité de ton modèle. Pour décider, ajoute le coût, la marge, l’incertitude et la possibilité que la correction améliore l’expérience sans effet commercial mesurable.
Qui peut corriger quoi ?
Certaines actions passent par le contenu ou la configuration. D’autres exigent de comprendre le réseau, l’exécution JavaScript ou le thème. La frontière dépend de tes outils, mais cette répartition évite de confondre « installer un plugin » avec « résoudre la cause ».
| Chantier | Ce que tu peux faire sans développeur | Ce qui demande un développeur |
|---|---|---|
| Images | Réimporter la photo principale à la largeur réellement affichée, au format proposé par ton CMS | Déclarer la photo LCP en priorité haute et la sortir du chargement paresseux |
| Scripts tiers | Désinstaller les applications que personne n’ouvre plus et supprimer les tags de campagnes terminées | Charger le chat et les widgets après l’interaction, découper les tâches longues |
| Réponse serveur | Activer le cache proposé par ton hébergeur et appliquer les mises à jour en attente | Repérer la requête lente de la page catégorie et mettre son résultat en cache |
| Stabilité visuelle | Retirer le bandeau promotionnel inséré en haut de page après le chargement | Réserver la hauteur des images et des encarts, précharger la police du titre |
| Checkout | Désactiver les modules non utilisés dans le tunnel | Corriger les erreurs JavaScript du paiement et afficher un état de chargement au clic |
Le retrait d’un module doit être vérifié : il peut gérer une fonction moins visible mais nécessaire. De même, déplacer un script après le consentement ou le charger de manière asynchrone ne supprime pas son coût d’exécution lorsqu’il finit par s’activer.
L’exemple de la photo principale
Si la photo est l’élément LCP, commence par identifier ce qui retarde son affichage. Le fichier est-il trop lourd ? Découvert seulement après du JavaScript ? En concurrence avec des ressources moins utiles ? Masqué par une animation ?
La méthode d’optimisation du LCP distingue ces étapes. Une image LCP chargée paresseusement peut être découverte trop tard ; à l’inverse, précharger toutes les images dilue la priorité. La correction doit viser la cause mesurée, puis être testée sur les formats d’écran concernés.
Par où commencer : périmètre, cause, vérification
Choisis quelques pages représentatives : une fiche produit importante, une catégorie et une étape de commande que tu peux tester dans un contexte autorisé. Leur importance doit venir du parcours et des données dont tu disposes, pas de l’idée que le checkout est toujours le seul endroit rentable à accélérer.
- Mesure avant de modifier. Garde les conditions du test, les données de terrain disponibles et les éléments qui ralentissent.
- Choisis une cause concrète. « Photo principale découverte après le chargement du script de galerie » est une cible plus exploitable que « PageSpeed est orange ».
- Définis la correction et la vérification. Ce qui doit changer, ce qui doit continuer à fonctionner et les appareils à couvrir.
- Rejoue les tests après la modification. Vérifie aussi les interactions, l’accessibilité et les fonctions métier.
- Observe la suite. Les données glissantes CrUX intègrent progressivement les nouvelles visites. Une fenêtre entièrement postérieure à la correction évite de mélanger trop longtemps les deux états.
Tu n’as pas besoin d’attendre 28 jours pour savoir si un fichier est plus léger ou si un bug est corrigé. Cette fenêtre concerne la lecture agrégée du terrain. Pour attribuer un effet commercial, il faut en plus une mesure cohérente des achats et un protocole adapté.
Si plusieurs changements sont lancés en même temps que des promotions ou une nouvelle acquisition, un simple avant/après ne séparera pas leurs effets. Un test A/B peut aider lorsque les conditions et le volume le permettent.
Relier la performance au reste de la page
Une page rapide peut encore présenter une offre incompréhensible. Une bonne lecture CRO associe performance, clarté, preuves et prochaine étape. Le guide d’audit CRO e-commerce décrit ce travail d’ensemble.
Questions fréquentes
Quel temps de chargement viser ?
Utilise les seuils des Core Web Vitals comme repères techniques, avec une lecture mobile et ordinateur. Regarde aussi les tâches réellement réalisées : une page peut afficher rapidement son contenu tout en répondant mal au panier.
Combien rapporte une seconde gagnée ?
Le coût dépend entièrement de la cause identifiée. Les cas étudiés montrent des effets possibles dans leurs contextes. Sur ton site, distingue un scénario financier, une amélioration technique observée et un gain commercial mesuré.
Un module de cache suffit-il ?
Il peut aider certains temps de réponse ou certaines ressources, selon ses fonctions. Les interactions lentes, les déplacements de mise en page et les scripts tiers se traitent séparément. Identifie d’abord la métrique et sa cause.
Dois-tu migrer de CMS pour gagner en vitesse ?
Pas sur la seule base d’un classement. Un thème, une image ou un ensemble de modules peut expliquer une partie importante du problème. Une migration coûteuse mérite un diagnostic de ton installation et de ses contraintes.
← Retour au blog CRO