Insight · Performance
Les images sont le seul chantier de performance dont le rendement est garanti
Sur une boutique, les images pèsent presque toujours plus que tout le reste réuni. C'est aussi le seul poste où l'on peut diviser le poids par quatre sans rien changer à l'architecture, sans arbitrage produit, et sans risque de régression fonctionnelle.
Publié le 29 septembre 2026 · 6 min de lecture · Sergio Nokam
Parmi les chantiers de performance qu’on peut proposer à une marque, celui des images occupe une position singulière : c’est le seul dont je peux annoncer le rendement avant de l’avoir commencé. Il ne demande aucun changement d’architecture, il n’exige aucun arbitrage produit — personne n’a besoin de renoncer à une fonctionnalité — et il ne présente pratiquement aucun risque de régression fonctionnelle. Sur une boutique qui sert des images non optimisées, une division du poids par trois à quatre est un résultat ordinaire, pas une performance.
Cette singularité mérite d’être expliquée, parce qu’elle contraste avec le reste du domaine. Réduire le temps de réponse serveur suppose de toucher au rendu ou au cache. Isoler une dépendance suppose de modifier le code. Retirer un widget suppose une décision commerciale1. Les images, elles, se traitent à la couche de diffusion, sans que le code métier ni l’expérience ne changent.
Les quatre corrections
| Correction | Gain typique | Risque | Effort |
|---|---|---|---|
| Format moderne (AVIF/WebP avec repli) | −40 à −60 % du poids | Nul si repli configuré | 1 jour |
| Dimensionnement réel (jeu de tailles) | −50 % sur mobile | Nul | 1 à 2 jours |
| Chargement différé hors écran | −60 à −80 % du poids initial | Réel si mal ciblé | 0,5 jour |
| Dimensions déclarées | Aucun gain de poids | Nul | Quelques minutes |
La dernière ligne ne fait pas gagner un octet et figure quand même au tableau : elle supprime le décalage visuel, qui est la nuisance la plus perceptible par les clients2. Elle se fait en même temps, par le même intervenant, sur les mêmes gabarits.
Le gaspillage le plus répandu : la taille
Si je devais n’en corriger qu’une, ce serait la deuxième.
Le cas typique : une image de produit téléversée en 2000 pixels de large, servie telle quelle, affichée dans une vignette de collection qui fait 400 pixels sur mobile. Le navigateur télécharge l’intégralité du fichier, puis le réduit à l’affichage. Environ 96 % des pixels transférés ne servent à rien.
Ce gaspillage est maximal là où il coûte le plus : sur mobile, où le réseau est contraint et où les écrans sont petits. Et il se multiplie par le nombre de vignettes d’une page de collection.
La correction consiste à générer plusieurs tailles et à laisser le navigateur choisir en fonction de son écran et de sa densité de pixels. Elle est prise en charge nativement par tous les navigateurs modernes et par la plupart des outils de construction, ce qui la rend peu coûteuse à mettre en place.
Servir une image de 2000 pixels dans un emplacement de 400, c’est transférer vingt-cinq fois ce qui est nécessaire. Sur une page de collection, cela se produit vingt fois par chargement.
Le format, gain immédiat et sans arbitrage
La première correction est celle qui demande le moins de réflexion.
Les formats modernes compressent nettement mieux que le JPEG à qualité perçue équivalente. La question de savoir lequel privilégier n’a pas à être tranchée : la bonne configuration sert celui que le navigateur annonce savoir lire, avec un repli vers un format universel. AVIF quand il est accepté, WebP sinon, JPEG en dernier recours.
Le seul point de vigilance porte sur le réglage de qualité. Une compression trop agressive est visible sur les images de produit — textures, dégradés, matières — et une marque qui vend sur l’apparence de ses produits ne peut pas se le permettre. Le réglage se valide à l’œil sur une dizaine d’images représentatives du catalogue, pas sur une valeur théorique.
Le chargement différé, et l’erreur qui l’accompagne
La troisième correction produit le gain le plus spectaculaire sur le poids initial, et elle est celle qu’on applique le plus souvent de travers.
Le principe : ne charger que ce qui est visible à l’ouverture, et laisser le reste arriver au fil du défilement. Sur une page de collection de vingt produits dont trois sont visibles, cela retire l’essentiel du transfert initial.
L’erreur fréquente consiste à l’appliquer partout, y compris à l’image principale de la page. On diffère alors précisément l’élément qui détermine le temps d’affichage perçu, et l’on dégrade la métrique qu’on voulait améliorer. J’ai vu des scores empirer après une optimisation d’images pour cette seule raison.
La règle qui évite ce piège est explicite : chargement immédiat et priorité haute pour ce qui est visible à l’ouverture — typiquement l’image principale d’une fiche produit et les premières vignettes d’une collection — chargement différé pour tout le reste.
Ce que ce chantier ne corrigera pas
Il faut être clair sur la portée, sinon la déception est garantie.
L’optimisation d’images agit sur un segment précis du temps d’affichage : celui du téléchargement de la ressource. Si le retard vient d’un temps de réponse serveur élevé, d’un blocage de rendu par des scripts, ou d’un délai avant que le navigateur ne découvre l’existence de l’image, alors diviser le poids par quatre ne déplacera presque rien3.
C’est pourquoi le relevé de la chronologie réseau précède le chantier, même sur un poste aussi prévisible que celui-ci. Cinq minutes de mesure disent si les images sont le sujet ou un détail.
Pourquoi commencer par là quand même
Malgré cette réserve, je propose presque toujours ce chantier en premier sur une boutique qui n’a jamais rien optimisé, et pour une raison qui n’est pas seulement technique.
C’est le seul chantier de performance qui ne demande d’arbitrage à personne. Pas de fonctionnalité à retirer, pas de widget à négocier avec le marketing, pas d’architecture à revoir. Il produit un résultat mesurable en quelques jours, sur des gabarits existants, sans risque.
Et ce résultat sert ensuite d’argument pour les chantiers suivants, qui eux exigeront des arbitrages. Une équipe qui a démontré un gain sur les images obtient plus facilement le budget d’isolation des dépendances — l’inverse est rarement vrai.
Footnotes
-
Sur la manière de faire remonter un arbitrage de performance à qui de droit, voir Un budget de performance sert à refuser des fonctionnalités. ↩
-
Sur les dimensions déclarées et les autres causes du décalage visuel, voir Le décalage visuel est la seule métrique que vos clients nomment. ↩
-
Sur la décomposition du temps d’affichage en quatre segments et sur le relevé qui l’établit, voir LCP sur mobile : l’image héro est rarement le coupable. ↩
Questions fréquentes
Quel gain attendre d'une optimisation d'images ?
Sur une boutique qui sert des images non optimisées, une division du poids par trois à quatre est courante, sans perte visible de qualité. Le gain est réel mais il porte sur un segment précis du temps d'affichage : celui du chargement de la ressource. Si le retard vient de la réponse serveur ou d'un blocage de rendu, l'optimisation d'images ne le corrigera pas.
Faut-il servir du WebP ou de l'AVIF ?
Les deux, avec une bascule automatique selon ce que le navigateur accepte, et un repli en JPEG. AVIF compresse davantage mais son encodage est plus lent et sa prise en charge légèrement moins universelle. La bonne configuration ne choisit pas : elle laisse le navigateur annoncer ce qu'il sait lire et sert le format le plus efficace disponible.
Le chargement différé peut-il nuire ?
Oui, s'il est appliqué à l'image principale de la page. Différer l'image la plus visible retarde précisément l'élément qui détermine le temps d'affichage perçu. La règle : chargement immédiat et priorité haute pour ce qui est visible à l'ouverture, différé pour tout le reste. Appliquer le différé partout est une erreur fréquente qui dégrade la métrique qu'on cherchait à améliorer.
Faut-il redimensionner les images à la source ?
Idéalement, on sert plusieurs tailles et on laisse le navigateur choisir selon l'écran. Servir une image de 2000 pixels de large dans un emplacement qui en fait 400 gaspille l'essentiel du transfert, particulièrement sur mobile où le réseau est le plus contraint. C'est le gaspillage le plus répandu et le plus simple à corriger.