Poids des images : redimensionner avant de compresser

Les repères, en trois lignes

Une image d'illustration : moins de 150 Ko. Une grande image de tête : moins de 300 Ko. Une page entière, images comprises : moins d'un méga-octet si possible. Et le geste qui rapporte le plus n'est pas de compresser davantage, c'est de ne plus servir une image de 4 000 pixels dans une colonne de 800.

La largeur réellement servie

Balance, image du poids d'un fichier à maîtriser

Le poids d'une image dépend de sa surface, donc du carré de sa largeur. C'est une conséquence arithmétique dont découle tout le reste, et elle explique pourquoi tant d'efforts de compression donnent si peu.

Largeur du fichier	Surface relative	Poids indicatif d'une photo en WebP
4 000 px, sortie d'appareil photo	25 fois	1 500 à 3 000 Ko
2 000 px	6,25 fois	400 à 700 Ko
1 200 px	2,25 fois	140 à 250 Ko
800 px	1 fois, la référence	60 à 120 Ko
400 px, vignette	0,25 fois	15 à 40 Ko

Autrement dit, diviser la largeur par deux divise le poids par quatre environ. Aucun réglage de compression n'obtient un tel gain, et surtout aucun ne l'obtient sans dégrader l'image. Une photo servie en 4 000 pixels dans une colonne de 800 gaspille environ 96 % de ses octets, quelle que soit la qualité d'encodage choisie.

C'est aussi l'erreur la plus fréquente sur les sites gérés par un CMS, où l'on téléverse le fichier tel qu'il sort de l'appareil et où le thème se contente de le rétrécir en CSS. À l'écran, tout va bien. Sur le réseau, le visiteur mobile télécharge trois méga-octets pour afficher une vignette.

Le contrôle en dix secondes. Ouvrez une page, clic droit sur une image, « Ouvrir l'image dans un nouvel onglet », et regardez les dimensions annoncées par le navigateur dans le titre de l'onglet. Comparez à la largeur à laquelle elle s'affiche réellement. Si l'écart dépasse un facteur deux, vous venez de trouver votre principal gisement d'allègement, et il ne coûte rien en qualité.

Les formats, et ce que chacun fait gagner

Format	Pour quoi	Gain par rapport au JPEG	Remarque
WebP	Photos et illustrations, l'usage courant	25 à 35 % de moins	Reconnu par tous les navigateurs actuels. Le choix par défaut.
AVIF	Photos, quand le poids est critique	Souvent 50 % de moins	Encodage plus lent, très bon rendu à basse qualité
JPEG	Photos, en repli	Référence	Universel, mais dépassé sur le rapport qualité sur poids
PNG	Aplats avec transparence	Souvent bien plus lourd	À réserver aux cas où la transparence est nécessaire. Voir le format PNG.
SVG	Logos, icônes, schémas	Sans commune mesure	Vectoriel : quelques kilo-octets, net à toutes les tailles
GIF	Rien, en pratique	Beaucoup plus lourd	Une courte vidéo pèse dix fois moins qu'un GIF animé. Voir le format GIF.

Sur la qualité d'encodage, un repère utile. Entre 75 et 85, la différence visuelle est imperceptible sur une photo, et le poids chute nettement par rapport à une qualité maximale. Au-delà de 90, vous payez des octets que personne ne verra. En dessous de 65, les aplats de ciel et les dégradés commencent à se marbrer.

Combien doit peser quoi

Usage	Largeur à servir	Poids cible	Seuil d'alerte
Image de tête, pleine largeur	1 600 à 2 000 px	150 à 300 Ko	Au-delà de 500 Ko
Illustration dans un article	800 à 1 200 px	60 à 150 Ko	Au-delà de 250 Ko
Vignette de liste	300 à 500 px	15 à 40 Ko	Au-delà de 80 Ko
Photo de produit	1 000 à 1 500 px	80 à 200 Ko	Au-delà de 300 Ko
Logo	SVG, ou 2 fois la taille d'affichage	Moins de 20 Ko	Au-delà de 50 Ko
Icône	SVG	Quelques Ko	Toute icône en PNG lourd
Page complète		Moins de 1 Mo	Au-delà de 2 Mo

Servir la bonne image à chaque écran

Un téléphone n'a pas besoin de la même image qu'un écran de bureau. L'attribut srcset permet de proposer plusieurs largeurs et de laisser le navigateur choisir, ce qui règle le problème à la racine plutôt que de chercher un compromis unique.

Le principe tient en deux attributs. srcset liste les fichiers disponibles avec leur largeur réelle. sizes indique la largeur à laquelle l'image sera affichée selon la taille de l'écran. Le second est indispensable. Sans lui, le navigateur suppose que l'image occupe toute la largeur de la fenêtre et télécharge donc systématiquement le plus gros fichier, ce qui annule tout le bénéfice. C'est l'erreur d'intégration la plus fréquente sur ce sujet.

En pratique, trois déclinaisons suffisent dans la plupart des cas : une pour les téléphones, une pour les tablettes, une pour les grands écrans. Générer huit variantes complique la production sans gain mesurable.

Chargement différé : sur toutes les images sauf une

L'attribut loading="lazy" retarde le téléchargement d'une image jusqu'à ce qu'elle approche de l'écran. C'est un gain considérable sur une page longue, et une erreur coûteuse quand on l'applique partout.

L'image visible dès l'ouverture ne doit jamais être différée. C'est presque toujours elle qui détermine le Largest Contentful Paint, la métrique que Google chronomètre. La différer revient à retarder volontairement l'élément mesuré. La bonne configuration est l'inverse. Cette image se charge en priorité, avec fetchpriority="high", et tout ce qui se trouve plus bas passe en chargement différé.

