Images responsives : comprendre srcset et sizes

Une image peut parfaitement s’adapter à la largeur d’un écran tout en restant inutilement lourde.

C’est l’un des pièges les plus fréquents du responsive design.

Avec ce CSS :

img {
  max-width: 100%;
  height: auto;
}

une photographie de 4 000 pixels de large peut être affichée proprement dans une colonne de 360 pixels. Visuellement, tout semble correct. Pourtant, si le navigateur télécharge toujours le fichier de 4 000 pixels, le visiteur mobile reçoit beaucoup plus de données que nécessaire.

Les images responsives répondent précisément à ce problème.

Le principe est de fournir au navigateur plusieurs ressources possibles et suffisamment d’informations sur leur usage pour qu’il puisse choisir une variante adaptée au contexte.

Deux attributs HTML jouent ici un rôle central :

• srcset, qui décrit les fichiers candidats ;
• sizes, qui décrit la largeur d’affichage probable de l’image lorsque l’on utilise des descripteurs de largeur.

À cela s’ajoute l’élément <picture>, utile lorsqu’il faut changer de format ou de composition selon le contexte.

Comprendre ces mécanismes permet de sortir d’un faux dilemme :

choisir entre une image nette mais énorme et une image légère mais floue.

Une bonne stratégie responsive peut proposer plusieurs tailles et laisser le navigateur sélectionner celle qui correspond le mieux à l’écran, à la densité de pixels et à la mise en page.

Une image fluide n’est pas forcément une image responsive

Ces deux notions sont souvent confondues.

Image fluide

Une image est fluide lorsque son affichage s’adapte à son conteneur.

Exemple :

img {
  max-width: 100%;
  height: auto;
}

Si le conteneur mesure 600 pixels, l’image peut être affichée à 600 pixels.

S’il mesure 320 pixels, elle peut être affichée à 320 pixels.

Mais le fichier téléchargé peut rester exactement le même.

Image responsive

Une image responsive permet au navigateur de choisir entre plusieurs ressources.

Par exemple :

photo-480.webp
photo-800.webp
photo-1200.webp
photo-1600.webp

Le navigateur peut alors éviter de télécharger systématiquement la version 1 600 pixels lorsqu’une variante plus petite suffit.

Les deux techniques sont complémentaires :

CSS responsive
→ adapte l’affichage

srcset / sizes
→ adapte la ressource téléchargée

Cette distinction prolonge directement les notions expliquées dans Quelle résolution choisir pour une image ?.

Pourquoi ne pas simplement envoyer la plus grande image ?

Parce qu’une grande ressource possède un coût.

Supposons quatre variantes :

480 px   → 55 Ko
800 px   → 110 Ko
1200 px  → 190 Ko
2000 px  → 420 Ko

Si un téléphone n’a réellement besoin que de la variante 800 px, lui envoyer systématiquement 2 000 px peut ajouter plusieurs centaines de kilo-octets.

Sur une seule page, cela semble parfois acceptable.

Sur :

• une galerie ;
• une page d’accueil ;
• un catalogue ;
• une connexion mobile ;
• plusieurs navigations ;

le gaspillage s’accumule.

L’objectif des images responsives est donc de rapprocher la ressource transférée de la ressource réellement utile.

Pourquoi ne pas simplement envoyer la plus petite image ?

Parce que le problème inverse apparaît.

Une image de 480 pixels affichée sur un grand écran ou un écran à forte densité peut manquer de netteté.

Il faut donc équilibrer :

• dimensions ;
• densité ;
• poids ;
• qualité.

Les images responsives permettent de fournir plusieurs réponses possibles au lieu d’imposer une taille universelle.

Avant srcset : préparer les variantes

Le HTML ne crée pas les fichiers à votre place.

Avant d’écrire :

srcset="..."

vous devez disposer de ressources adaptées.

À partir d’un original de qualité suffisante, vous pouvez produire par exemple :

hero-480.webp
hero-768.webp
hero-1024.webp
hero-1440.webp
hero-1920.webp

Le redimensionneur d’image permet de préparer ces différentes largeurs.

Si le format doit également être changé, utilisez le convertisseur d’images.

Et si vous devez déterminer les dimensions correspondant à un ratio précis, le calculateur de ratio d’image complète ce workflow.

Combien de variantes faut-il créer ?

Il n’existe pas de nombre universel.

Créer une variante pour chaque largeur possible serait inutile.

L’objectif est d’obtenir un ensemble raisonnable de paliers.

Par exemple :

480
768
1024
1440
1920

ou :

400
800
1200
1600
2400

Le bon choix dépend :

• de la largeur maximale d’affichage ;
• du ratio ;
• du poids des fichiers ;
• de la densité des écrans ;
• de la fréquence d’utilisation ;
• du système de design.

Plus les variantes sont proches, plus le navigateur peut choisir précisément, mais plus vous devez générer et stocker de fichiers.

Il faut rechercher un compromis.

src reste important

Même avec srcset, l’attribut src reste présent.

Exemple :

<img
  src="/images/photo-800.webp"
  srcset="
    /images/photo-480.webp 480w,
    /images/photo-800.webp 800w,
    /images/photo-1200.webp 1200w
  "
  alt="Lac de montagne entouré de sommets"
>

src fournit notamment une ressource de repli et fait partie de la déclaration de l’image.

Ne considérez pas srcset comme un remplacement complet de src.

Première syntaxe : les descripteurs de largeur w

Voici le cas le plus utile pour une image dont la largeur d’affichage varie avec la mise en page :

<img
  src="/images/photo-800.webp"
  srcset="
    /images/photo-480.webp 480w,
    /images/photo-800.webp 800w,
    /images/photo-1200.webp 1200w,
    /images/photo-1600.webp 1600w
  "
  sizes="100vw"
  alt="..."
>

Chaque nombre suivi de w décrit la largeur intrinsèque du fichier candidat.

Ainsi :

photo-480.webp 480w

signifie :

ce fichier possède une largeur intrinsèque de 480 pixels.

Ce n’est pas une instruction disant au navigateur de l’afficher à 480 pixels.

C’est une information sur la ressource.

480w n’est pas une media query

C’est une distinction fondamentale.

Dans :

srcset="
  small.webp 480w,
  medium.webp 800w,
  large.webp 1200w
"

les valeurs :

480w
800w
1200w

ne signifient pas :

si écran <= 480
si écran <= 800
si écran <= 1200

Elles indiquent la largeur des images candidates.

Le navigateur combine ensuite ces informations avec :

• sizes ;
• largeur du viewport ;
• densité de pixels ;
• autres facteurs de sélection.

C’est lui qui choisit la ressource.

Pourquoi sizes existe-t-il ?

