Images responsives : comment le navigateur choisit une image ?
Remettre les images responsives à plat n’est pas une nostalgie ni un retour sur d’anciens formats, c’est une nécessité. En juin 2013, l’article « Les médias et les multimédias » présentait l’ensemble des nouveaux éléments HTML5 dans un contexte où audio, video, svg, canvas et contenus externes étaient encore en construction. Aujourd’hui, ces domaines ont mûri, les vidéos se lisent sans effort, le SVG irrigue l’interface moderne, canvas suit son propre élan et les plugins appartiennent au passé.
Pourtant, un sujet demeure mal compris malgré une abondante documentation, la manière dont le navigateur choisit une image, lit la mise en page, évalue l’espace utile et décide de la ressource à charger. De nombreux articles détaillent srcset, sizes et picture, leurs syntaxes et leurs cas particuliers, mais peu décrivent ce qui se passe réellement dans le moteur de rendu au moment précis où cette décision est prise.
L’objectif n’est pas d’ajouter un guide de plus, mais de clarifier le raisonnement, comprendre le comment pour éclairer le pourquoi, comprendre le fonctionnement avant d’intégrer la solution. Il s’agit simplement de proposer une lecture orientée vers la logique du navigateur, afin de produire moins d’images, mais mieux ajustées.
Comprendre la page avant de comprendre l’image
Un navigateur ne choisit pas une image pour un écran, il la choisit pour un espace dans la page. Avant même de charger la moindre ressource, il sait déjà plusieurs choses : la largeur du conteneur, la densité de l’affichage, et la façon dont l’image s’insère dans le flux. C’est ce calcul initial qui guide toute la suite. Nous en disons davantage dans le sous-chapitre « Ce que disent vraiment les moteurs de rendu ».
Pour comprendre cette mécanique, imaginons une situation très simple : une page avec une colonne principale affichée en 600 pixels CSS de large, contenant une image déclarée comme responsive. Même sans image, le navigateur peut déjà estimer que l’espace utile sera proche de ces 600 pixels. C’est cette valeur qui oriente son choix.
<img
src="photo-800.jpg"
srcset="photo-400.jpg 400w, photo-800.jpg 800w, photo-1200.jpg 1200w"
sizes="100vw"
alt="">Dans cet exemple, avant même l’affichage, le navigateur détermine : « l’image doit probablement occuper environ 600w, donc je choisis la ressource la plus proche ». Ce raisonnement est décrit en détail sur MDN dans <img>: The Image Embed element. Dans un layout plus complexe, comme une grille CSS, le navigateur anticipe également la place probable :
.grid img {
width: 100%;
object-fit: cover;
}Même si la grille se redimensionne selon la fenêtre, le navigateur calcule une largeur approximative à partir des règles CSS. Il n’a pas besoin que l’image soit chargée pour comprendre que chaque cellule prendra une portion variable du viewport.
Sur StackOverflow, plusieurs discussions l’illustrent, notamment lorsque la largeur réelle d’une colonne diffère de ce que l’on imagine, notamment Can I use <img srcset> or <picture> for image size rather than viewport size ?
Pourquoi srcset densité (1x, 2x) n’a jamais suffi
La syntaxe densité était suffisante en 2013. Plus aujourd’hui. Elle repose sur une logique simple : fournir deux versions d’une même image, l’une pour les écrans classiques, l’autre pour les écrans à forte densité. Cette approche reste valable uniquement si l’image occupe toujours la même place dans la mise en page.
<img
src="image-1x.jpg"
srcset="image-1x.jpg 1x, image-2x.jpg 2x"
alt="Description de l’image"
>
Dans un site réellement responsive, la taille d’affichage de l’image varie selon les contextes. Un même fichier peut apparaître en pleine largeur sur mobile, puis dans une colonne étroite sur desktop, puis dans une grille flexible. La logique densité ne sait pas s’adapter à ces changements : elle ne raisonne qu’en termes de netteté, jamais en termes de largeur utile.
Cette limite ne vient pas d’une « mauvaise utilisation » de la syntaxe 1x/2x, ni d’une recommandation explicite des documentations officielles. Elle découle simplement de la manière dont fonctionne un site responsive : pour choisir la bonne ressource, le navigateur doit connaître la largeur réelle que l’image occupera dans la page. La densité n’exprime pas cette largeur. Elle n’indique que la finesse d’affichage attendue.
En pratique, cela signifie que le navigateur ne peut pas anticiper si l’image fera 320 px, 600 px ou 1100 px dans le layout. Il ne peut donc pas ajuster le choix de fichier en fonction de l’espace disponible. La densité améliore la netteté, mais ne guide pas le choix en termes de dimensions.
C’est pourquoi il est essentiel de comprendre ce que représentent réellement les pixels CSS et la densité d’affichage, notions abordées dans le chapitre suivant afin d’éclairer ce fonctionnement plus en profondeur.
Pixels CSS et pixels physiques
Les navigateurs utilisent les pixels CSS pour comprendre la taille réelle d’un élément dans la page. Un pixel CSS n’est pas un pixel matériel. C’est une unité logique, conçue pour garder un repère cohérent malgré la variété des écrans. C’est d’ailleurs la raison pour laquelle on ajoute presque toujours <meta name="viewport" content="width=device-width,initial-scale=1.0,maximum-scale=1"> dans les pages mobiles : sans cette directive, les navigateurs mobiles simulent un écran plus large que la réalité et redimensionnent toute la mise en page. Ainsi, un bloc affiché à 600 pixels CSS peut occuper 1200 pixels physiques sur un écran Retina, mais pour le navigateur, sa largeur reste 600.
Pour bien comprendre cela, il faut introduire la notion de densité d’affichage (voir MDN : Device pixel et Window.devicePixelRatio). La densité correspond au rapport entre pixels physiques et pixels CSS. On parle souvent de device pixel ratio (DPR). Un écran avec un DPR de 2 affiche deux pixels matériels pour un pixel CSS, un écran avec un DPR de 3 en affiche trois, et ainsi de suite. Cette densité n’augmente pas la place disponible dans la page, elle ne fait qu’affiner l’affichage.
C’est ce point qui oriente le choix d’image : le navigateur sélectionne une ressource adaptée à la largeur affichée dans la page, pas à la densité brute de l’écran. Autrement dit, le navigateur ne se dit jamais « cet écran a beaucoup de pixels, donc il me faut une image énorme ». Il commence toujours par la largeur logique disponible dans la mise en page, exprimée en pixels CSS. La densité physique intervient ensuite, uniquement pour choisir une ressource plus nette lorsque plusieurs alternatives sont proches.
Pour expérimenter concrètement ces notions, une page de démonstration est disponible via le lien suivant : dpr-demo.html. Elle permet d’observer en direct quelle image est choisie par le navigateur selon la densité de l’écran et la largeur disponible dans la page.
Dans cette démonstration, chaque image affiche en haut à gauche une mention intégrée dans le visuel : DPR1, DPR2 ou DPR3. Cette inscription n’est pas interprétée par le navigateur : elle sert uniquement à montrer clairement, à l’œil nu, quelle ressource est réellement sélectionnée. Cela évite les ambiguïtés et permet d’identifier immédiatement si le navigateur décide d’utiliser la version 1x, 2x ou 3x.
Il est important enfin de préciser que, quel que soit le comportement du navigateur, c’est toujours l’écran lui‑même qui impose la limite finale. Firefox peut simuler différents DPR dans son outil responsive, mais il ne pourra jamais afficher une image d’une netteté inférieure à celle permise par la dalle physique. Autrement dit, un écran Retina n’affichera jamais visuellement une image comme un écran 1x, même si le simulateur annonce un DPR faible. L’affichage final reste contraint par les capacités matérielles du dispositif.
Ce que disent vraiment les moteurs de rendu
Comprendre la logique du navigateur, c’est aussi s’appuyer sur ce que documentent les moteurs eux-mêmes. Chrome, Firefox et le W3C décrivent clairement la façon dont ils évaluent la mise en page et sélectionnent une image.
- Les spécifications du WHATWG détaillent l’algorithme complet de choix d’image : calcul de la taille CSS, estimation de la largeur utile, sélection du meilleur candidat. Le document est exigeant, mais il éclaire le fonctionnement réel du navigateur.
- Chez Blink (le moteur de Chrome, Edge et Opera), plusieurs ressources expliquent comment le navigateur choisit la ressource la plus adaptée. L’analyse proposée sur web.dev, Images responsives, reste l’une des plus accessibles.:
- Pour Gecko (Firefox), MDN met en avant la manière dont les éléments remplacés, comme les images, sont intégrés au layout. Ces notions éclairent la manière dont la largeur utile est calculée, voir sur MDN Élément remplacé.
srcset avec w : quand le navigateur mesure l’espace
Les descripteurs en w introduisent une logique entièrement nouvelle. Au lieu d’associer chaque ressource à une densité d’écran, ils indiquent sa largeur réelle. Le navigateur n’a plus besoin de deviner : il peut choisir la ressource qui correspond le mieux à la place que l’image occupera dans le layout.
<img
src="400.jpg"
srcset="
400.jpg 400w,
800.jpg 800w,
1200.jpg 1200w
"
alt="Description de l’image"
>Ici, chaque fichier est associé à sa largeur intrinsèque. Le navigateur peut alors poser une question simple :
« De quelle largeur vais‑je avoir besoin dans cette page ? »
Ce raisonnement ne dépend ni de l’écran, ni de la densité, mais de la mise en forme. Le navigateur analyse la structure, les règles CSS, les contraintes du conteneur, et estime la largeur effective que l’image occupera une fois intégrée. Cette étape se déroule avant même que la première ressource ne soit chargée. Dans une colonne flexible, par exemple, l’image peut mesurer 600 px sur desktop, 350 px dans un layout intermédiaire, ou 100 % du viewport sur mobile. Les descripteurs en w permettent au navigateur de sélectionner la ressource la plus adaptée à chacune de ces situations, sans surcharger la bande passante.
C’est cette anticipation, centrale dans le web moderne, qui rend possible une sélection d’image réellement responsive. Le navigateur raisonne désormais sur l’espace disponible, et non sur les capacités matérielles de l’appareil. La densité intervient seulement ensuite, pour affiner la netteté, mais elle n’est plus le point de départ. C’est ici que le navigateur combine la largeur utile qu’il a calculée avec le devicePixelRatio de l’écran, afin de choisir automatiquement la ressource la plus nette disponible. Autrement dit, un set en w suffit pour servir des images adaptées aux écrans haute densité sans qu’il soit nécessaire d’ajouter des notations en 1x ou 2x.
Une question se pose alors naturellement : comment le navigateur sait‑il, selon la mise en page, quelle largeur l’image occupera réellement ? C’est précisément à ce besoin que répond l’attribut sizes, qui fera l’objet du chapitre suivant.
sizes : le navigateur ne devine pas, il anticipe
L’attribut sizes complète les descripteurs en w en donnant au navigateur une information qui manque encore : la largeur que l’image est censée occuper dans la mise en page. Là où w décrit la largeur réelle des fichiers, sizes décrit l’intention de mise en forme. Le navigateur peut ainsi estimer l’espace utile avant même de charger une seule ressource.
<img
src="400.jpg"
srcset="
400.jpg 400w,
800.jpg 800w,
1200.jpg 1200w
"
sizes="(min-width: 900px) 50vw, 100vw"
alt=""
/>
<!-- (min-width:900px) : condition CSS ;
50vw : largeur utilisée si condition vraie ;
100vw : largeur par défaut
-->Ici, deux comportements sont définis : lorsque la fenêtre dépasse 900 px CSS, l’image occupe 50 % de cet espace ; en dessous, elle utilise 100 % du viewport. À partir de ces règles, le navigateur déduit une largeur probable. Avec une fenêtre de 960 px CSS, 50vw équivaut à 480 px CSS. Une fois cette largeur estimée, il compare cette valeur aux ressources du srcset :
- Question : « Quelle largeur l’image occupera dans ce contexte ? »
- Déduction : « Elle fera environ 480 px CSS. »
- Choix : « Je sélectionne la ressource la plus proche sans être inférieure, donc 800w. »
sizes fournit ainsi une règle d’anticipation essentielle. Il permet au navigateur de choisir immédiatement la ressource la plus adaptée à la mise en page, en tenant compte de la largeur utile plutôt que de la seule densité de l’écran.
Quand utiliser <picture> : intention avant technique
La balise <picture> intervient dans un cas précis : lorsqu’il faut prendre une décision que srcset et sizes ne peuvent pas exprimer seuls. Ces deux attributs gèrent parfaitement les variations de taille, de densité et d’espace disponible, mais ne peuvent pas changer le visuel lui‑même ni adapter le format selon les capacités du navigateur.
<picture> est donc utilisé lorsqu’il faut combiner deux axes distincts :
- Le contexte d’affichage : mobile, desktop, orientation, largeur, ratio… (via
media). - Les capacités techniques du navigateur : formats pris en charge, décodage matériel, priorité entre AVIF, WebP, JPEG… (via
type).
Autrement dit, <picture> permet d’exprimer : « Si le contexte est celui‑ci → utilise ce visuel‑là. Et parmi ce visuel, si ton navigateur sait lire tel format → privilégie‑le. ». C’est ce croisement, changement de visuel et changement de format, qui dépasse les possibilités de srcset et sizes, lesquels ne modifient que la taille d’un même fichier, jamais son interprétation éditoriale. Voici un exemple volontairement complet, qui montre toute la puissance de <picture> :
<picture>
<!-- Cadrage serré + formats modernes -->
<source media="(max-width: 700px)" srcset="cadrage_serre.avif" type="image/avif">
<source media="(max-width: 700px)" srcset="cadrage_serre.webp" type="image/webp">
<!-- Fallback spécifique cadrage serré -->
<source media="(max-width: 700px)" srcset="cadrage_serre.jpg" type="image/jpeg">
<!-- Cadrage large + formats modernes -->
<!-- Portrait desktop classique -->
<source media="(min-width: 701px) and (orientation: portrait)" srcset="cadrage_large.avif" type="image/avif">
<source media="(min-width: 701px) and (orientation: portrait)" srcset="cadrage_large.webp" type="image/webp">
<!-- Fallback spécifique cadrage large portrait -->
<source media="(min-width: 701px) and (orientation: portrait)" srcset="cadrage_large.jpg" type="image/jpeg">
<!-- Paysage large, visuel allégé ou ratio 16/9 -->
<source media="(min-width: 701px) and (orientation: landscape)" srcset="cadrage_large_169.avif" type="image/avif">
<source media="(min-width: 701px) and (orientation: landscape)" srcset="cadrage_large_169.webp" type="image/webp">
<!-- Fallback spécifique cadrage large paysage -->
<source media="(min-width: 701px) and (orientation: landscape)" srcset="cadrage_large_169.jpg" type="image/jpeg">
<!-- Fallback universel -->
<img src="cadrage_media.jpg" alt="Description du visuel">
</picture>
Dans cet exemple, cadrage-contexte.html, deux logiques distinctes se croisent clairement.
- D’un côté, la logique éditoriale : le cadrage change réellement selon le contexte (cadrage serré en petite largeur, cadrage large ou panoramique en paysage, etc.).
- D’un autre côté, une logique technique : pour chaque contexte, plusieurs formats sont proposés, du plus performant au plus compatible.
Le navigateur reste strict : il évalue d’abord les conditions media, puis sélectionne la première source dont le format est pris en charge. Seule la balise <img> reçoit le texte alternatif, car les <source> ne représentent jamais une image visible.
Texte alternatif et accessibilité
L’attribut alt ne s’applique qu’à la balise <img>. Les éléments <source> ne portent aucun texte alternatif : ils ne font que proposer des variantes. Le texte alternatif doit donc être placé dans <img>, utilisé si aucune source n’est compatible ou si les formats échouent.
Cas particulier : impression (media= »print »)
<picture> peut également adapter l’image lors de l’impression, en fournissant une version simplifiée, monochrome ou conçue pour le papier.
<picture>
<!-- Autres règles éventuelles placées avant -->
<!-- Versions dédiées à l’impression -->
<source media="print" srcset="visuel-print.tiff" type="image/tiff">
<source media="print" srcset="visuel-print.svg" type="image/svg+xml">
<source media="print" srcset="visuel-print.png" type="image/png">
<!-- Fallback spécifique impression -->
<source media="print" srcset="visuel-print.jpg" type="image/jpeg">
<!-- Fallback universel (utilisé hors impression) -->
<img src="cadrage_media.jpg" alt="Description du visuel">
</picture>
Le navigateur utilisera visuel-print.* en impression, et cadrage_media.jpg dans les autres contextes.
<picture>ne remplace passrcsetetsizes, il les complète lorsqu’il faut changer de visuel, changer de format ou exprimer une intention éditoriale forte dictée par le contexte d’affichage.
Penser comme un navigateur, comprendre trois comportements clés
Pour entrer dans la logique du navigateur, il faut comprendre qu’il ne « regarde » jamais une image isolément. Il lit une structure, interprète un contexte et projette la place probable que l’image occupera. Ce chapitre met à plat ce qui a été établi dans les chapitres précédents et montre comment les outils présentés, w, x, sizes et picture, se traduisent dans des situations concrètes.
Autrement dit, il ne s’agit plus seulement d’expliquer des mécanismes, mais d’observer comment le navigateur tranche réellement selon la mise en page. À chaque situation, pleine largeur, colonne flexible ou grille, il croise ce qu’il observe dans le layout avec ce que nous avons exprimé dans les attributs, pour sélectionner la ressource la plus cohérente. srcset, les notations x et w, les règles sizes et, lorsque nécessaire, un picture qui introduit plusieurs chemins possibles.
Pleine largeur, logique en w
Ici, la largeur dépend du layout, donc la logique en w est la plus pertinente car le navigateur choisit la ressource la plus adaptée en fonction de la largeur utile qu’il a calculée.
<img src="hero-800.jpg"
srcset="hero-480.jpg 480w, hero-800.jpg 800w, hero-1200.jpg 1200w"
sizes="(min-width: 900px) 800px, 100vw" alt="">Colonne flexible, logique mixte sizes et x
Dans une colonne flexible, la largeur fluctue selon les marges, le flux ou le parent. Le navigateur estime cette largeur grâce aux règles sizes. Si l’image garde un gabarit constant, la logique en x devient un choix naturel :
<img src="portrait-1x.jpg"
srcset="portrait.jpg 1x, portrait@2x.jpg 2x"
sizes="(min-width: 700px) 50vw, 100vw"
alt="">Le fichier portrait@2x.jpg apporte la précision nécessaire sur écrans haute densité. Dans ce cas, le navigateur choisit simplement une version adaptée au nombre de pixels physiques, tout en conservant la largeur CSS qu’il a anticipée.
Dans une colonne flexible, la largeur n’est plus une donnée stable. Elle dépend du flux, des marges ou des contraintes du parent. Le navigateur recalcule alors une largeur probable, parfois révisée en cours de route, puis sélectionne la ressource la plus cohérente en fonction des valeurs de sizes que nous avons fixées. Ces règles deviennent ici essentielles puisque c’est elles qui orientent son estimation.
Grille et changement de format, usage naturel de picture
Dans une grille, les ratios, espacements et comportements du container influencent la place finale. Lorsque le visuel doit changer selon le contexte, un picture permet d’exprimer clairement cette intention :
<picture>
<source srcset="banner-wide.jpg" media="(min-width: 1000px)">
<img src="banner-mobile.jpg" alt="">
</picture>Dans cet exemple, une seule <source> suffit, car une seule condition distincte est nécessaire : afficher une version large au‑delà de 1000 px, et sinon laisser le navigateur utiliser l’image par défaut. Lorsque plusieurs ruptures visuelles sont prévues, plusieurs <source> peuvent être empilées, chacune exprimant une intention propre. Le navigateur compare les conditions, retient la bonne branche, puis sélectionne la ressource adaptée. Ce processus montre que la sélection d’une image n’est jamais un simple match entre valeurs, mais un dialogue constant entre la mise en page et nos intentions exprimées dans les attributs.
En conclusion, chaque approche correspond à une intention. Le w accompagne les mises en page qui varient, le x garantit la qualité sur écrans denses et picture permet de changer réellement de visuel selon le contexte. Intégrés au fil de la conception, ces choix construisent un équilibre durable entre lisibilité, performance et justesse visuelle.
Produire juste, pas beaucoup, une méthode simple et réaliste
Produire des images responsives commence par une intention précise : définir le rôle de l’image dans la page. Une image immersive n’a pas les mêmes besoins qu’une vignette intégrée dans une grille ou qu’une illustration placée dans une colonne. Nous partons donc de situations concrètes : une pleine largeur qui doit rester nette sur un grand écran, une colonne qui varie selon les tailles de viewports, une carte ou un encadré dont les proportions resteront stables.
Une fois ces contextes identifiés, nous observons les largeurs réellement rencontrées. Dans un layout moderne, quatre zones dominent : environ 480 px pour le mobile, 768 px pour les tablettes, autour de 1200 px pour les écrans moyens, et 1920 px pour le plein écran. Ces paliers ne sont pas arbitraires ; ils correspondent à des comportements typiques des mises en page.
<img src="visuel-1200.jpg"
srcset="visuel-480.jpg 480w,
visuel-768.jpg 768w,
visuel-1200.jpg 1200w,
visuel-1920.jpg 1920w"
sizes="(min-width: 1200px) 1200px,
(min-width: 768px) 768px,
100vw"
alt="">Ce fragment illustre une stratégie sobre : quatre fichiers, chacun correspondant à une véritable largeur rencontrée dans la mise en page, et des règles sizes calquées sur les comportements du layout. Ce choix repose ici sur la logique w, mais les approches en x, sizes et picture obéissent au même principe : proposer au navigateur un ensemble d’images cohérent et limité, aligné sur nos besoins réels.
L’objectif n’est pas d’inonder les possibilités, mais de répondre aux situations concrètes. Trop de variantes compliquent la maintenance et perturbent la lecture du code, sans gain notable pour l’affichage. En visant la clarté, quelques paliers pertinents et un ensemble maîtrisé, nous construisons un système capable de s’adapter à différents contextes et écrans, anciens comme haute résolution, tout en conservant une structure efficace et pérenne.
Conclusion, comprendre avant d’intégrer
L’enjeu n’est pas d’appliquer mécaniquement srcset, sizes ou picture, mais de comprendre pourquoi ces outils existent et comment ils dialoguent pour guider le navigateur. Leur force réside dans leur complémentarité, pas dans leur accumulation.
L’article publié en 2013, Les médias et les multimédias, appartenait à une période où HTML5 et les formats visuels cherchaient encore leur place. Cette conclusion en constitue un prolongement naturel : un passage d’une époque de transition à une maturité où l’intention prévaut sur la technique, et où l’on intègre une image en comprenant ce que le navigateur perçoit réellement.