Ajoutez systématiquement width et height sur chaque balise image. Le navigateur réserve alors la place avant l'arrivée du fichier, ce qui évite le décalage de mise en page mesuré par le Cumulative Layout Shift. Ces deux attributs restent utiles même quand le CSS redimensionne l'image, puisque seul leur rapport est exploité.

Performance

Les images sont rarement le seul problème

Alléger les images fait gagner beaucoup, puis on découvre les polices chargées depuis trois domaines, les scripts bloquants et le carrousel de la page d'accueil. Le diagnostic complet se fait sur données réelles, pas sur une note.

Voir la vitesse d'affichage

Mesure sur le terrain, pas seulement en laboratoire.

Alléger un site existant, dans le bon ordre

1. Trouver les vingt fichiers les plus lourds
Un crawl du site trié par poids d'image suffit. La distribution est presque toujours la même, avec une poignée de fichiers qui représente la moitié du problème.
2. Redimensionner avant tout
Ramener chaque image à deux fois sa largeur d'affichage maximale au plus. Le gain est là, et il ne coûte rien en qualité perçue.
3. Convertir en WebP
Un quart à un tiers de moins, sans effort visible. Conservez les originaux ailleurs, car on ne revient pas en arrière depuis un fichier compressé.
4. Régler le chargement
Priorité haute sur l'image de tête, chargement différé sur le reste, width et height partout.
5. Mesurer avant et après, sur mobile
Sur un appareil réel ou en simulation de réseau lent. Un gain qui ne se voit que sur une connexion en fibre n'est pas un gain.

Sur un site que je reprends, cette séquence divise couramment le poids des pages par trois, sans qu'aucune image ne paraisse dégradée. Voir aussi compresser une image et optimiser ses images pour le référencement.

Les erreurs qui reviennent

Compresser sans redimensionner. On passe une heure à optimiser des fichiers cinq fois trop larges. Le gain est marginal et la qualité en souffre.
Compter sur le CSS pour rétrécir. max-width: 100% change l'affichage, pas le téléchargement. Le fichier complet transite quand même.
Différer l'image de tête. Le réglage qui dégrade la métrique qu'on cherchait à améliorer.
Oublier sizes avec srcset. Le navigateur télécharge alors la plus grande variante sur tous les écrans.
Servir un PNG pour une photo. Trois à cinq fois le poids d'un WebP équivalent, sans aucun bénéfice.
Utiliser un GIF animé. Une vidéo courte en boucle pèse une fraction du poids pour un rendu supérieur.
Optimiser une fois. Sans réglage automatique côté serveur ou dans le CMS, la prochaine personne qui publie retéléversera un fichier de quatre méga-octets.

Questions fréquentes

Combien doit peser une image sur un site web ?

Une image d'illustration dans un article doit rester sous 150 kilo-octets, une grande image de tête sous 300, une vignette sous 40, et un logo sous 20. Ce sont des repères, pas des règles, et ce qui compte est le total de la page, qu'il vaut mieux garder sous un méga-octet. Une page qui affiche huit images à 400 kilo-octets chacune a un problème, même si chaque image prise isolément paraît raisonnable.

Faut-il compresser ou redimensionner ses images ?

Redimensionner d'abord, et de loin. Le poids d'une image varie avec la surface, donc avec le carré de sa largeur. Une photo de 4 000 pixels de large affichée dans une colonne de 800 pixels gaspille environ 96 % de ses octets, et aucun réglage de compression ne rattrapera cela. Divisez la largeur par deux et vous divisez le poids par quatre environ. La compression vient ensuite, pour gagner les dernières dizaines de pour cent.

Quel format d'image choisir en 2026 ?

WebP pour la quasi-totalité des usages, puisqu'il est reconnu par tous les navigateurs actuels et pèse en général 25 à 35 % de moins qu'un JPEG de qualité visuelle équivalente. AVIF descend encore plus bas, souvent autour de la moitié d'un JPEG, au prix d'un encodage plus lent. Le SVG reste imbattable pour les logos, les icônes et les schémas, puisqu'il est vectoriel et pèse quelques kilo-octets quelle que soit la taille d'affichage. Le PNG ne se justifie plus que pour de la transparence sur des aplats.

Le poids des images influence-t-il le référencement ?

Indirectement, par la vitesse. Le poids n'est pas un critère de classement en lui-même, mais l'image principale est presque toujours l'élément qui détermine le Largest Contentful Paint, l'un des trois signaux Core Web Vitals mesurés par Google. Une image de tête trop lourde dégrade donc directement une métrique que Google observe, et surtout elle fait partir les visiteurs mobiles avant l'affichage, ce qui coûte bien plus cher qu'un signal de classement.

Faut-il activer le chargement différé sur toutes les images ?

Sur toutes sauf une, jamais sur l'image visible dès l'ouverture de la page. Un chargement différé appliqué à l'image de tête retarde exactement l'élément que Google chronomètre, et dégrade le score au lieu de l'améliorer. La bonne configuration consiste à charger cette première image en priorité, avec l'attribut fetchpriority, et à différer tout ce qui se trouve plus bas dans la page.

Pourquoi indiquer width et height sur une image ?

Pour que le navigateur réserve la place avant que l'image n'arrive. Sans ces attributs, le texte s'affiche, puis l'image le pousse vers le bas au moment où elle charge. C'est le décalage de mise en page que mesure le Cumulative Layout Shift, et l'un des défauts les plus agaçants pour un lecteur mobile. Les deux attributs suffisent, même si le CSS redimensionne ensuite l'image, puisque seul le rapport entre les deux est utilisé.

Sources

web.dev, optimiser le Largest Contentful Paint.
MDN, l'élément img : srcset, sizes, loading et fetchpriority.
Google Search Central, bonnes pratiques pour Google Images.