Les photos de produits sont habituellement la chose la plus lourde sur la page d’une boutique — plus lourdes que le thème, les scripts et les polices réunis. Une photo de 12 mégapixels tout droit sortie d’un téléphone se mesure en mégaoctets, pas en kilooctets. Multipliez ça par six angles sur une fiche produit, plus une grille de vignettes sur la page de catégorie au-dessus, et une boutique peut finir par déplacer bien plus de données que ce que l’acheteur voit réellement à l’écran. La solution n’est pas d’avoir moins de photos, ni de moins bonnes. C’est d’avoir des photos dimensionnées et formatées pour ce dont un navigateur a besoin, pas pour ce qu’un appareil photo produit par défaut.
Rien de tout ça n’exige une refonte ou une nouvelle plateforme. Trois changements — les dimensions, le format et la façon dont le fichier est livré — font presque tout le travail, et l’ordre compte : s’y prendre dans le mauvais ordre, c’est passer un après-midi sur le réglage qui économise le moins.
D’où vient vraiment le poids
La plupart des boutiques surchargées partagent la même habitude : le fichier original téléversé est bien plus gros que l’espace où il s’affiche. Une photo d’appareil photo de 4000 px de large, affichée dans un emplacement de 600 px sur la fiche produit, transporte plus de 40 fois les données de pixels que la page n’affichera jamais — un original de 12 mégapixels contre un emplacement qui montre environ 0,3 mégapixel. Le navigateur doit quand même télécharger le fichier au complet avant de pouvoir le réduire.
WooCommerce, par exemple, enregistre trois tailles pour chaque photo de produit téléversée — une vignette carrée de 300 px pour les pages en grille, une image de 600 px pour la fiche produit et une vignette de galerie de 100 × 100 — et les génère automatiquement à partir de ce que vous téléversez. Si le fichier original est déjà propre et raisonnablement dimensionné, les tailles générées restent légères. Si l’original est un fichier d’appareil photo de 12 mégapixels, certains thèmes et blocs le demandent quand même directement, et le redimensionnement automatique ne vous sauve pas. L’habitude la plus sûre : téléverser une image proche de la plus grande taille que votre design affiche réellement, pas la plus grande que votre appareil photo peut produire.
Le format bat le curseur de compression
La plupart des gens pensent qu’« optimiser une image », c’est glisser un curseur de qualité de 90 % à 60 %. Le choix du format fait bouger l’aiguille bien davantage. Le WebP est généralement 25 à 35 % plus léger qu’un JPEG ou un PNG comparable, à qualité visuelle égale, selon les indications web.dev de Google, qui citent cette fourchette tirée du déploiement de Facebook lui-même — et tous les grands navigateurs vendus aujourd’hui le décodent nativement, donc plus besoin de maintenir une logique de repli. L’AVIF peut réduire les fichiers encore davantage, mais il prend plus de temps à encoder et son support navigateur reste un cran derrière le WebP — il convient donc mieux aux images principales qu’à un catalogue de milliers de UGS, où le temps d’encodage finit par s’accumuler.
| Format | Le mieux pour | Compromis |
| JPEG | Photos, large support hérité | Plus lourd que le WebP à qualité égale |
| PNG | Transparence, graphiques plats | Beaucoup plus lourd pour les photos |
| WebP | Défaut pour la plupart des photos produits | Rares lacunes de navigateurs, cas limites |
| AVIF | Images principales, pages à faible trafic | Plus lent à encoder à grande échelle |
| SVG | Logos, icônes | Inutilisable pour les photos |
Pour un travail manuel sur une poignée d’images, Squoosh — un outil gratuit conçu par l’équipe Chrome de Google — permet de glisser un fichier, de comparer la version compressée côte à côte avec l’original, et d’exporter en WebP ou en AVIF sans rien installer. Pour un catalogue de centaines ou de milliers de UGS, c’est un travail pour un plugin ou une étape de compilation, pas pour un onglet de navigateur.
Pourquoi ce n’est pas juste du ménage
Le poids des images se reflète directement dans le Largest Contentful Paint, l’un des Core Web Vitals de Google. Sur une fiche produit, l’élément LCP est presque toujours la photo principale du produit, et la documentation même de Google fixe 2,5 secondes comme seuil pour un « bon » score — mesuré sur de vrais visiteurs, pas dans un test de laboratoire. Une image principale non optimisée est la raison la plus fréquente pour laquelle les boutiques ratent ce chiffre, et les Core Web Vitals font partie des signaux d’expérience de page que Google utilise pour le classement.
Le volet comportement des utilisateurs est plus ancien, mais il ne s’est pas inversé. Dans une analyse de 2016 portant sur environ 3 700 sites mobiles, les propres données analytiques de Google ont trouvé qu’un peu plus de la moitié des visites étaient abandonnées une fois qu’une page dépassait trois secondes de chargement. C’est une donnée datée, et elle ne visait pas spécifiquement le commerce en ligne — mais les pages n’ont fait qu’alourdir depuis, pas s’alléger, donc la pression qu’elle décrit n’a pas disparu. Ce qu’un acheteur décide de continuer à regarder dans les trois premières secondes dépend de ce qui s’est réellement affiché d’ici là.
Dimensionnement et livraison, sans plugins supplémentaires
Deux choses font presque tout le reste du travail, et ni l’une ni l’autre n’exige plus de code sur mesure :
- Les images adaptatives (
srcset) laissent le navigateur choisir quelle taille télécharger selon l’écran du visiteur — un téléphone ne récupère pas le même fichier qu’un moniteur de bureau. La plupart des thèmes WordPress et Shopify actuels le génèrent automatiquement, une fois que les images sous-jacentes existent en plusieurs tailles. - Le chargement différé natif (
loading="lazy") retarde les images sous la ligne de flottaison jusqu’à ce qu’un visiteur défile jusqu’à elles — une fonction maintenant intégrée aux navigateurs plutôt que simulée par un plugin.
Un CDN s’occupe du dernier morceau : livrer le même fichier optimisé depuis un serveur physiquement plus proche de l’acheteur. Tous les plans Shopify incluent la livraison par CDN — le CDN de la vitrine est pris en charge par Cloudflare — alors que les boutiques WooCommerce se retrouvent habituellement derrière Cloudflare, BunnyCDN ou un fournisseur semblable que vous choisissez vous-même. La plateforme que vous utilisez a déjà pris certaines de ces décisions pour vous — on couvre ce compromis plus en détail dans notre comparatif WooCommerce et Shopify pour les boutiques en ligne.
Ce qui a tendance à défaire la solution plus tard
L’optimisation des images n’est pas un réglage qu’on active une fois pour toutes. Les deux moments où elle se défait discrètement :
- Une migration de plateforme ou de thème. Les anciennes images sont réimportées à leur résolution d’appareil photo d’origine, parce que l’outil de migration copie des fichiers, pas des réglages.
- Un nouveau membre de l’équipe qui téléverse des photos. Sans une taille et un format documentés, le prochain lot de photos de produits se retrouve en ligne exactement comme l’appareil photo les a exportées.
Vérifier une poignée de fiches produits récemment ajoutées après l’un ou l’autre de ces événements permet de rattraper la majorité des dégâts avant qu’ils ne se répandent dans tout le catalogue. Une migration, c’est aussi le moment où ça cesse d’être une simple question de plugin : si un passage à une nouvelle plateforme ou à un nouveau thème a déjà réimporté tout un catalogue à la résolution d’appareil photo, régler ça correctement fait partie d’une refonte de commerce électronique, pas quelque chose qu’un plugin de compression corrige après coup.
Dimensionner les images au moment du téléversement, plutôt que de les corriger page par page plus tard, suit le même principe « quand A se produit, faites B » que tout processus qui mérite d’être automatisé — et que ça vaille la peine de le mettre en place dépend de la fréquence réelle d’arrivée de nouvelles photos.
Si le système d’images de votre boutique a besoin de plus qu’un plugin — une vraie refonte de la façon dont les photos sont dimensionnées, livrées et générées au téléversement — c’est le genre de chose qu’on traite en développement de site de commerce électronique, où notre construction standard est chiffrée à prix fixe dès le départ, pas à l’heure. Et si vous ne savez pas si la solution est un réglage, un nouvel hébergeur ou une refonte plus large, c’est une question légitime à nous poser directement — contactez-nous.
