Images de site : le format qui divise le poids par dix

Une photo prise avec un téléphone pèse plusieurs mégaoctets. Sur la page, elle s'affiche sur 600 ou 800 pixels de large. Tout ce qui se trouve entre ces deux nombres est du poids que votre visiteur télécharge sans jamais le voir, sur une connexion qu'il paie souvent au forfait.

Cet article traite un seul levier : les images, leur format, leurs dimensions et le moment de leur chargement. Pour situer ce levier parmi les autres causes de lenteur — serveur, scripts, polices, services tiers — Site trop lent : les cinq causes réelles donne la vue d'ensemble et l'ordre de traitement.

Pourquoi une image pèse trop lourd

Une image lourde l'est pour trois raisons, souvent cumulées. Les dimensions d'abord : une photo de 4 000 pixels de large affichée dans une colonne de 700 pixels transporte cinq à six fois plus de pixels que nécessaire. Le format ensuite : un logo enregistré en PNG transparent ou une photo exportée en PNG pèsent bien plus lourd que le même contenu dans un format conçu pour la photographie. La compression enfin : un export réglé au maximum de qualité, ou un fichier recompressé trois fois au fil des retouches.

Le format se choisit selon ce que l'image contient.

Format	Pour quoi	Ce qu'il pèse
JPEG	Photos, sans transparence	Correct : c'est l'ancien standard du web
PNG	Transparence, captures d'écran, aplats de couleur	Lourd dès qu'il y a des nuances ou une photo
WebP	Photos, avec ou sans transparence	Plus léger que le JPEG à qualité comparable
SVG	Logos et icônes dessinés	Quelques kilo-octets, net à toutes les tailles

Sur l'écart entre le JPEG et le WebP, les chiffres publiés par Google sur son propre format annoncent un quart à un tiers de poids en moins, à qualité comparable. C'est utile, mais ce n'est pas là que se trouve le facteur dix. Il vient de l'addition des gestes décrits plus bas.

Convertir ses images en WebP : la méthode

Le WebP est lu par tous les navigateurs courants depuis plusieurs années. La question ne porte donc plus sur la compatibilité générale, mais sur les appareils anciens qui subsistent chez une partie de votre audience. On verra comment couvrir ce cas avec un format de repli.

Un outil en ligne pour commencer

Squoosh, l'outil de conversion de Google, fonctionne directement dans le navigateur, sans installation. Vous déposez une image, vous choisissez le format WebP, vous réglez la qualité, et le poids avant et après s'affiche côte à côte. Commencez par trois images représentatives de votre site : une photo, un visuel avec du texte, une vignette de produit. Si la différence se voit dans l'aperçu, remontez la qualité d'un cran.

En ligne de commande, quand il y en a beaucoup

Pour un catalogue de plusieurs centaines d'images, un utilitaire en ligne de commande fait le travail sans intervention. La commande de base tient sur une ligne.

cwebp -q 80 photo.jpg -o photo.webp

Le paramètre -q 80 règle la qualité, et le fichier de sortie porte le même nom avec la nouvelle extension. Pour traiter un dossier entier d'un coup, une boucle suffit.

for f in *.jpg; do cwebp -q 80 "$f" -o "${f%.jpg}.webp"; done

Deux précautions avant de lancer ce genre de commande. Travaillez sur une copie du dossier, jamais sur l'unique exemplaire de vos images, et vérifiez le résultat sur un échantillon avant de convertir le reste.

Dans un CMS ou un logiciel de gestion de contenu

Les extensions de conversion existent pour WordPress et les autres logiciels courants. Deux points se vérifient avant d'en installer une. D'abord, l'extension convertit-elle seulement les nouveaux envois, ou propose-t-elle de convertir la bibliothèque existante ? Beaucoup ne traitent que les images suivantes, ce qui laisse vos anciennes photos aussi lourdes qu'avant. Ensuite, l'extension sert-elle réellement le fichier WebP aux visiteurs, ou convertit-elle dans un coin sans que la page change ? Le test est simple : ouvrez une page et cherchez les fichiers .webp dans le panneau réseau.

Le format de repli, pour les appareils les plus anciens, se déclare dans le code de la page : une balise d'image à deux sources, le WebP proposé en premier, le JPEG ensuite. Le navigateur prend le premier format qu'il comprend, et les dimensions comme le texte alternatif restent portés par la balise d'image finale.

<picture>
  <source srcset="/assets/img/photo.webp" type="image/webp">
  <img src="/assets/img/photo.jpg" width="800" height="600" alt="Description">
</picture>

Cette écriture n'est utile que si vous gardez les fichiers JPEG d'origine. Si vous les supprimez, le repli ne protège plus rien.

Redimensionner à la taille d'affichage réelle

La règle est simple à énoncer : la largeur en pixels d'un fichier ne devrait pas dépasser le double de la largeur qu'il occupe à l'écran. Le double, parce que les écrans denses affichent deux pixels physiques par pixel logique ; au-delà, vous payez pour des pixels que personne ne verra jamais.

Le cas le plus fréquent est la photo prise au téléphone : 4 000 pixels de large, affichée dans une colonne de 700. Redimensionnée à 1 400 pixels, elle conserve toute sa netteté sur les écrans denses et perd l'essentiel de son poids. C'est souvent ce seul geste qui produit le plus gros écart, avant même de parler de format.

Comment trouver la bonne largeur

Ouvrez la page, faites un clic droit sur l'image, puis inspectez l'élément : la largeur d'affichage apparaît dans le panneau. Multipliez par deux, et vous avez la largeur d'export. Trois tailles couvrent la plupart des sites : la grande image d'en-tête d'un article, l'image courante dans le texte, et la vignette d'une carte. Notez ces trois largeurs une fois pour toutes, et exportez toujours à l'une de ces trois valeurs.

