L'ordre qui rapporte
Dans cet ordre, du gain le plus fort au plus faible : redimensionner à la largeur réellement affichée, servir plusieurs tailles selon l'écran, changer de format, ajuster la compression, différer ce qui n'est pas visible. La première étape se compte en facteurs, les suivantes en pourcentages. Retenez une exception, celle de l'image principale de la page, qui ne doit jamais être différée.
Sur un site moderne, les images représentent le plus souvent la majorité du poids d'une page, loin devant le code et les scripts. C'est donc le poste où une correction produit le plus d'effet. Encore faut-il traiter les choses dans le bon ordre, et l'ordre habituel est presque toujours inversé.
La largeur, avant tout le reste
Prenons un cas que je rencontre chaque semaine. Une photo issue d'un appareil, 4 000 pixels de large, téléversée telle quelle, affichée dans un bloc de 800 pixels. Le navigateur la réduit à l'affichage, mais il a bien fallu la télécharger entièrement.
La surface transportée est alors vingt-cinq fois supérieure à celle affichée. Aucun changement de format ne rattrape un écart pareil. Redimensionner le fichier à la taille utile divise le poids d'un facteur, là où passer de JPEG à WebP le réduit de quelques dizaines de pourcents.
La règle simple que j'applique. Une image ne doit jamais être servie à plus du double de sa largeur d'affichage. Le double, et non l'exact, parce que les écrans à forte densité affichent deux pixels physiques pour un pixel de mise en page. Au-delà du double, vous transportez des pixels que personne ne verra jamais, sur aucun écran.
Servir plusieurs tailles selon l'écran
Une même image ne s'affiche pas à la même largeur sur un téléphone et sur un grand écran. Le HTML permet de déclarer plusieurs versions d'un même visuel et de laisser le navigateur choisir celle qui correspond à sa situation, en combinant l'attribut de jeu de sources et celui des tailles.
Le gain est particulièrement net sur mobile, où l'on économise l'essentiel du poids sur les connexions les plus lentes. Trois déclinaisons suffisent dans la quasi-totalité des cas : une pour le téléphone, une pour la tablette, une pour l'ordinateur.
La plupart des CMS produisent déjà ces déclinaisons automatiquement au téléversement. Ce qu'il faut vérifier est leur utilisation réelle, car il arrive fréquemment qu'un thème ignore ces variantes et serve systématiquement l'image d'origine.
Le format, en second
| Format | Pour quoi | Ce qu'il apporte |
|---|---|---|
| WebP | Photographies et illustrations, usage général | Gain notable sur JPEG à qualité équivalente, prise en charge universelle |
| AVIF | Photographies, quand chaque kilo-octet compte | Gain supérieur à WebP, encodage plus lent, prise en charge un peu moins large |
| JPEG | Photographies, compatibilité maximale | Le repli sûr, traité en détail sur ma page consacrée au format JPG |
| PNG | Captures d'écran, aplats, transparence | Sans perte, donc lourd sur une photographie |
| SVG | Logos, icônes, schémas | Poids minime et netteté à toutes les tailles |
Le PNG explique à lui seul la moitié des pages trop lourdes que j'examine. Une capture d'écran enregistrée en PNG pèse souvent plusieurs mégaoctets, alors que la même en WebP tient dans quelques dizaines de kilo-octets sans différence visible. Le PNG garde son intérêt sur les images à aplats et sur celles qui exigent une transparence, pas sur les photographies.
L'image principale, le cas à ne pas rater
Le chargement différé est une bonne pratique, et elle a une exception. L'image la plus visible en haut de page est généralement l'élément qui définit le signal du plus grand contenu affiché. La différer revient à retarder volontairement la mesure sur laquelle on est évalué.
Ce défaut est devenu extrêmement courant depuis que les extensions appliquent le chargement différé à toutes les images d'un site sans distinction. Deux gestes suffisent à le corriger, retirer l'attribut de différé sur cette image et lui ajouter une priorité de récupération élevée.
Profitez-en pour déclarer les dimensions de chaque image dans le code. Sans elles, le navigateur ne réserve pas la place et la page saute au moment où l'image arrive, ce qui dégrade le signal de stabilité visuelle. Deux attributs suffisent, et ils n'empêchent pas la mise en page adaptative.
Repérer les images à corriger
- Partir des pages qui comptent. Celles qui reçoivent du trafic dans la Search Console. Corriger les images d'une page sans visiteurs n'améliore rien de mesurable.
- Comparer taille servie et taille affichée. Les outils de développement d'un navigateur affichent les deux valeurs au survol d'une image. Un rapport supérieur à deux désigne un candidat immédiat.
- Trier par poids décroissant. Une seule image de trois mégaoctets pèse plus que cinquante images correctes. Le tri par poids concentre l'effort là où il rapporte.
- Vérifier l'image principale. Est-elle différée ? Ses dimensions sont-elles déclarées dans le code ? Les deux se corrigent en une minute chacune.
- Mesurer après. Sur les données réelles de terrain, pas sur un test de laboratoire, et en laissant passer quelques semaines pour que les mesures se renouvellent.
Trois situations où le calcul change
La méthode décrite plus haut couvre la majorité des sites. Trois configurations demandent un traitement différent, et les confondre coûte du temps pour rien.
Le catalogue de plusieurs milliers de fiches. Reprendre les images une à une n'est pas envisageable. Le travail se fait alors en amont, au moment de l'import, avec une règle unique de redimensionnement et de conversion appliquée à tout ce qui entre. Corriger la source coûte une journée, corriger le résultat coûte des semaines.
Le site de photographe ou d'artisan. Ici l'image est le produit, et la compression agressive détruit ce qu'on vend. Gardez une qualité élevée sur les visuels de démonstration, et allez chercher les kilo-octets ailleurs, sur les vignettes et les éléments d'interface. C'est le seul cas où j'accepte des pages nettement plus lourdes que la moyenne.
Le site déjà servi par un réseau de distribution. Beaucoup de ces services transforment les images à la volée, redimensionnement et conversion de format compris, selon des paramètres passés dans l'adresse. Avant d'installer quoi que ce soit, vérifiez ce que fait déjà votre infrastructure, car la fonction est parfois disponible et simplement pas activée.
Les pièges des outils automatiques
Les extensions d'optimisation rendent service et introduisent trois défauts que je retrouve régulièrement.
La compression trop agressive. Un réglage poussé produit des aplats visibles sur les dégradés et un flou sur les visages. Sur un site où l'image vend le produit, c'est un mauvais échange. Un contrôle à l'œil sur cinq visuels après traitement évite la déconvenue.
Les déclinaisons non utilisées. L'outil génère six tailles, le thème sert toujours l'originale. On paie le stockage sans obtenir le gain. La vérification se fait en regardant quelle adresse est réellement chargée sur une page.
Le différé appliqué partout. Y compris à l'image principale, comme évoqué plus haut. C'est le défaut le plus fréquent et le plus coûteux des trois.
Reste un point qui n'a rien de technique. Ces gains de poids ne servent à rien si l'image n'est pas trouvable. Le texte alternatif, la légende et le nom du fichier restent les signaux qui décident de sa visibilité, et ils sont traités sur mes pages consacrées à l'attribut alt et au nom de fichier.
Questions fréquentes
Sources
- Google, « Bonnes pratiques pour les images »
https://developers.google.com/search/docs/appearance/google-images?hl=fr - Google, documentation sur le plus grand élément visible et son optimisation
https://web.dev/articles/lcp?hl=fr - Ordres de grandeur relevés lors d'audits de performance menés sur des sites en production. Consulté le 27 août 2026.