Une image de 5 Mo sur une fiche produit, et le temps de chargement passe de 2 à 15 secondes. Ça suffit à faire fuir la moitié des visiteurs, alors on ouvre son dossier de photos et on lance une recompression en série. Sauf que cette réaction, aussi logique soit-elle, fait perdre du temps et parfois de la qualité pour rien. Les images pèsent en moyenne entre 60 et 80 % du poids d’une page e-commerce, mais toutes ne pèsent pas de la même façon dans le chargement réel. Avant de toucher au moindre fichier, il faut mesurer.
Le poids d’un fichier n’est pas le poids dans la page
Un JPEG de 800 Ko rangé dans la médiathèque de votre boutique ne coûte pas 800 Ko à chaque visiteur. Il coûte ce que le navigateur télécharge au moment où il en a besoin, dans l’ordre où la page se construit.
Un outil comme referencement-dom.com rappelle régulièrement cette distinction : ce qui compte pour le référencement, c’est le rendu perçu, pas la taille du dossier d’images sur le serveur. Une photo compressée à 150 Ko mais chargée en pleine résolution sur mobile peut ralentir plus qu’une photo de 400 Ko correctement dimensionnée.
Le vrai indicateur s’appelle le LCP, pour Largest Contentful Paint. Il mesure le moment où le plus gros élément visible de la page s’affiche complètement. Sur une fiche produit, c’est presque toujours l’image principale. Google s’en sert comme critère de positionnement officiel, aux côtés des autres Core Web Vitals. Vous pouvez recompresser tout votre catalogue et garder un mauvais LCP si l’image principale reste lourde ou mal servie.
Ce que les DevTools racontent vraiment
Ouvrez l’onglet Réseau, rechargez la page en vidant le cache, puis triez les requêtes par taille décroissante. Vous verrez immédiatement quelles images pèsent le plus, mais aussi lesquelles arrivent trop tard. Une image de 300 Ko qui bloque l’affichage coûte plus qu’une image de 900 Ko chargée en arrière-plan. Ce classement par impact, et non par poids brut, change l’ordre des priorités.
L’onglet Performance complète le tableau. Lancez un enregistrement, puis regardez la timeline : le navigateur vous montre quel élément déclenche le LCP et à quel moment. C’est là que beaucoup de diagnostics basculent. On découvre qu’une bannière promotionnelle de 1,2 Mo, placée en haut de l’accueil, plombe la page d’entrée bien plus que les cinquante fiches produits qu’on s’apprêtait à traiter une par une.
Le rapport Core Web Vitals de Search Console apporte la vision terrain, sur des visites réelles et non plus sur votre machine. Il distingue les pages qui échouent au LCP de celles qui passent, et il regroupe les URL par type. Le problème ? Ce rapport arrive avec du retard et ne dit pas quelle image précise pose problème. Il confirme le symptôme, les DevTools désignent le coupable.
Les signaux qui doivent vous alerter
Un diagnostic utile se joue sur quelques observations simples, faites sur mobile en conditions réelles et non sur la fibre du bureau. Voici ce qui mérite un examen immédiat.
- Le LCP dépasse les 3 secondes sur la majorité des fiches produits, ce qui laisse peu de marge : selon Imagine Développement, c’est la limite au-delà de laquelle l’expérience se dégrade nettement.
- Une seule requête image pèse plus que tout le reste réuni.
- L’image principale est-elle servie en taille réelle alors que l’écran mobile affiche une vignette ?
- Des formats anciens comme le PNG pour des photos de produit, sans raison technique.
- Le serveur met plus de temps à répondre que le navigateur à afficher l’image.
Cette dernière ligne est souvent négligée. Si le TTFB dépasse la seconde, recompresser des images ne servira à rien : le visiteur attend le serveur, pas les fichiers. Il faut régler l’hébergement avant de toucher aux pixels.
Mesurer l’abandon, pas seulement les octets
Près de 50 % des utilisateurs quittent un site si la page met plus de 3 secondes à s’afficher, et après ce même seuil, 40 % des visiteurs ont déjà abandonné selon la source Think with Google citée par Make the Noise et HubSpot. Sur une boutique, ces chiffres se traduisent directement en panier moyen perdu. Une page lente ne se contente pas de mal se positionner, elle vide le tunnel de conversion.
Le lien avec la conversion se vérifie dans vos propres statistiques avant d’être supposé. Croisez le taux de conversion par appareil avec la vitesse moyenne mesurée sur ces mêmes appareils. Si le mobile convertit deux fois moins que le desktop et que son LCP est trois fois plus lent, la corrélation saute aux yeux. Elle ne prouve pas la causalité, mais elle justifie d’investiguer dans cet ordre. Sur ce point, voir aussi notre article sur quelle stratégie efficace garantit un SEO on site Lyon puissant ?.
Un détail compte ici : les outils de mesure de vitesse et les rapports de ventes ne parlent pas le même langage. Les seconds comptent des commandes, les premiers comptent des millisecondes. Il faut faire la traduction soi-même, en comparant des pages de poids comparable et en isolant un type de produit à la fois.
Choisir le bon format, et la bonne taille
Le WebP réduit le poids de 25 à 35 % à qualité visuelle égale, et l’AVIF grimpe jusqu’à 50 % selon Codeur.com. Ces gains sont réels, mais ils ne s’appliquent qu’à des images déjà correctement dimensionnées. Convertir une photo de 4000 pixels de large en AVIF reste une mauvaise idée si elle s’affiche sur 600 pixels. Le format règle la compression, pas le redimensionnement.
La plupart des plateformes e-commerce génèrent plusieurs tailles d’une même image, et il suffit souvent d’activer le bon rendu plutôt que de réencoder à la main. Vérifiez ce que votre thème sert réellement, à quelle résolution, et si le lazy loading est activé partout sauf sur l’image principale. Cette exception est volontaire : charger l’image du LCP en différé revient à retarder son affichage, donc à dégrader la note.
Franchement, le piège classique reste de tout recompresser à 70 % de qualité dans un lot, sans comparer. On gagne du poids, on perd du détail sur les zooms produit, et le client qui agrandit une texture de tissu se retrouve avec une bouillie de pixels. Un réglage par type d’image (photo produit, bannière, vignette) donne de bien meilleurs résultats qu’un traitement uniforme.
Optimiser sans casser le rendu
Une fois le diagnostic posé, la recompression devient chirurgicale. Vous savez quelle image pèse, où elle s’affiche, et si elle intervient dans le LCP. Le travail se limite alors à quelques fichiers, avec une comparaison visuelle avant et après sur un écran de téléphone. Ça prend une heure au lieu d’une journée, et le résultat se mesure dans Search Console quelques semaines plus tard.
Gardez une trace des modifications et de leur effet sur le LCP, page par page. Sans ce suivi, impossible de savoir si le gain vient de la conversion en WebP, du redimensionnement ou du changement d’hébergement décidé au même moment. Le diagnostic initial sert justement de point de référence pour trancher plus tard.
Un chiffre avant un pixel
Recompresser un catalogue entier sans avoir regardé le LCP revient à repeindre une façade avant de vérifier que les fondations tiennent. Le poids d’un fichier ne dit rien du temps d’affichage, et une seule image bien placée peut coûter plus que cinquante autres réunies.
Mesurez, classez par impact, traitez l’image principale d’abord, puis vérifiez sur des visites réelles. La question à vous poser maintenant : savez-vous, à la seconde près, quel élément déclenche le LCP de votre fiche produit la plus visitée ?