Redimensionner des images pour le web : tailles, Retina et srcset

Mis à jour le: June 28, 2026

J'ai redimensionné la même photo de héros de quatre manières et j'ai mesuré la différence : un JPEG caméra de 4.2MB, servi tel quel dans une zone d'affichage de 800px, est devenu un WebP de 94KB sans perte visible de qualité. Redimensionner les images pour le web représente le gain de poids de page le plus important possible, et cela repose principalement sur quatre décisions : la taille d'affichage, le facteur rétine, le format et la compression. Voici le flux de travail que j'utilise sur tous les sites que je déploie.

Réponse rapide : comment devriez-vous redimensionner vos images pour le web ?

Redimensionnez chaque image pour qu'elle ait environ deux fois la largeur à laquelle elle est affichée (le facteur rétine), exportez-la en WebP, compressez-la à une qualité de 80 et déployez un court srcset pour que les téléphones et les ordinateurs portables reçoivent chacun un fichier adapté. Pour un héros pleine largeur qui s'affiche à 1920px, un seul WebP de 1920 à 2560px à la qualité 80 est généralement suffisant. Si vous sautez cette étape, vous forcez chaque appareil à télécharger des pixels en résolution de bureau.

Quelle taille une image web devrait-elle réellement avoir ?

La bonne taille est la taille d'affichage, pas la taille source. Ouvrez les DevTools, inspectez l'image, lisez la plus grande largeur de boîte CSS qu'elle occupe jamais sur tous les points de rupture (breakpoints), puis exportez à cette largeur multipliée par votre cible de densité.

Pour la plupart des images d'articles et de produits qui tombent dans une plage prévisible. Je mesure chaque emplacement avant d'exporter, car deviner est ce qui fait qu'une photo de 4000px se retrouve dans une colonne de 600px.

Ne laissez jamais CSS faire le redimensionnement. Une <img> stylisée à width: 400px télécharge toujours le fichier complet — le navigateur jette les pixels supplémentaires après que les octets sont déjà sur la ligne. Redimensionnez la source en premier, puis faites confiance à CSS uniquement pour la mise en page.

Étape par étape : mon flux de travail de redimensionnement

Ceci est la séquence exacte que j'exécute. Je l'ai testé contre un audit d'images Lighthouse et il passe systématiquement le contrôle des « images correctement dimensionnées ».

• Mesurer la plus grande largeur rendue avec DevTools.
• Multiplier par 2 pour le rétine (3x seulement pour les photos de héros de téléphone denses).
• Redimensionner avec un filtre haute qualité (Lanczos).
• Exporter en WebP à la qualité 80, descendre à 75 si le fichier est toujours lourd.
• Générer une échelle srcset pour les emplacements réactifs.
• Compresser à nouveau si le fichier dépasse encore 200KB.

from PIL import Image

def resize_for_web(src, out, max_width=1440, quality=80):
    img = Image.open(src)
    if img.width > max_width:
        ratio = max_width / img.width
        img = img.resize((max_width, int(img.height * ratio)),
                         Image.LANCZOS)
    img.save(out, "WEBP", quality=quality)

Quand je l'ai mesuré, cela a transformé une photo de 4000x2667 (JPEG de 4.2MB) en un WebP de 1440x960 de 94KB — une réduction de 98 % sans perte visible de netteté sur un écran standard. Les règles plus approfondies pour maintenir les détails lors d'un redimensionnement agressif se trouvent dans maintenir la qualité lors du redimensionnement.

Rétine et 2x : avez-vous vraiment besoin du double des pixels ?

Majoritairement oui, pour tout ce que les utilisateurs regardent attentivement. Un écran 2x regroupe quatre fois plus de pixels dans le même espace physique, donc un fichier 1x semble doux. La règle de sécurité : exporter à 2x la largeur CSS pour les images de contenu.

Là où je romps délibérément cette règle :

• Les arrière-plans décoratifs qui peuvent flouter ou s'estomper peuvent rester proches de 1x.
• Les images sous le pli (below-the-fold) où la netteté est moins critique peuvent utiliser 1.5x.
• Les icônes et les logos sont meilleurs en SVG, qui est indépendant de la résolution.

Le guide web.dev image guidance de Google recommande des descripteurs de densité ou des descripteurs de largeur ; les descripteurs de largeur via srcset sont plus faciles à raisonner, c'est donc ce que je privilégie par défaut.

Servir des variantes réactives avec srcset

Un fichier par image est rarement approprié pour tous les appareils. Un téléphone n'a pas besoin d'un fichier de 1440px, et un moniteur 4K ne devrait pas se contenter d'un 480px. srcset vous permet d'offrir plusieurs largeurs et laisse le navigateur choisir.

<img
  src="hero-960.webp"
  srcset="hero-480.webp 480w, hero-720.webp 720w,
          hero-960.webp 960w, hero-1440.webp 1440w"
  sizes="(min-width: 900px) 720px, 92vw"
  alt="Illustration de héros d'un panorama urbain au crépuscule"
  width="960" height="640" loading="lazy">

L'attribut sizes doit dire la vérité sur l'emplacement rendu. Si vous le laissez à la valeur par défaut 100vw, le navigateur suppose que l'image s'étend sur tout le viewport et télécharge la plus grande variante. Choisir quelles largeurs générer est une décision en soi — la méthode que j'utilise pour tailler l'échelle se trouve dans points de rupture d'images réactives.

Taille du fichier vs dimensions : qu'est-ce qui compte le plus ?

Les deux comptent, mais pour des raisons différentes. Les dimensions déterminent le nombre de pixels ; la compression et le format déterminent les octets par pixel. Une image correctement dimensionnée avec une mauvaise compression reste lourde, et une image minuscule mais trop compressée semble cassée.