L'ordre compte : redimensionnez d'abord, convertissez ensuite, pour ne jamais manipuler un fichier inutilement lourd.

Prenons un exemple, à vérifier sur vos propres fichiers. Une photo de 4 000 pixels exportée en JPEG peut peser plusieurs mégaoctets. La même photo redimensionnée à 1 400 pixels puis convertie en WebP à qualité 80 descend souvent sous les quelques centaines de kilo-octets. Le facteur dix du titre vient de là : du cumul du redimensionnement, du format et du chargement différé, sur une page qui contient plusieurs images. Sur vos images, mesurez les deux étapes séparément, vous verrez laquelle pèse le plus dans votre cas.

Déclarer les dimensions pour éviter les décalages

Une image sans dimensions déclarées réserve zéro espace avant son arrivée. Le texte se place, puis l'image arrive et pousse tout vers le bas. Le visiteur qui lisait perd sa ligne, et s'il s'apprêtait à cliquer, il clique à côté. Google mesure ces décalages sous le nom de stabilité de mise en page, avec un seuil public de 0,1.

La correction tient en deux attributs : width et height, renseignés avec les dimensions réelles du fichier. Le navigateur calcule le rapport entre les deux et réserve la place avant même de télécharger l'image. Le style de la page continue de gérer la largeur fluide : les attributs servent au calcul, pas à l'affichage.

Pour les éléments qui ne sont pas des images — une vidéo intégrée, une carte, un cadre de réservation — la même logique s'applique avec un rapport d'aspect déclaré. Et si vos attributs sont faux, le résultat est pire que leur absence : la place réservée ne correspond pas à l'image, et le décalage se produit quand même. Recopiez les dimensions du fichier, pas celles que vous croyez avoir exportées.

Différer le chargement des images hors écran

La plupart des visiteurs ne descendent pas jusqu'au bas de la page. L'attribut loading="lazy" demande au navigateur d'attendre que l'image approche de la zone visible pour la télécharger.

Une règle ne doit jamais être enfreinte : l'image principale du premier écran ne se diffère pas. C'est elle qui donne au visiteur l'impression que la page est arrivée, et c'est elle que mesure l'indicateur d'affichage du contenu principal. Sur cette image-là, on fait l'inverse : on la déclare prioritaire pour qu'elle parte en premier.

Un autre attribut, decoding="async", évite que le décodage d'une image bloque l'affichage du reste. Le piège le plus courant vient des extensions qui appliquent le chargement différé à toutes les images, y compris le logo de l'en-tête. Le symptôme est trompeur : la page semble se construire plus vite, mais l'image principale arrive plus tard qu'avant.

Utiliser srcset quand c'est utile

L'attribut srcset permet de proposer plusieurs largeurs de fichier et de laisser le navigateur choisir celle qui correspond à l'écran. Un téléphone prend la version légère, un grand écran dense prend la version large. C'est utile sur les images dont la largeur d'affichage change selon l'appareil : la grande image d'un article, une bannière pleine largeur.

Ce n'est pas utile partout. Sur un logo de largeur fixe ou une vignette de carte qui ne bouge pas, un seul fichier bien dimensionné fait le travail, et il est plus simple à maintenir. Multiplier les versions d'une image, c'est multiplier le stockage et les fichiers à regénérer à chaque changement.

Quand vous l'utilisez, faites-le complètement. Trois largeurs suffisent en général — une pour le téléphone, une pour la tablette, une pour l'ordinateur. À côté de srcset, il faut décrire la largeur d'affichage dans l'attribut sizes. Sans cette description, le navigateur suppose que l'image occupe toute la largeur de l'écran et choisit le fichier le plus lourd : exactement l'inverse du but recherché. C'est l'erreur la plus fréquente sur ce point.

Si votre site publie beaucoup d'images, la génération de ces versions se fait à l'envoi, par le logiciel ou l'extension, plutôt qu'à la main. Un geste automatisé une fois vaut mieux qu'une discipline qui s'oublie au troisième article.

Vérifier le résultat sans rien casser

La vérification commence par une mesure, dans le panneau réseau du navigateur, en filtrant sur les images : additionnez le poids transféré et comparez avec le chiffre relevé avant vos changements. Regardez ensuite l'indicateur d'affichage du contenu principal sur mobile.

Vient le contrôle visuel, et il ne se fait pas sur un écran de téléphone. Une image trop compressée se voit sur les visages, sur les dégradés de ciel et sur le texte incrusté dans un visuel. Ouvrez l'ancienne et la nouvelle version à leur taille réelle, côte à côte, et comparez. Si la différence se voit, remontez la qualité d'un cran : quelques kilo-octets ne valent pas un visuel abîmé.

Pensez à vider le cache. Si un service de diffusion se trouve devant votre site, il continue de servir les anciens fichiers tant qu'on ne lui demande pas de les oublier : vous compareriez deux fois la même chose. Les visiteurs déjà venus peuvent aussi garder l'ancienne version un moment.

Gardez enfin vos originaux dans un dossier hors du site. Une image recompressée plusieurs fois perd de la qualité à chaque passage, et il n'existe aucun moyen de revenir en arrière sans le fichier de départ. Une fois le travail terminé sur l'ordinateur, il reste une dernière épreuve, celle du terrain : Rendre son site utilisable sur un téléphone d'entrée de gamme explique comment tester sur un vrai appareil modeste, celui de vos visiteurs.

FAQ — images, formats et poids