Lorsque le navigateur rencontre le HTML, il souhaite commencer à télécharger l’image rapidement.

Mais il ne connaît pas toujours encore la largeur finale exacte calculée par toute la mise en page.

sizes lui donne une estimation déclarative de la largeur que l’image occupera.

Exemple :

sizes="100vw"

signifie, dans ce contexte :

l’image devrait occuper une largeur correspondant à 100 % de la largeur du viewport.

Le navigateur peut alors comparer cette largeur attendue aux candidats de srcset.

vw : largeur du viewport

L’unité :

1vw

correspond à 1 % de la largeur du viewport.

Donc :

100vw

correspond à toute la largeur du viewport.

Et :

50vw

à la moitié.

Si le viewport mesure 1 000 CSS pixels :

50vw = 500 CSS px

Cette information aide le navigateur à estimer la ressource nécessaire.

Exemple simple avec sizes="100vw"

<img
  src="/images/landscape-800.webp"
  srcset="
    /images/landscape-480.webp 480w,
    /images/landscape-800.webp 800w,
    /images/landscape-1200.webp 1200w,
    /images/landscape-1600.webp 1600w
  "
  sizes="100vw"
  alt="Paysage côtier"
>

Sur un viewport d’environ 390 CSS px, l’image est déclarée comme occupant environ 390 CSS px.

Sur un écran à densité standard, une variante proche de cette largeur peut suffire.

Sur un écran à densité élevée, le navigateur peut préférer une ressource plus large.

C’est pourquoi il ne faut pas essayer de prédire manuellement chaque choix.

Le navigateur choisit, pas le développeur

Avec srcset, vous ne dites généralement pas :

« sur tel appareil, télécharge exactement ce fichier ».

Vous fournissez :

• une liste de candidats ;
• leurs caractéristiques ;
• une estimation de la taille d’affichage.

Le navigateur choisit.

Cette liberté lui permet de prendre en compte des éléments que votre media query ne résume pas nécessairement.

Le choix exact peut aussi dépendre de l’implémentation du navigateur.

Votre travail consiste à proposer un ensemble de candidats cohérent.

Exemple : image limitée par un conteneur

Une image n’occupe pas toujours toute la largeur de l’écran.

Supposons une page :

.article {
  width: min(100% - 2rem, 1200px);
  margin-inline: auto;
}

L’image peut occuper presque toute la largeur sur mobile, mais ne jamais dépasser environ 1 200 px sur desktop.

Une première approximation pourrait être :

sizes="(max-width: 1200px) calc(100vw - 2rem), 1200px"

L’idée est :

• sous le seuil, l’image suit la largeur disponible avec les marges ;
• au-delà, elle reste limitée au conteneur.

sizes doit refléter la mise en page réelle, pas une taille inventée.

Syntaxe de sizes

sizes peut contenir plusieurs conditions.

Exemple :

sizes="
  (max-width: 600px) 100vw,
  (max-width: 1000px) 50vw,
  600px
"

Le navigateur examine les conditions dans l’ordre.

On peut lire cette déclaration ainsi :

• jusqu’à 600 px de viewport : l’image occupe environ toute la largeur ;
• jusqu’à 1 000 px : environ la moitié ;
• sinon : environ 600 px.

La dernière valeur joue le rôle de cas par défaut.

L’ordre des conditions compte

Dans :

sizes="
  (max-width: 600px) 100vw,
  (max-width: 1000px) 50vw,
  600px
"

la première condition correspondante est utilisée.

Il faut donc organiser les règles de manière cohérente.

Un sizes contradictoire ou mal ordonné peut conduire le navigateur à estimer une largeur incorrecte et à télécharger une ressource trop grande ou trop petite.

sizes doit-il reproduire exactement le CSS ?

Il doit représenter suffisamment fidèlement la largeur d’affichage prévue.

Il n’est pas nécessaire de recopier toute la feuille de styles.

Mais si votre CSS dit :

carte mobile : 100 % de largeur
tablette : deux colonnes
desktop : trois colonnes

et que sizes dit toujours :

sizes="100vw"

le navigateur peut surestimer la largeur d’une image de carte sur desktop.

Le résultat fonctionne visuellement, mais vous perdez une partie du bénéfice de srcset.

Exemple : grille de cartes

Supposons :

• une colonne sur mobile ;
• deux colonnes sur tablette ;
• trois colonnes sur desktop.

Une déclaration simplifiée pourrait être :

sizes="
  (max-width: 640px) 100vw,
  (max-width: 1024px) 50vw,
  33vw
"

Dans une vraie grille, il faut également tenir compte :

• des marges ;
• des gaps ;
• de la largeur maximale du conteneur.

L’exemple illustre le principe, pas une formule universelle.

Pourquoi un mauvais sizes peut annuler l’optimisation

Vous avez peut-être préparé :

400w
800w
1200w
1600w

mais déclaré :

sizes="100vw"

pour une image qui n’occupe réellement que 25 % de la largeur du desktop.

Le navigateur peut choisir un candidat beaucoup plus grand que nécessaire.

Tous les fichiers ont été correctement générés, mais l’information fournie au navigateur est mauvaise.

Une stratégie responsive ne s’arrête donc pas à la génération des variantes.

sizes="auto" et comportements modernes

Les capacités HTML évoluent et certains scénarios modernes permettent au navigateur de s’appuyer davantage sur les dimensions réellement connues pour certaines images, notamment dans des contextes de chargement différé.

Cependant, il est préférable de comprendre d’abord la logique classique :

srcset + descripteurs w + sizes

car elle explique la sélection des ressources et reste essentielle dans de nombreux cas.

Lorsque vous adoptez une fonctionnalité plus récente, vérifiez sa compatibilité avec les navigateurs réellement ciblés par votre projet.

Deuxième syntaxe : les descripteurs de densité x

Il existe une autre forme de srcset.

Exemple :

<img
  src="/images/logo.png"
  srcset="
    /images/logo.png 1x,
    /images/logo@2x.png 2x
  "
  width="200"
  height="60"
  alt="..."
>

Ici :

1x
2x

décrivent des densités de pixels.

Cette approche convient lorsque la taille d’affichage de l’image est essentiellement fixe, mais que vous souhaitez fournir une ressource plus détaillée aux écrans à forte densité.

1x, 2x et Device Pixel Ratio

Un écran peut utiliser plusieurs pixels physiques pour représenter un pixel CSS.

Si une image est affichée à :

200 CSS px

une ressource de :

200 px

correspond approximativement à un cas 1x.

Une ressource de :

400 px

peut servir de candidat 2x.

Mais la densité réelle des appareils ne se limite pas à 1 ou 2.

