Images responsives : le chantier de performance au meilleur retour sur investissement

Sur la majorité des sites vitrines et e-commerce, les images représentent la moitié à deux tiers du poids des pages. C'est aussi le chantier de performance le plus rentable : les techniques sont standardisées, les gains sont mesurables, et rien n'oblige à refondre le site pour les appliquer. Voici les quatre leviers, dans l'ordre où nous les appliquons.

1. Servir le bon format

JPEG et PNG ont trente ans. WebP les remplace avantageusement dans la quasi-totalité des cas (25 à 35 % plus léger à qualité égale, supporté partout depuis des années), et AVIF va plus loin encore (souvent 50 % de gain sur JPEG), au prix d'un encodage plus lent. La balise <picture> laisse le navigateur choisir le meilleur format qu'il supporte :

<picture>
  <source srcset="/img/produit.avif" type="image/avif" />
  <source srcset="/img/produit.webp" type="image/webp" />
  <img src="/img/produit.jpg" alt="Fauteuil en chêne massif" width="800" height="600" />
</picture>

La nuance : convertir tout un catalogue à la main ne passe pas à l'échelle. En pratique, ce travail revient soit à la chaîne de build, soit à un service de redimensionnement à la volée (self-hosted ou CDN d'images). Les deux approches se valent ; la seconde coûte un abonnement ou un service de plus à opérer, la première allonge les builds.

2. Servir la bonne taille

Envoyer une image de 2400 px de large à un téléphone qui l'affiche sur 360 px gaspille 90 % des octets. L'attribut srcset décrit les variantes disponibles, sizes la place que l'image occupera :

<img
  src="/img/produit-800.jpg"
  srcset="/img/produit-400.jpg 400w, /img/produit-800.jpg 800w, /img/produit-1600.jpg 1600w"
  sizes="(max-width: 640px) 100vw, 50vw"
  alt="Fauteuil en chêne massif"
  width="800"
  height="600"
/>

Le navigateur choisit seul la variante adaptée à l'écran et à la densité de pixels. Trois à quatre largeurs suffisent ; en générer quinze complique le cache pour un gain marginal.

3. Charger au bon moment

loading="lazy" diffère le chargement des images hors écran — une ligne, gain immédiat sur les pages longues. Avec une exception importante : jamais sur l'image principale visible au chargement. La différer dégrade le LCP au lieu de l'améliorer ; c'est l'erreur la plus courante de ce chantier. À l'inverse, l'image du haut de page mérite fetchpriority="high".

<!-- Image de héros : prioritaire, jamais lazy -->
<img src="/img/hero.avif" fetchpriority="high" alt="…" width="1200" height="600" />

<!-- Images sous la ligne de flottaison : différées -->
<img src="/img/galerie-3.avif" loading="lazy" alt="…" width="600" height="400" />

4. Réserver l'espace

Une image sans width et height fait sauter la mise en page quand elle arrive — c'est la première cause de mauvais CLS. Déclarer les dimensions (le CSS peut ensuite les rendre fluides avec max-width: 100%; height: auto;) permet au navigateur de réserver l'espace avant le chargement.

Ce que ce chantier ne fera pas

Restons honnêtes sur les limites. Optimiser les images ne corrigera ni un serveur lent, ni un JavaScript envahissant, ni un tunnel de commande défaillant. Et le gain dépend du point de départ : un site déjà servi en WebP avec des tailles raisonnables n'a plus grand-chose à y gagner. D'où l'intérêt de mesurer avant : si les images pèsent 70 % de vos pages, ce chantier est prioritaire ; si elles en pèsent 15 %, regardez ailleurs.

Ce qu'il faut retenir

Formats modernes, tailles adaptées, chargement différé sauf en haut de page, dimensions explicites : quatre techniques standard, sans dépendance à un prestataire, qui réduisent typiquement le poids des pages de 40 à 60 % quand elles n'étaient pas appliquées. C'est le premier chantier que nous recommandons après un diagnostic — précisément parce qu'il est mesurable, borné et sans risque fonctionnel.