Comment vérifier srcset et sizes pour servir des images adaptées ?

Par l’équipe Limpi. Les faits externes sont distingués des méthodes Limpi et aucune visibilité, position ou citation automatique n’est garantie.

Comprendre images responsives srcset et sizes

srcset et sizes permettent au navigateur de choisir une ressource d’image adaptée à l’espace d’affichage et aux caractéristiques de l’écran. L’objectif est d’éviter d’envoyer systématiquement un fichier très large à un emplacement qui n’en affiche qu’une version beaucoup plus petite.

Inspecter le comportement réellement servi

Pour chaque image importante, relevez la largeur réellement affichée selon plusieurs viewports, les candidats déclarés dans srcset, la valeur sizes et la ressource finalement téléchargée. Utilisez le panneau réseau avec différentes tailles d’écran plutôt que de lire uniquement le HTML.

Distinguer les notions qui se ressemblent

Les images responsives répondent au choix de dimensions de ressource. WebP ou AVIF concernent le format ; la compression concerne le poids à qualité donnée ; width et height peuvent aider à réserver l’espace ; le preload ou la priorité concernent le moment du chargement. Ces sujets interagissent sans être interchangeables.

Identifier les causes les plus probables

Un srcset peut être présent mais inefficace si sizes indique une largeur trop grande, si toutes les variantes ont quasiment la même dimension, si le CMS génère des candidats manquants ou si CSS agrandit l’image au-delà des hypothèses du markup.

Décider ce qui mérite d’être corrigé en premier

Commencez par les images lourdes vues sur mobile, les visuels répétés dans les listes et les images proches du haut de page. Une miniature de catalogue servie avec un fichier de plusieurs milliers de pixels est un cas plus rentable qu’une petite icône.

Corriger à la bonne couche

Générez plusieurs variantes réellement utiles et décrivez le comportement de mise en page avec sizes. Vérifiez que l’URL choisie conserve assez de définition pour l’affichage cible. Ne multipliez pas les variantes sans limite : le jeu doit correspondre aux principaux besoins du design.

Traiter les cas limites sans automatisme

Les images art-directed peuvent nécessiter picture et des sources différentes, alors que srcset seul convient quand le cadrage reste identique. Les écrans à forte densité peuvent sélectionner une ressource plus large que la largeur CSS ; ce n’est pas automatiquement une anomalie.

Valider la correction sur des cas réels

Testez plusieurs largeurs, densités et états de cache. Comparez la ressource sélectionnée avec la taille d’affichage et observez la qualité visuelle. Pour une image LCP, vérifiez séparément que le mécanisme responsive n’a pas ajouté un retard de découverte ou une priorité inadaptée.

Prévenir la régression dans le temps

Reliez les tailles d’images générées aux breakpoints réels du design system et contrôlez les composants qui affichent les médias. Une modification de grille ou de carte peut rendre un ancien sizes obsolète même si le HTML continue à être valide.

Clôturer le contrôle sur images responsives srcset et sizes

Pour clôturer le contrôle « Comment vérifier srcset et sizes pour servir des images adaptées ? », conservez une preuve avant/après : URL ou composant testé, constat initial, origine technique, correction appliquée et résultat de la vérification. Contrôlez aussi les pages liées /seo/performance-technique, /seo/images-webp-avif-performance, /seo/image-lcp-lente-comment-corriger afin de vérifier que la correction reste cohérente avec le reste du corpus. Le périmètre documentaire reste volontairement borné : Expliquer le rôle de srcset et sizes dans le choix d’une ressource adaptée au viewport. Distinguer dimensions d’affichage, format, compression et image LCP. Si le comportement dépend d’un gabarit, d’un CDN, d’un navigateur ou d’un outil tiers, testez au moins un second cas représentatif. Une anomalie ambiguë doit rester en revue plutôt que d’être fermée sur une hypothèse. Attribuez enfin la règle à une source précise — composant, template, serveur, CMS ou configuration — pour pouvoir la retester après une refonte.

Conserver une preuve exploitable dans l’audit

Un contrôle sur images responsives srcset et sizes est utile seulement si une autre personne peut reproduire le constat. Enregistrez la réponse ou l’état observé, l’outil utilisé, le contexte de test et l’élément exact qui justifie la conclusion. Évitez les captures isolées sans URL, statut ou propriété mesurée. Pour les anomalies répétées, comptez les occurrences par gabarit avant et après correction. Cette trace permet de distinguer une résolution globale d’un exemple corrigé manuellement et évite de rouvrir le même diagnostic sans information nouvelle. Lorsque la documentation officielle est la borne du contrôle, notez également la source utilisée afin de pouvoir réévaluer la règle si elle évolue.

Tester un scénario représentatif

Prenez une image de héros et une vignette de carte affichées avec des dimensions très différentes. Dans les DevTools, émulez 360 px, 768 px puis un écran desktop dense. Notez currentSrc, largeur intrinsèque, largeur CSS et candidat choisi dans srcset. Modifiez ensuite temporairement sizes pour observer comment une mauvaise estimation pousse le navigateur vers un fichier surdimensionné. Comparez un jeu de variantes 480, 960 et 1600 pixels sans changer le format, puis répétez avec WebP ou AVIF pour ne pas mélanger bénéfice du format et bénéfice du responsive. Sur l’image LCP, contrôlez aussi le moment de découverte et la priorité, car un srcset correct ne compense pas un chargement lancé trop tard. Cette méthode produit des preuves concrètes de surdimensionnement par viewport. Le relevé doit contenir src, srcset, sizes, currentSrc, naturalWidth, clientWidth, devicePixelRatio et poids transféré. Testez les candidats 320w, 640w, 960w ou ceux réellement générés par le CMS. Sur picture, notez media et type pour distinguer art direction et simple changement de format. Cette matrice révèle si le navigateur choisit un fichier plus lourd à cause de sizes, d’un breakpoint CSS ou d’une variante absente. Incluez une carte produit à 180 px de large dans une grille et la même image ouverte en galerie à 900 px. Le CMS doit pouvoir fournir des candidats adaptés aux deux contextes sans forcer la vignette à télécharger la variante de galerie ni dégrader l’agrandissement haute densité. Testez loading=lazy, fetchpriority, decoding, width, height et aspect-ratio séparément de srcset. Pour une image de héros, vérifiez si le candidat choisi est découvert dans le HTML initial ; pour une image sous la ligne de flottaison, observez le moment où la requête démarre lors du scroll. Ces propriétés permettent d’expliquer poids, stabilité et priorité sans les mélanger.

Sources officielles

Les règles des moteurs et des fournisseurs de crawlers peuvent évoluer. Les affirmations techniques de cette page sont bornées par les documentations officielles ci-dessous.

• webdev responsive images