Le navigateur sait effectuer la sélection à partir des candidats disponibles.

Quand utiliser x ?

Les descripteurs de densité sont pratiques lorsque :

• la taille CSS est relativement stable ;
• vous avez des variantes de même composition ;
• vous voulez gérer la netteté sur différents écrans.

Exemples :

• petite image de profil ;
• logo raster ;
• icône raster particulière.

Pour une grande image dont la largeur change fortement avec la mise en page, les descripteurs w sont souvent plus adaptés.

Pourquoi ne pas mélanger w et x ?

Les deux syntaxes correspondent à deux modes de description différents.

Évitez de construire un srcset incohérent mélangeant arbitrairement :

480w
2x
1200w

Choisissez la stratégie correspondant au problème.

Largeur variable

Utilisez généralement :

w + sizes

Taille d’affichage fixe avec variantes de densité

Utilisez éventuellement :

x

Cette séparation rend la déclaration compréhensible et prévisible.

sizes avec descripteurs x ?

sizes est associé au mécanisme de sélection basé sur les descripteurs de largeur.

Avec un srcset de densité :

srcset="avatar.png 1x, avatar@2x.png 2x"

vous décrivez directement les densités candidates.

N’ajoutez pas sizes mécaniquement à toutes les images parce que vous avez vu les deux attributs ensemble dans un exemple.

Comment le navigateur choisit-il avec w ?

Prenons :

<img
  srcset="
    photo-400.webp 400w,
    photo-800.webp 800w,
    photo-1200.webp 1200w
  "
  sizes="400px"
  ...
>

Si l’image doit occuper environ 400 CSS px :

• sur un écran proche de 1x, 400w peut être suffisant ;
• sur un écran proche de 2x, le navigateur peut viser une ressource autour de 800 pixels ;
• si aucun candidat idéal n’existe, il choisit parmi ceux disponibles.

Le principe peut être approximé ainsi :

largeur de rendu × densité
≈ largeur de ressource souhaitée

Mais le navigateur conserve la décision finale.

Pourquoi un téléphone peut-il télécharger une image de 800 px pour l’afficher à 400 px ?

Parce que l’écran peut avoir une densité d’environ 2.

Dans ce cas :

400 CSS px × 2
≈ 800 pixels de ressource

Cela n’est pas nécessairement du gaspillage.

L’erreur serait de conclure uniquement depuis les dimensions CSS que le navigateur aurait dû choisir 400w.

La densité compte.

Faut-il toujours viser exactement le DPR ?

Pas nécessairement.

Une ressource 2x est plus lourde qu’une ressource 1x.

Selon le contenu, la différence visuelle peut être faible.

Une stratégie de performance peut donc choisir des paliers raisonnables plutôt que de fournir des variantes extrêmement grandes pour satisfaire parfaitement les densités les plus élevées.

Le navigateur choisit parmi ce que vous lui donnez.

Vous contrôlez donc indirectement le budget en contrôlant les candidats disponibles.

Résolution et images responsives

Les images responsives ne remplacent pas la réflexion sur la résolution.

Elles l’industrialisent.

Vous devez toujours déterminer :

• largeur maximale utile ;
• largeur minimale ;
• ratio ;
• niveau de détail.

Le guide Quelle résolution choisir pour une image ? explique comment dimensionner les ressources avant de les déclarer.

srcset ne peut pas réparer un mauvais ensemble de fichiers.

Compression et images responsives

Supposons que vous génériez cinq largeurs.

Si chacune est exportée à une qualité excessivement élevée, votre page peut rester lourde.

Chaque variante doit également être correctement compressée.

Le workflow devient :

source maître
→ redimensionnement
→ encodage
→ compression
→ srcset

Le guide Comment compresser une image sans perdre en qualité ? détaille cette étape.

Les images responsives et la compression ne sont pas des stratégies concurrentes.

Elles agissent à deux niveaux différents.

Format et images responsives

Vous pouvez générer :

photo-480.webp
photo-800.webp
photo-1200.webp

mais également proposer un autre format avec <picture>.

Le choix du format et le choix de la largeur sont deux axes distincts.

Pour comprendre JPEG, PNG, WebP et AVIF, consultez PNG, JPEG, WebP ou AVIF : quel format choisir ?.

<picture> : à quoi sert-il ?

<picture> permet de fournir plusieurs sources possibles autour d’un élément <img>.

Exemple :

<picture>
  <source
    type="image/avif"
    srcset="
      photo-480.avif 480w,
      photo-800.avif 800w,
      photo-1200.avif 1200w
    "
    sizes="100vw"
  >
  <source
    type="image/webp"
    srcset="
      photo-480.webp 480w,
      photo-800.webp 800w,
      photo-1200.webp 1200w
    "
    sizes="100vw"
  >
  <img
    src="photo-800.jpg"
    srcset="
      photo-480.jpg 480w,
      photo-800.jpg 800w,
      photo-1200.jpg 1200w
    "
    sizes="100vw"
    alt="..."
  >
</picture>

Le navigateur examine les sources compatibles puis utilise la logique de sélection appropriée.

<picture> n’est pas obligatoire pour utiliser srcset

Vous pouvez utiliser srcset directement sur <img>.

<img
  src="photo-800.webp"
  srcset="
    photo-480.webp 480w,
    photo-800.webp 800w,
    photo-1200.webp 1200w
  "
  sizes="100vw"
  alt="..."
>

C’est suffisant si :

• un seul format est nécessaire ;
• la composition ne change pas.

N’utilisez pas <picture> uniquement pour rendre le code « plus moderne ».

<picture> pour les formats

Un usage courant consiste à proposer un format moderne tout en conservant une solution de repli.

Par exemple :

<picture>
  <source
    type="image/avif"
    srcset="hero-800.avif 800w, hero-1600.avif 1600w"
    sizes="100vw"
  >
  <img
    src="hero-800.webp"
    srcset="hero-800.webp 800w, hero-1600.webp 1600w"
    sizes="100vw"
    alt="..."
  >
</picture>

Selon vos navigateurs cibles, le fallback exact peut varier.

L’idée est surtout de séparer :

• négociation de format ;
• sélection de taille.

<picture> pour la direction artistique

La direction artistique répond à un problème différent.

Supposons une photographie horizontale montrant une personne à gauche et beaucoup de décor à droite.

Sur mobile, réduire toute l’image peut rendre le sujet minuscule.

Vous pourriez préférer un recadrage vertical.

Exemple :

<picture>
  <source
    media="(max-width: 600px)"
    srcset="/images/portrait-mobile.webp"
  >
  <img
    src="/images/portrait-desktop.webp"
    alt="..."
  >
</picture>

