Ce sont vos images, pas votre JavaScript, qui pèsent lourd

L'affirmation

Sur un site de contenu ou de commerce typique, les images représentent la majorité des octets transférés — habituellement de 55 % à 75 % — et le correctif est une étape de construction qu'on configure une fois, pas une fonctionnalité qu'on loue à un fournisseur. Des équipes passent des mois à débattre du poids de leur cadriciel tout en livrant une photographie d'en-tête de 2,4 Mo qui aurait pu peser 140 ko sans différence visible.

Mesurez d'abord votre propre répartition

Ouvrez l'onglet réseau, filtrez par type et lisez les totaux. Ou depuis un terminal, à partir de votre propre sortie de construction :

du -sh public/images public/assets/js
find public/images -type f -size +500k | head -20

Cette seconde commande raconte généralement toute l'histoire. Si elle renvoie vingt fichiers, vous avez vingt problèmes qu'un seul après-midi réglera.

Les trois changements, par ordre de rendement

1. Encodez en AVIF avec un repli JPEG. Une photographie de 3000 pixels de large en JPEG qualité 85 pèse environ 1,2 Mo. La même image en AVIF qualité 50 fait typiquement de 120 à 200 ko et reste indiscernable à distance normale de lecture. Le WebP se situe entre les deux, autour de 300 ko, avec une prise en charge universelle : il constitue un palier intermédiaire raisonnable.

npx sharp-cli -i hero.jpg -o hero-1600.avif resize 1600 --format avif --quality 50
npx sharp-cli -i hero.jpg -o hero-1600.webp resize 1600 --format webp --quality 78

2. Cessez d'envoyer des images d'ordinateur aux téléphones. C'est le changement au plus fort effet et celui qu'on saute le plus souvent. Un téléphone dont la fenêtre fait 390 pixels de large en densité double a besoin d'une image de 780 pixels. Lui envoyer votre original de 2400 pixels gaspille environ 85 % des octets.

<img
  src="hero-1200.jpg"
  srcset="hero-600.avif 600w, hero-1200.avif 1200w, hero-2000.avif 2000w"
  sizes="(max-width: 700px) 100vw, 60vw"
  width="1200" height="675"
  alt="Plancher d'entrepot avec rayonnage">

L'attribut sizes est celui qu'on rate. Il décrit la largeur de mise en page de l'image, pas celle de la fenêtre. S'il manque, le navigateur suppose 100vw et choisit la plus grande variante, ce qui annule tout l'exercice.

3. Fixez explicitement la largeur et la hauteur de chaque image. Pas pour les octets, pour la stabilité de la mise en page. Sans elles, le navigateur ne peut pas réserver l'espace et la page se réorganise à l'arrivée de chaque image. C'est la cause dominante des mauvais scores de décalage cumulatif, et la corriger ne coûte rien.

Le comportement de chargement compte autant que le poids

Deux attributs, appliqués à des images différentes :

• loading="lazy" sur tout ce qui se trouve sous la ligne de flottaison. Sur une page de catégorie comptant 40 vignettes de produits, cela peut à lui seul réduire le transfert initial de 80 %, puisque la plupart des visiteurs ne défilent jamais au-delà des six premières.
• fetchpriority="high" sur l'unique image qui constitue le plus grand élément visible d'emblée, et jamais loading="lazy" sur celle-là. Charger votre image d'en-tête en différé la retarde jusqu'à la fin de la mise en page, ce qui dégrade directement la mesure que vous vouliez améliorer.

Mettez en cache agressivement grâce aux empreintes

Une fois optimisée, une image ne devrait être téléchargée qu'une seule fois par visiteur, à vie. Placez une empreinte de contenu dans le nom de fichier et servez-la avec un en-tête immuable d'un an :

location ~* \.(avif|webp|jpg|png)$ {
    add_header Cache-Control "public, max-age=31536000, immutable";
}

La directive immutable demande au navigateur de ne pas revalider, même lors d'un rechargement forcé. Ce n'est sûr qu'avec des noms de fichiers à empreinte : si vous servez logo.png avec cet en-tête, vous ne pourrez pas changer le logo avant un an.

Quand un service d'images payant vaut son prix

L'optimisation à la construction couvre les images que votre équipe maîtrise. Elle ne couvre pas le contenu téléversé par les utilisateurs : une place de marché où des vendeurs versent des photos prises au téléphone recevra des fichiers de 8 Mo avec toutes les métadonnées de l'appareil. Dans ce cas, un service de redimensionnement à la volée — ou un petit service maison utilisant sharp derrière un cache — est la bonne réponse, puisqu'on ne peut pas reconstruire le site chaque fois que quelqu'un met une chaise en vente.

À quoi s'attendre

Une page de contenu portant 3,1 Mo d'images retombe typiquement entre 350 et 600 ko après encodage AVIF, tailles adaptatives et chargement différé. Sur la connexion à 1,6 Mbit/s de notre calcul précédent, quinze secondes de transfert deviennent moins de trois. Aucun changement de cadriciel, aucune réécriture, aucune nouvelle facture mensuelle : une étape de construction et cinq attributs sur une balise présente dans HTML depuis 1993.