Images responsives : srcset, sizes, chargement différé et fetchpriority

Performance & typographie · Par la rédaction de Gabarit · Publié le 2026-10-27

Mains sur le clavier d'un ordinateur portable affichant un éditeur de code, sur une table claire — Travail sur ordinateur portable. Photographie de Crew, CC0 (Wikimedia Commons).

Les images sont souvent les fichiers les plus lourds d'une page, et l'image de tête est presque toujours l'élément que mesure le LCP. Bien les servir tient en une poignée d'attributs HTML, que WordPress ajoute en partie tout seul. Encore faut-il savoir ce qu'ils font, pour ne pas les annuler par un réglage de thème ou d'extension.

srcset et sizes : la bonne taille pour chaque écran

Une photo de 1 920 pixels de large affichée dans une colonne de 360 pixels sur un téléphone, c'est plusieurs centaines de kilo-octets transférés pour rien. L'attribut srcset règle le problème en listant plusieurs fichiers et leur largeur réelle ; le navigateur choisit le plus adapté à l'écran et à sa densité de pixels.

<img src="/img/atelier.webp"
     srcset="/img/atelier-s.webp 640w, /img/atelier.webp 960w"
     sizes="(max-width: 719px) 100vw, 720px"
     width="960" height="640"
     alt="Établi d'un atelier de reliure, outils alignés">

L'attribut sizes est le plus souvent oublié, ou mal renseigné. Il indique la largeur que l'image occupera dans la mise en page, selon la largeur de la fenêtre : ici, toute la largeur de l'écran jusqu'à 719 pixels, puis 720 pixels fixes. Sans lui, le navigateur suppose que l'image occupe toute la largeur de la fenêtre et choisit souvent un fichier trop grand. Un sizes juste demande de connaître la mise en page du thème : c'est un travail de conception autant que de code.

WordPress produit ces attributs depuis la version 4.4, comme l'a annoncé la note de développement « Responsive Images in WordPress 4.4 » : à chaque envoi d'image, il crée plusieurs tailles intermédiaires et les liste dans srcset. Le thème peut ajuster les tailles générées et la valeur de sizes.

width et height : réserver la place

Sans dimensions, le navigateur ne sait pas quelle hauteur réserver avant d'avoir reçu l'image : le texte s'affiche, puis saute vers le bas quand l'image arrive. C'est la cause la plus fréquente d'un mauvais score CLS, détaillé dans notre article sur les Core Web Vitals.

Les navigateurs récents calculent le rapport largeur/hauteur à partir des attributs width et height, même si la CSS redimensionne l'image avec max-width: 100%; height: auto. Il suffit donc d'indiquer les dimensions intrinsèques du fichier. La note de développement de WordPress 5.5 explique que le logiciel complète désormais ces attributs quand ils manquent, pour les images de la médiathèque qui portent la classe wp-image-{id}.

Le chargement différé, au bon endroit

L'attribut loading="lazy" demande au navigateur de ne charger une image qu'à l'approche de la zone visible. Sur une longue page d'articles, c'est un gain considérable. La même note de développement précise que, depuis WordPress 5.5, le logiciel ajoute par défaut loading="lazy" à toutes les balises img qui comportent les attributs width et height.

Le revers est connu : appliqué à l'image visible dès l'ouverture de la page, le chargement différé retarde justement l'élément que mesure le LCP. WordPress a corrigé ce comportement par étapes : la note de 2023 sur les performances des images rappelle que ce travail a commencé avec WordPress 5.9, s'est poursuivi en 6.2 et a été achevé en 6.3, pour ne plus différer les images situées dans la fenêtre au chargement.

fetchpriority : passer devant

Même sans chargement différé, l'image principale entre en concurrence avec les feuilles de style, les scripts et les polices. L'attribut fetchpriority="high" signale au navigateur qu'elle est prioritaire. Depuis WordPress 6.3, le logiciel l'ajoute automatiquement à l'image qu'il juge la plus susceptible d'être l'image LCP. Un thème peut l'aider en marquant explicitement son image de tête, et en évitant de précharger trop d'autres ressources.

Les images de fond et les cas particuliers

Tout ce qui précède vaut pour les balises img. Une image de fond déclarée en CSS, fréquente dans les bandeaux de page d'accueil, échappe à srcset, au chargement différé natif et à l'attribut fetchpriority ; le navigateur ne la découvre qu'après avoir lu la feuille de style. Quand cette image est l'élément principal de la page, mieux vaut la transformer en vraie balise img positionnée sous le texte, ou la précharger explicitement. L'élément picture, lui, sert à proposer des cadrages différents selon l'écran, par exemple une version carrée sur mobile et panoramique sur ordinateur.

Format et poids

Le format WebP, lu par tous les navigateurs actuels, produit à qualité visuelle égale des fichiers généralement plus légers que le JPEG pour les photos. AVIF va plus loin, au prix d'un encodage plus lent. Quelques règles simples valent quel que soit le format :

Recadrer avant d'envoyer : une image au rapport prévu par le thème évite de transférer des pixels qui seront masqués.
Ne pas dépasser la plus grande taille affichée, multipliée par deux au plus pour les écrans haute densité.
Régler la qualité de compression en regardant le résultat, pas seulement le poids.
Écrire une alternative textuelle utile pour chaque image porteuse d'information, et un alt="" vide pour les images décoratives : la performance ne doit pas se faire au détriment de l'accessibilité.

Ce que le thème doit faire

Un thème WordPress bien conçu n'empêche pas ces mécanismes de fonctionner. Concrètement : il déclare des tailles d'image qui correspondent à sa mise en page, renseigne un sizes réaliste pour ses images de tête et ses cartes, utilise les fonctions de WordPress pour afficher les images plutôt qu'un code HTML écrit à la main, et laisse les dimensions dans le balisage. Une extension d'optimisation peut compléter ce travail ; elle ne remplace pas un thème qui le fait correctement dès le départ.

Images légères et polices auto-hébergées bien chargées forment l'essentiel du travail de performance d'un site éditorial. Le reste tient le plus souvent au nombre d'extensions et de scripts tiers.