Ici, on ne choisit pas seulement une résolution différente.

On choisit une composition différente.

Résolution switching et art direction

Ces deux notions doivent être distinguées.

Resolution switching

Même image, mêmes informations, différentes tailles :

photo-480
photo-800
photo-1200

Art direction

Le contenu visuel ou le cadrage change :

photo-mobile-recadrée
photo-desktop-large

srcset avec w est excellent pour le premier problème.

<picture> avec des conditions media est utile pour le second.

Pourquoi ne pas utiliser <picture> pour forcer chaque appareil ?

Il est tentant d’écrire :

mobile → fichier A
tablette → fichier B
desktop → fichier C

pour toutes les images.

Mais cela retire au navigateur une partie de sa capacité à choisir selon :

• densité ;
• largeur réelle ;
• ressources disponibles.

Pour un simple changement de résolution, fournissez des candidats et laissez le navigateur choisir.

Réservez les conditions <picture> aux situations où vous avez une raison éditoriale ou technique de changer de source.

L’attribut media de <source>

Une source peut être conditionnée :

<source
  media="(max-width: 600px)"
  srcset="mobile.webp"
>

Le navigateur utilise cette source lorsque la condition correspond.

On retrouve ici une logique proche des media queries CSS.

Mais contrairement aux descripteurs 480w, cette condition concerne bien le contexte du viewport.

Ne confondez donc pas :

480w

avec :

(max-width: 480px)

Le premier décrit une ressource.

Le second décrit une condition.

type dans <source>

Vous pouvez indiquer :

<source type="image/avif" ...>

Le navigateur peut alors ignorer une source dont il ne prend pas en charge le type sans devoir nécessairement télécharger l’image pour le découvrir.

Cela permet d’organiser une stratégie de formats.

L’ordre des sources doit être cohérent avec vos préférences.

Le <img> final reste indispensable

Dans <picture>, l’élément <img> n’est pas un détail facultatif.

Il porte notamment :

• l’image de repli ;
• alt ;
• dimensions ;
• attributs de chargement ;
• sémantique de l’image.

Exemple :

<picture>
  <source ...>
  <img
    src="fallback.webp"
    alt="..."
    width="1200"
    height="800"
  >
</picture>

Ne placez pas l’alternative textuelle sur <source>.

alt et images responsives

Toutes les variantes représentant la même information partagent la même alternative.

Vous ne devez pas écrire un alt différent pour :

photo-480
photo-800
photo-1200

Ce sont des versions techniques du même contenu.

Pour une direction artistique, le cadrage peut changer, mais l’information essentielle devrait rester cohérente avec l’alternative portée par <img>.

width et height restent utiles

Une image responsive peut conserver :

width="1200"
height="800"

sur <img>.

Ces valeurs peuvent aider le navigateur à déterminer le rapport d’aspect intrinsèque et à réserver l’espace.

Puis CSS peut adapter l’affichage :

img {
  max-width: 100%;
  height: auto;
}

Les dimensions HTML et le responsive design ne sont pas contradictoires.

Cette question est détaillée dans Quelle résolution choisir pour une image ?.

Pourquoi réserver l’espace ?

Si le navigateur ne connaît pas la place que prendra une image, le contenu peut se déplacer lorsqu’elle arrive.

Exemple :

1. le texte apparaît ;
2. l’image se charge ;
3. elle pousse le texte vers le bas.

Ces déplacements nuisent à la stabilité visuelle.

Déclarer des dimensions cohérentes aide à réserver l’espace.

Le futur guide Optimiser les images pour les performances Web reliera cette question au CLS et aux performances globales.

Variantes avec le même ratio

Pour du simple resolution switching, les variantes devraient généralement conserver le même rapport d’aspect.

Par exemple :

480 × 320
800 × 533
1200 × 800

Les arrondis peuvent produire un pixel d’écart, mais la composition reste la même.

Si les ratios changent fortement, vous entrez plutôt dans une logique de direction artistique.

Le calculateur de ratio d’image permet de vérifier les dimensions cohérentes.

Comment générer les variantes sans dégrader l’image ?

Repartez toujours d’une source maître suffisamment grande.

Évitez :

original
→ 1600
→ 1200 depuis 1600
→ 800 depuis 1200
→ 480 depuis 800

Préférez :

              → 1600
original maître → 1200
              → 800
              → 480

Chaque variante est ainsi produite depuis la meilleure source.

Cela limite l’accumulation de transformations et de pertes.

Noms de fichiers

Une convention claire facilite le workflow.

Par exemple :

mountain-480.webp
mountain-768.webp
mountain-1024.webp
mountain-1440.webp
mountain-1920.webp

Ou :

mountain-sm.webp
mountain-md.webp
mountain-lg.webp

Les largeurs explicites ont l’avantage de rester compréhensibles dans un srcset.

Dans une chaîne automatisée, les noms peuvent également être générés ou hachés.

L’important est la cohérence.

Faut-il générer 1x et 2x pour chaque largeur ?

Pas si vous utilisez les descripteurs w.

Avec :

480w
800w
1200w
1600w

le navigateur combine déjà la largeur d’affichage et la densité pour sélectionner une ressource.

Créer en plus :

480-1x
480-2x
800-1x
800-2x

peut dupliquer inutilement le modèle.

Choisissez une stratégie claire.

Quel candidat mettre dans src ?

Choisissez une ressource raisonnable pour le contexte et le fallback.

Évitez par principe de mettre le plus gros fichier si cela conduit certains environnements à le télécharger inutilement.

Mais ne choisissez pas non plus une miniature qui serait médiocre lorsqu’elle est utilisée comme fallback.

La stratégie exacte dépend de vos navigateurs cibles et de votre pipeline.

Le préchargement peut-il compliquer srcset ?

Oui.

Précharger naïvement :

<link rel="preload" as="image" href="hero-2000.webp">

peut forcer le téléchargement d’une grande ressource alors que srcset aurait choisi une variante plus petite.

Lorsque vous préchargez une image responsive importante, utilisez les mécanismes prévus pour que le préchargement reste cohérent avec les candidats responsives lorsque votre environnement le permet.

Le principe général est :

ne contournez pas involontairement la logique de sélection que vous avez construite.

Image héro et LCP

Une image héro visible immédiatement peut devenir le Largest Contentful Paint.

Pour ce type d’image, la stratégie responsive est particulièrement importante.

Vous voulez :

• une ressource suffisamment nette ;
• pas de fichier surdimensionné ;
• une découverte rapide ;
• des dimensions réservées ;
• une priorité cohérente.

Mais n’appliquez pas mécaniquement loading="lazy" à une image LCP importante.

Retarder son chargement peut dégrader la performance perçue.