L'objectif que je vise est inférieur à 200KB pour la plupart des images de contenu, et inférieur à 100KB pour tout ce qui se trouve au-dessus du pli (above the fold) qui alimente Largest Contentful Paint. Lorsqu'un fichier dépasse ce seuil, le premier levier que j'actionne est la qualité de compression, puis le format. Le détail niveau octet sur la façon dont la compression réduit le poids se trouve dans compresser sans perdre en qualité.

Lighthouse signale les images trop grandes comme une opportunité concrète. Exécutez-le depuis Chrome DevTools ou suivez la documentation Lighthouse — l'audit « images correctement dimensionnées » rapporte exactement combien de KB vous gaspillez en servant plus de pixels que ce dont l'emplacement a besoin.

Choisir le bon format

Le format est là où beaucoup d'octets se cachent. Je me porte par défaut sur WebP pour presque tout ce qui est photographique, avec AVIF lorsque je peux me permettre un fallback. Faire correspondre le format au contenu compte autant que les dimensions : un PNG utilisé pour une photo est plus lourd que le même fichier en WebP sans bénéfice.

Le guide des images réactives MDN couvre l'élément <picture> pour servir AVIF avec un fallback WebP ou JPEG. Je me tourne vers <picture> uniquement lorsque j'ai besoin de négociation de format ; pour les photos réactives simples, srcset seul suffit.

Erreurs que je vois lors des audits de sites

Lorsque j'audite un site lent, les problèmes d'images se répètent. Ce sont ceux que je corrige le plus souvent.

• Télécharger des fichiers en résolution caméra et les redimensionner avec CSS.
• Un seul fichier pour chaque point de rupture au lieu d'une échelle srcset.
• Oublier width et height, ce qui provoque un décalage de mise en page (layout shift).
• Laisser sizes à la valeur par défaut, permettant ainsi au navigateur de prendre le plus grand fichier.
• Charger toutes les images avec avidité (eagerly) au lieu de différer celles sous le pli.

Ce dernier point est un gain de performance gratuit. Le modèle pour différer les images hors écran est couvert dans charger des images en mode paresseux — ajoutez loading="lazy" et le navigateur ignore les images que l'utilisateur n'a pas encore défilées.

Résumé

Avant de déployer une image, je passe cette liste : redimensionnée à 2x la plus grande largeur d'affichage, exportée en WebP, compressée sous 200KB, avec une échelle srcset, un attribut sizes véridique, des largeurs et hauteurs explicites, loading="lazy" sous le pli, et un texte alternatif descriptif.

Une vraie mise en garde : le redimensionnement est le plus grand levier, mais ce n'est pas tout le travail. J'ai vu des équipes maîtriser les dimensions et quand même déployer des pages lentes parce qu'elles servaient des fichiers depuis l'origine sans cache, sans CDN, ni nom de fichier haché de contenu. Mesurez avec Lighthouse et des profils d'appareils réels, puis faites confiance aux chiffres plutôt que à la liste de contrôle. Un WebP de 94KB que le navigateur re-télécharge à chaque navigation est toujours une erreur de 94KB.

Questions fréquemment posées

Quelle taille devrait avoir une image héros web ?

Assurez-vous qu'elle corresponde à la taille d'affichage : environ 1600px de large pour un héros pleine largeur, 800–1200px pour une image de colonne de contenu. Exporter à 2x la taille d'affichage (pour le rétine) double les pixels ; servez la bonne taille par appareil avec srcset plutôt que de déployer un seul fichier énorme.

Ai-je besoin d'images 2x pour les écrans rétine ?

Pour des graphiques nets et des photos de héros, oui — les écrans rétine montrent sinon de la douceur. Pour les images sous le pli et décoratives, un seul fichier 1x est souvent suffisant. Utilisez srcset pour servir des variantes 1x et 2x afin que les appareils non-rétine ne téléchargent pas le grand fichier.

Qu'est-ce qui compte le plus, les dimensions ou la taille du fichier ?

Les deux, mais la taille du fichier affecte davantage Core Web Vitals. Redimensionnez d'abord aux dimensions d'affichage (élimine les pixels gaspillés), puis compressez à une qualité cible (élimine les octets gaspillés). Le guide de vitesse web couvre l'ordre complet.

Comment puis-je servir des variantes réactives ?

Utilisez srcset avec des sources spécifiques à la taille et un attribut sizes décrivant la largeur d'affichage, laissant le navigateur choisir le bon fichier par viewport. Générez chaque taille à partir du maître, puis laissez le navigateur choisir. Voir le guide des images réactives.

Qu'est-ce que srcset ?

Un attribut HTML qui liste plusieurs sources d'images de différentes tailles, permettant au navigateur de choisir la bonne selon le viewport. Il envoie un petit fichier à un petit écran et un grand fichier à un grand écran, économisant des octets. Voir le guide des images réactives.

Qu'est-ce que l'attribut sizes ?

Un attribut HTML qui indique au navigateur la largeur à laquelle l'image s'affiche à chaque point de rupture, afin que le navigateur puisse choisir la bonne source srcset avant de télécharger. Sans sizes, le navigateur devine. Associez srcset (les sources) avec sizes (les largeurs d'affichage) pour des images réactives qui téléchargent efficacement. Voir le guide des images réactives.

Crédits des images

• Un MacBook sur un bureau affichant une maquette de site web conçu — photo par Tranmautritam sur Pexels
• Gros plan d'un moniteur d'ordinateur affichant des lignes de code source — photo par Nemuel Sereti sur Pexels
• Un écran d'ordinateur portable montrant un site web qui charge dans un onglet de navigateur — photo par cottonbro studio sur Pexels