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 montrent que la performance peut avoir un effet commercial. Elles ne donnent pas une formule selon laquelle chaque dixième de seconde gagné rapporterait le même pourcentage à toutes les boutiques. Le bon raisonnement consiste à mesurer la page, identifier la cause technique, corriger, puis vérifier l’expérience et l’effet observé.
Voici comment lire les chiffres disponibles, comprendre les Core Web Vitals et répartir les corrections entre configuration, contenu et code.
Vitesse et conversion : ce que les études permettent de dire
Les références suivantes portent sur des contextes différents. Leur intérêt est de montrer des méthodes et des résultats situés, pas de fournir une promesse à recopier dans un devis.
Deloitte : une association observée sur plusieurs marques
L’étude Milliseconds Make Millions, publiée en 2020 et commandée par Google, observe des sites mobiles sur quatre semaines. Dans le retail, une amélioration naturelle de 0,1 seconde est associée à une hausse de 8,4 % des conversions et de 9,2 % du panier moyen dans l’échantillon étudié.
Le mot « associée » compte. Il s’agit d’une étude observationnelle multi-marques, pas d’une règle causale permettant de calculer ton revenu après compression d’une image. Tu peux t’en servir pour justifier l’examen de la performance, pas pour prédire un gain individuel.
Vodafone : un test A/B centré sur la performance
Le cas Vodafone publié sur web.dev décrit deux variantes de landing page identiques sur le plan visuel et fonctionnel. La version optimisée avait un LCP amélioré de 31 %. Le test a mesuré 8 % de ventes supplémentaires dans ce contexte.
L’expérience est plus solide pour attribuer le résultat aux optimisations testées. Elle ne signifie toujours pas que ta fiche produit connaîtra le même effet. L’audience, la page, le niveau de départ et les corrections diffèrent.
Rakuten 24 : une optimisation globale, pas le seul CLS
Rakuten 24 rapporte un test A/B d’un mois avec 33,13 % de hausse du taux de conversion et 53,37 % de revenu supplémentaire par visiteur. La version optimisée améliorait fortement la stabilité visuelle, avec un CLS réduit de 92,72 %, mais aussi d’autres métriques.
Attribuer tout le résultat au seul CLS serait donc excessif. Le test porte sur un ensemble d’optimisations de performance. C’est aussi un bon exemple de distinction entre une corrélation issue des données courantes et un test contrôlé présenté séparément dans le même cas d’étude.
redBus et Portent : garder le périmètre des chiffres
Le cas redBus relie un travail sur la réactivité à une évolution des ventes. L’INP de la page de recherche a été amélioré de 72 % ; le cas rapporte une hausse globale de 7 % des ventes. La mesure technique d’une page et la mesure commerciale de l’ensemble du site n’ont pas le même périmètre.
L’étude Portent mise à jour en 2022 décrit, pour son échantillon e-commerce, un taux de conversion 2,5 fois supérieur à une seconde de chargement par rapport à cinq secondes. Elle porte sur 20 sites, dont six e-commerce, et reste observationnelle. C’est une association à lire avec la méthode, pas une expérience qui isole la vitesse sur ta boutique.
Faire un calcul d’enjeu sans le transformer en 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 ne dit pas qu’un chantier vitesse produira cette hausse. Il sert à comprendre la sensibilité du 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.
Les trois Core Web Vitals, traduits 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 ne mesure pas non plus la durée complète de toutes les requêtes métier ; il renseigne la réponse visuelle à l’interaction. Un bouton peut afficher rapidement un état de chargement alors que le traitement 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 ne résout pas à elle seule un serveur qui tarde à envoyer le document.
PageSpeed Insights : distinguer le laboratoire et le 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. Ce n’est pas une preuve de vitesse ni de lenteur. 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 Shopify, PrestaShop ou WooCommerce 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 qui passent un seuil ne constitue pas un diagnostic individuel.
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.
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 | Contrôles côté contenu ou configuration | Travail technique possible |
|---|---|---|
| Images | Taille des fichiers, dimensions réellement utiles, format proposé par le CMS | Images adaptées aux écrans, priorité de la ressource LCP, ordre de découverte |
| Scripts tiers | Applications encore utilisées, widgets redondants, tags inutiles | Chargement conditionnel, réduction des tâches longues, respect des dépendances |
| Réponse serveur | Offre d’hébergement, cache disponible, mises à jour prévues | Requêtes lentes, cache serveur, génération du HTML |
| Stabilité visuelle | Bandeaux et encarts ajoutés tardivement | Espace réservé aux images, polices et composants dynamiques |
| Checkout | Scripts et modules nécessaires au parcours | Réactivité, erreurs JavaScript, états de chargement et retours de paiement |
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 : un périmètre, une cause, une 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.
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 ?
Il n’existe pas de montant universel. 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. Il ne garantit pas la correction de toutes les interactions lentes, des déplacements de mise en page et des scripts tiers. 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.
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.
L’audit d’une page publique examine son rendu mobile et ordinateur et fournit un diagnostic, des priorités et des instructions. Il ne comprend ni accès à ton code ou à tes comptes, ni optimisation technique réalisée pour toi. L’implémentation et la vérification des changements restent à ta charge. Consulter l’exemple de livrable.
← Retour au blog CRO