Le futur guide Optimiser les images pour les performances Web approfondira ce cas.

Lazy loading et images responsives

Une image située loin sous la ligne de flottaison peut utiliser :

loading="lazy"

selon le contexte.

Cela ne remplace pas srcset.

Les deux techniques répondent à des questions différentes :

lazy loading
→ quand charger ?

srcset
→ quel fichier charger ?

Une image lazy peut donc également être responsive.

decoding

L’attribut decoding permet de fournir une indication sur le décodage de l’image.

Il ne choisit pas la résolution et ne remplace pas srcset.

Ne mélangez pas toutes les optimisations dans une seule catégorie.

Pour comprendre un pipeline complet, gardez les responsabilités séparées :

• dimensions ;
• format ;
• compression ;
• sélection responsive ;
• chargement ;
• décodage.

fetchpriority

Certaines images importantes peuvent utiliser une indication de priorité.

Là encore, cela ne remplace pas srcset.

Une image peut être :

• responsive ;
• prioritaire ;
• correctement dimensionnée.

Ou responsive mais chargée trop tard.

L’optimisation globale combine plusieurs leviers.

Pourquoi les outils de développement peuvent surprendre ?

Vous testez une page à 390 px et voyez que le navigateur télécharge un candidat de 800w.

Cela peut être parfaitement normal à cause de la densité de l’écran.

Ou parce que :

• sizes annonce une largeur plus grande ;
• le cache contient déjà une variante ;
• les outils d’émulation modifient le DPR.

Pour analyser correctement, regardez :

• viewport CSS ;
• DPR ;
• largeur rendue ;
• currentSrc ;
• cache.

currentSrc

En JavaScript, la propriété :

img.currentSrc

permet de connaître la ressource finalement sélectionnée.

Dans la console :

document.querySelector("img").currentSrc

peut aider à comprendre le choix du navigateur.

C’est plus fiable que de regarder uniquement l’attribut src, puisque le fichier réellement utilisé peut provenir de srcset ou <picture>.

Tester avec DevTools

Pour vérifier une stratégie responsive :

1. ouvrez les outils de développement ;
2. affichez l’onglet réseau ;
3. désactivez éventuellement le cache pendant le test ;
4. rechargez ;
5. changez la taille du viewport ;
6. observez la ressource téléchargée ;
7. vérifiez currentSrc.

Attention : modifier simplement la taille après qu’une grande image a déjà été téléchargée ne garantit pas que le navigateur retéléchargera immédiatement une plus petite ressource.

Rechargez dans les conditions à tester.

Tester plusieurs densités

Une stratégie peut sembler parfaite sur votre écran 1x et envoyer des fichiers très différents sur un téléphone 3x.

Testez plusieurs profils.

Vous n’avez pas besoin de couvrir chaque appareil existant.

Testez des catégories représentatives :

• petit mobile ;
• grand mobile ;
• tablette ;
• desktop ;
• densité standard ;
• forte densité.

L’objectif est de détecter les choix absurdes, pas de contrôler manuellement chaque décision du navigateur.

Vérifier le poids, pas seulement le nom

Si :

photo-1200.avif

est plus légère que :

photo-800.jpg

les dimensions seules ne racontent pas toute l’histoire.

Format et compression influencent le poids.

Mesurez :

• dimensions ;
• taille transférée ;
• qualité visuelle.

C’est pourquoi les articles formats d’image et compression restent indispensables dans un workflow responsive.

Faut-il servir AVIF à tout le monde ?

La question ne se résume pas à srcset.

Vous pouvez utiliser <picture> pour proposer différents formats, mais cela augmente le nombre de variantes générées.

Si vous produisez :

5 largeurs × 3 formats

vous obtenez :

15 fichiers

pour une seule image.

Le gain doit justifier la complexité.

Une stratégie simple et bien optimisée peut être préférable à une matrice gigantesque de variantes.

Explosion combinatoire des fichiers

Les images responsives peuvent créer beaucoup d’assets.

Supposons :

• 6 largeurs ;
• 2 formats ;
• 2 cadrages.

Cela donne :

6 × 2 × 2 = 24 variantes

pour une image.

Il faut donc définir des règles.

Par exemple :

• 4 ou 5 largeurs standard ;
• un format principal ;
• un fallback seulement lorsque nécessaire ;
• art direction uniquement pour les images qui en bénéficient réellement.

L’automatisation devient vite utile.

Pipeline automatisé

Un pipeline d’images peut :

1. prendre l’original ;
2. lire ses dimensions ;
3. générer plusieurs largeurs ;
4. encoder les formats retenus ;
5. produire les chemins ;
6. générer le srcset ;
7. éventuellement fournir largeur et hauteur.

Dans un site statique ou un framework moderne, cette génération peut être réalisée au build.

L’objectif est d’éviter de préparer manuellement des dizaines de variantes.

CDN d’images

Un CDN spécialisé peut générer des variantes à la demande.

Une URL peut inclure des paramètres de :

• largeur ;
• qualité ;
• format.

Cela évite de stocker toutes les variantes dans le dépôt.

Mais cela introduit :

• dépendance au service ;
• coûts ;
• politique de cache ;
• URLs spécifiques ;
• configuration.

Pour un site statique, une génération au build peut être plus simple.

Pour un catalogue très dynamique, un service d’images peut être pertinent.

Le navigateur peut-il choisir selon la bande passante ?

Les algorithmes de sélection appartiennent au navigateur et peuvent évoluer.

Il ne faut pas construire une architecture qui dépend d’une hypothèse précise comme :

« avec une connexion lente, il prendra forcément ce fichier ».

La spécification donne au navigateur une latitude de sélection.

Votre responsabilité est de fournir des candidats raisonnables et des informations correctes.

srcset garantit-il que le plus petit fichier possible sera choisi ?

Non.

Il aide le navigateur à choisir une ressource appropriée, pas nécessairement le fichier ayant le moins d’octets.

Le navigateur connaît les dimensions candidates, mais le poids exact et les heuristiques peuvent varier.

De plus, deux formats de même largeur peuvent avoir des poids très différents.

L’optimisation doit donc commencer par produire des fichiers eux-mêmes raisonnables.

Pourquoi le navigateur télécharge-t-il parfois un candidat plus grand ?

Plusieurs raisons possibles :

• DPR élevé ;
• sizes surestime la largeur ;
• paliers de candidats trop espacés ;
• ressource déjà en cache ;
• heuristiques du navigateur.

Avant de conclure à un bug, vérifiez ces facteurs.

Pourquoi ne télécharge-t-il pas une version plus petite après redimensionnement ?

Si une grande ressource est déjà disponible, télécharger une seconde image plus petite uniquement parce que la fenêtre a rétréci peut gaspiller davantage de réseau.

Le navigateur peut donc conserver la ressource existante.

Pour tester un viewport plus petit, rechargez la page dans les nouvelles conditions.

Le cache change l’expérience de test

Si photo-1600.webp est déjà en cache, le navigateur peut la réutiliser.

Cela peut donner l’impression que srcset ne fonctionne pas.

Pendant les tests :

• désactivez temporairement le cache ;
• rechargez ;
• observez le réseau.

En production, le cache est évidemment bénéfique.

Images responsives et SEO

srcset n’est pas une technique SEO magique.

Son bénéfice principal est l’expérience et la performance.

Une image doit toujours avoir :

• une intégration sémantique cohérente ;
• une alternative appropriée ;
• un contexte pertinent.

Les variantes techniques ne nécessitent pas des textes alternatifs différents.

Ne dupliquez pas artificiellement du contenu pour les moteurs.

Images responsives et accessibilité

Le choix de résolution est généralement transparent pour les technologies d’assistance.

L’accessibilité dépend surtout :

• du rôle de l’image ;
• de alt ;
• du contexte ;
• du contenu visuel.

La direction artistique doit toutefois préserver l’information essentielle.

Si le recadrage mobile supprime un élément décrit dans alt, votre alternative n’est plus cohérente.

Art direction et contenu informatif

Supposons que l’image desktop montre :

une personne + un panneau indiquant le lieu

et que le recadrage mobile supprime le panneau.

Si le panneau apporte une information importante, les deux variantes ne sont plus éditorialement équivalentes.

La direction artistique ne doit pas supprimer un contenu nécessaire uniquement pour améliorer la composition.

Responsive et SVG

Un SVG réellement vectoriel n’a généralement pas besoin de variantes de densité pour rester net.

Le navigateur peut le rasteriser à la taille nécessaire.

Cela ne signifie pas qu’un SVG complexe s’adapte automatiquement à toutes les compositions.

Vous pouvez avoir besoin d’une version simplifiée sur mobile, mais ce sera davantage de l’art direction que du resolution switching.

Pour approfondir, consultez SVG : comprendre le format vectoriel.

Responsive et transparence

Lorsque vous générez plusieurs variantes d’une image transparente, vérifiez que le format choisi conserve correctement l’alpha.

PNG, WebP et AVIF peuvent gérer la transparence selon les usages.

JPEG classique ne le fait pas.

Le choix de format doit donc précéder ou accompagner la génération des variantes.

Responsive et métadonnées

Créer cinq variantes à partir d’une photographie peut également dupliquer certaines métadonnées.

Selon votre pipeline, vous pourriez recopier :

• EXIF ;
• GPS ;
• informations d’appareil.

Le futur article Métadonnées d’image : les lire, les conserver ou les supprimer expliquera comment définir une politique cohérente.

Le responsive design ne doit pas multiplier involontairement des données que vous ne vouliez pas publier.

Responsive et confidentialité

Le nombre de variantes ne change pas la nature des données sensibles.

Si une source contient une géolocalisation qui doit être supprimée, faites-le dans le pipeline avant ou pendant la génération des fichiers de publication.

Le lecteur de métadonnées peut aider à inspecter un fichier avant diffusion.

Cas pratique : image héro pleine largeur

Supposons une image héro :

• ratio 16:9 ;
• largeur maximale utile 1 920 px ;
• presque toute la largeur du viewport.

Vous pourriez produire :

640
960
1280
1600
1920

puis :

<img
  src="/hero-1280.webp"
  srcset="
    /hero-640.webp 640w,
    /hero-960.webp 960w,
    /hero-1280.webp 1280w,
    /hero-1600.webp 1600w,
    /hero-1920.webp 1920w
  "
  sizes="100vw"
  width="1920"
  height="1080"
  alt="..."
>

Si la page possède une largeur maximale, adaptez sizes.

Cas pratique : image d’article

Supposons un contenu limité à 800 px.

Sur mobile, l’image occupe presque toute la largeur.

Sur desktop, elle ne dépasse jamais 800 px.

Vous pourriez produire :

400
600
800
1200
1600

Les deux dernières variantes peuvent servir aux écrans à forte densité.

Puis :

sizes="(max-width: 840px) calc(100vw - 2rem), 800px"

Le navigateur sait que même sur un écran desktop de 2 000 px, l’image ne mesure pas 2 000 CSS px.

C’est une information essentielle.

Cas pratique : cartes en grille

Supposons une grille :

mobile   : 1 colonne
tablette : 2 colonnes
desktop  : 3 colonnes

Chaque image de carte peut utiliser :

sizes="
  (max-width: 640px) calc(100vw - 2rem),
  (max-width: 1024px) calc(50vw - 2rem),
  360px
"

Les valeurs exactes doivent correspondre à votre grille.

Le but est d’éviter que le navigateur suppose qu’une vignette desktop occupe tout le viewport.

Cas pratique : avatar fixe

Un avatar est toujours affiché à :

64 × 64 CSS px

Vous pourriez utiliser :

<img
  src="/avatar-64.webp"
  srcset="
    /avatar-64.webp 1x,
    /avatar-128.webp 2x
  "
  width="64"
  height="64"
  alt="..."
>

Ici, les descripteurs de densité sont simples et adaptés.

Il n’est pas nécessaire d’utiliser sizes.

Cas pratique : photo avec recadrage mobile

Desktop :

1600 × 700

Mobile :

800 × 1000

Le sujet doit rester visible.

Utilisez <picture> :

<picture>
  <source
    media="(max-width: 600px)"
    srcset="
      portrait-480.webp 480w,
      portrait-800.webp 800w
    "
    sizes="100vw"
  >
  <img
    src="landscape-1200.webp"
    srcset="
      landscape-800.webp 800w,
      landscape-1200.webp 1200w,
      landscape-1600.webp 1600w
    "
    sizes="100vw"
    alt="..."
  >
</picture>

Vous combinez ici art direction et resolution switching.

Cas pratique : AVIF + WebP + plusieurs largeurs

Cette stratégie est possible :

<picture>
  <source
    type="image/avif"
    srcset="
      photo-480.avif 480w,
      photo-800.avif 800w,
      photo-1200.avif 1200w
    "
    sizes="100vw"
  >
  <img
    src="photo-800.webp"
    srcset="
      photo-480.webp 480w,
      photo-800.webp 800w,
      photo-1200.webp 1200w
    "
    sizes="100vw"
    alt="..."
  >
</picture>

Mais demandez-vous si le gain justifie six fichiers.

Pour une image très importante et largement consultée, oui peut-être.

Pour une petite illustration secondaire, une seule famille WebP correctement optimisée peut suffire.

Comment choisir les paliers de largeur ?

Commencez par les usages réels.

Supposons que vos composants affichent les images à :

320
480
720
960
1200

et que vous ciblez raisonnablement des écrans haute densité.

Vous n’avez pas forcément besoin d’un candidat exactement à chaque valeur multipliée par chaque DPR.

Choisissez une série couvrant progressivement les besoins.

Par exemple :

400
640
960
1280
1600
2000

Puis mesurez les écarts de poids entre paliers.

Si 1 600 et 1 800 produisent presque le même poids, un palier supplémentaire peut être inutile.

Les paliers doivent-ils être linéaires ?

Non.

Une série :

400
800
1200
1600
2000

est simple.

Mais une progression plus proportionnelle peut parfois mieux répartir les écarts :

400
600
900
1350
2000

L’objectif est d’éviter à la fois :

• trop peu de candidats ;
• trop de candidats presque identiques.

Votre pipeline peut automatiser ce choix.

Faut-il créer des variantes plus grandes que l’original ?

Non.

Si l’original mesure :

1400 px

générer :

2000 px

n’ajoute pas de détail réel.

Vous ne faites qu’interpoler les pixels.

Le srcset doit s’arrêter à la résolution réellement disponible, sauf cas de transformation spécifique assumée.

Faut-il proposer la source originale ?

Pas nécessairement.

Une photographie de 6 000 px peut servir de source maître sans jamais être exposée au navigateur.

Si la largeur maximale utile est 1 920 px, votre plus grande variante Web peut s’arrêter autour de cette valeur ou un peu au-dessus selon la densité visée.

La source maître et la ressource de production ont des rôles différents.

Ne pas oublier la hauteur

Les descripteurs w parlent de largeur, mais vos fichiers possèdent aussi une hauteur.

Pour des variantes de même composition, conservez le ratio.

Si vous générez :

800 × 533
1200 × 800
1600 × 1067

les petites différences d’arrondi sont normales.

Si vous passez soudain à :

1600 × 600

vous avez changé le cadrage.

Traitez alors cette variante comme une direction artistique.

Pourquoi une image peut sembler floue malgré srcset ?

Plusieurs causes :

• candidats trop petits ;
• sizes sous-estime la largeur ;
• compression excessive ;
• source maître déjà floue ;
• CSS agrandit l’image au-delà du prévu.

srcset ne crée pas de détail.

Il permet seulement au navigateur de choisir parmi les ressources fournies.

Pourquoi une page reste lourde malgré srcset ?

Causes fréquentes :

• sizes="100vw" partout ;
• variantes elles-mêmes lourdes ;
• trop d’images chargées immédiatement ;
• images hors écran sans stratégie de chargement ;
• candidats minimaux déjà trop grands ;
• formats inadaptés ;
• cache mal configuré.

Le futur guide Optimiser les images pour les performances Web permettra d’analyser l’ensemble de la chaîne.

Erreur : confondre viewport et conteneur

Une image de contenu peut être limitée à 700 px sur un écran de 1 920 px.

Si vous déclarez :

sizes="100vw"

vous annoncez environ 1 920 CSS px.

Le navigateur peut sélectionner une énorme ressource alors que l’image ne dépassera jamais 700 px.

sizes doit décrire l’image, pas l’écran en général.

Erreur : écrire les breakpoints du CSS sans vérifier les largeurs

Un breakpoint indique qu’une mise en page change.

Il ne dit pas directement quelle largeur prend l’image.

À :

min-width: 1024px

une carte peut occuper :

• 50 % ;
• 33 % ;
• 25 % ;
• 400 px fixes.

Construisez sizes depuis la géométrie réelle du composant.

Erreur : utiliser x pour une image très fluide

Une déclaration :

image.jpg 1x
image@2x.jpg 2x

suppose surtout une taille d’affichage donnée.

Si l’image peut passer de 300 à 1 200 CSS px selon le viewport, les descripteurs w offrent généralement une description plus adaptée.

Erreur : créer un srcset avec des fichiers de largeur incorrecte

Si vous écrivez :

photo.jpg 800w

mais que le fichier mesure réellement 1 200 px, vous fournissez une information fausse.

Les descripteurs doivent correspondre aux ressources.

Un pipeline automatisé réduit ce risque.

Erreur : utiliser sizes sans descripteurs de largeur

Copier :

sizes="..."

sur un srcset en 1x, 2x n’apporte pas la logique attendue.

Comprenez d’abord le mode de sélection utilisé.

Erreur : oublier le fallback <img> dans <picture>

<picture> organise les sources autour de <img>.

L’élément <img> porte le contenu image final et son alternative.

Ne construisez pas un <picture> uniquement avec des <source>.

Erreur : mettre alt sur <source>

L’alternative textuelle appartient à <img>.

Les <source> sont des candidats techniques.

Erreur : changer l’information dans le recadrage mobile

La direction artistique doit préserver le sens essentiel.

Un beau recadrage qui supprime l’élément informatif principal est une mauvaise adaptation.

Erreur : lazy-loader l’image LCP

Une image immédiatement visible et importante ne doit pas être retardée mécaniquement.

Le lazy loading est destiné aux ressources qui peuvent attendre.

Erreur : tester sans vider le cache

Vous pouvez conclure que le navigateur choisit mal alors qu’il réutilise simplement une ressource déjà disponible.

Erreur : générer trop de variantes

Une matrice de 30 fichiers par image augmente :

• build ;
• stockage ;
• invalidation ;
• complexité.

Ajoutez une variante seulement lorsqu’elle répond à un besoin mesurable.

Checklist avant publication

Pour chaque image responsive, vérifiez :

• ai-je une source maître ?
• les variantes sont-elles générées depuis cette source ?
• leurs largeurs sont-elles utiles ?
• le ratio reste-t-il cohérent ?
• les descripteurs w correspondent-ils aux vraies dimensions ?
• sizes correspond-il à la mise en page ?
• ai-je utilisé x seulement lorsque c’est pertinent ?
• le format est-il adapté ?
• la compression est-elle raisonnable ?
• ai-je besoin de <picture> ?
• l’art direction préserve-t-elle l’information ?
• alt est-il correct ?
• width et height réservent-ils l’espace ?
• ai-je testé plusieurs viewports ?
• ai-je testé plusieurs DPR ?
• ai-je vérifié currentSrc ?
• ai-je observé le poids réseau ?
• l’image importante est-elle chargée au bon moment ?
• les images hors écran peuvent-elles être différées ?

Workflow Bethemesh recommandé

Pour préparer manuellement une image responsive :

1. partez du meilleur original disponible ;
2. déterminez la largeur maximale utile avec Quelle résolution choisir pour une image ? ;
3. calculez les dimensions cohérentes avec le calculateur de ratio ;
4. créez plusieurs variantes avec le redimensionneur d’image ;
5. choisissez le format avec PNG, JPEG, WebP ou AVIF ;
6. convertissez si nécessaire avec le convertisseur d’images ;
7. contrôlez la compression avec Comment compresser une image sans perdre en qualité ? ;
8. construisez srcset ;
9. écrivez sizes à partir de la mise en page réelle ;
10. testez currentSrc et le réseau.

Le futur guide Optimiser les images pour les performances Web réunira ce workflow avec chargement, stabilité et mesure.

Ce qu’il faut retenir

Une image responsive ne consiste pas simplement à écrire :

max-width: 100%;

Cette règle adapte l’affichage, pas nécessairement le téléchargement.

Pour adapter la ressource :

• srcset propose des candidats ;
• les descripteurs w décrivent leurs largeurs ;
• sizes indique la largeur d’affichage probable ;
• les descripteurs x conviennent à certains cas de densité ;
• <picture> permet de gérer formats et direction artistique.

La meilleure stratégie ne cherche pas à contrôler chaque décision du navigateur.

Elle lui fournit de bons candidats et de bonnes informations.

Et surtout, les images responsives ne travaillent jamais seules. Elles complètent les décisions déjà prises sur :

• la résolution ;
• le format ;
• la compression.

Elles préparent également les deux dernières étapes de la collection : comprendre les métadonnées et leurs enjeux de confidentialité, puis assembler l’ensemble dans une stratégie complète d’optimisation des images Web.

Questions fréquentes

Quelle différence entre une image fluide et une image responsive ?

Une image fluide adapte sa taille d’affichage au conteneur. Une image responsive permet également au navigateur de choisir entre plusieurs fichiers adaptés au contexte.

À quoi sert srcset ?

srcset fournit une liste de ressources candidates accompagnées de descripteurs de largeur ou de densité.

Que signifie 480w ?

Cela signifie que la ressource candidate possède une largeur intrinsèque de 480 pixels. Ce n’est pas une condition de media query.

Que signifie 2x ?

Cela décrit une ressource destinée à une densité environ deux fois supérieure à une ressource de référence 1x, pour une taille d’affichage donnée.

À quoi sert sizes ?

Avec des descripteurs w, sizes aide le navigateur à estimer la largeur d’affichage de l’image afin de sélectionner un candidat approprié.

Faut-il toujours mettre sizes="100vw" ?

Non. Utilisez-le seulement si l’image occupe réellement environ toute la largeur du viewport. Pour une image limitée par un conteneur ou placée dans une grille, décrivez sa largeur réelle.

Quelle différence entre 480w et (max-width: 480px) ?

480w décrit la largeur d’un fichier. (max-width: 480px) est une condition portant sur le viewport.

Peut-on mélanger w et x dans le même srcset ?

Il faut choisir le mode de description correspondant au besoin. Ne mélangez pas arbitrairement les deux syntaxes.

Quand utiliser les descripteurs x ?

Ils sont pratiques lorsque l’image conserve une taille CSS relativement fixe et que vous souhaitez fournir des variantes adaptées aux différentes densités d’écran.

Quand utiliser les descripteurs w ?

Ils sont généralement préférables lorsque la largeur d’affichage varie selon le viewport ou le conteneur.

À quoi sert <picture> ?

<picture> permet notamment de proposer différents formats ou de changer de composition selon des conditions de media query.

Ai-je besoin de <picture> pour utiliser WebP ?

Pas nécessairement. Si WebP convient à vos navigateurs cibles et à votre stratégie, un simple <img srcset> peut suffire. <picture> devient utile lorsque vous proposez plusieurs familles de sources.

Qu’est-ce que la direction artistique ?

C’est le fait de changer le cadrage ou la composition selon le contexte, par exemple une photo horizontale sur desktop et un recadrage vertical sur mobile.

srcset redimensionne-t-il mes images ?

Non. Vous devez générer les fichiers candidats en amont. Utilisez le redimensionneur d’image.

Combien de variantes faut-il créer ?

Seulement assez pour couvrir efficacement les principales tailles d’affichage et densités sans multiplier inutilement les fichiers. Il n’existe pas de nombre universel.

Faut-il proposer une variante pour chaque breakpoint CSS ?

Non. Les breakpoints et les largeurs de fichiers sont deux choses différentes. Choisissez les variantes selon les besoins de résolution et les écarts de poids.

Pourquoi mon téléphone télécharge-t-il une image deux fois plus large que son affichage CSS ?

Son écran peut avoir un DPR proche de 2. Le navigateur cherche alors davantage de pixels pour conserver la netteté.

Pourquoi le navigateur choisit-il un fichier plus grand que prévu ?

Vérifiez le DPR, sizes, les paliers disponibles et le cache. Le navigateur garde également une certaine latitude dans sa sélection.

Comment savoir quel fichier a réellement été choisi ?

Inspectez le réseau ou utilisez la propriété JavaScript currentSrc de l’élément image.

Pourquoi le fichier ne change-t-il pas quand je réduis la fenêtre ?

Le navigateur peut conserver une grande ressource déjà téléchargée plutôt que d’utiliser davantage de réseau pour en récupérer une plus petite. Rechargez la page dans les nouvelles conditions pour tester.

Une image responsive doit-elle conserver width et height ?

Oui, cela peut être utile pour fournir le ratio intrinsèque et réserver l’espace. CSS peut toujours rendre l’image fluide.

srcset améliore-t-il automatiquement les performances ?

Non. Les candidats doivent être correctement dimensionnés et compressés, et sizes doit correspondre à la mise en page.

Faut-il mettre loading="lazy" sur toutes les images responsives ?

Non. Les images hors écran peuvent en bénéficier, mais une image importante visible immédiatement ne doit pas être retardée mécaniquement.

Les SVG ont-ils besoin de srcset ?

Un SVG réellement vectoriel n’a généralement pas besoin de plusieurs résolutions pour rester net. Une composition différente peut toutefois nécessiter une autre ressource.

Les métadonnées sont-elles copiées dans toutes les variantes ?

Cela dépend du pipeline. Vérifiez votre processus, notamment pour les données EXIF ou GPS. Le prochain article Métadonnées d’image : les lire, les conserver ou les supprimer traite précisément ce sujet.

Quel est le workflow idéal ?

Source maître, dimensions pertinentes, variantes, format, compression, srcset, sizes, puis test dans le navigateur. Le guide Optimiser les images pour les performances Web réunira l’ensemble de ces décisions.