L'essentiel à retenir : WordPress génère automatiquement les attributs srcset et sizes sur chaque image depuis la version 4.4 — le problème sur la plupart des sites n'est pas une fonctionnalité manquante, c'est une valeur sizes incorrecte qui indique silencieusement au navigateur de télécharger un fichier plus gros que ce dont la mise en page a réellement besoin. Corriger cet unique attribut est généralement le changement d'image responsive le plus rentable que vous puissiez faire.
Ce que srcset et sizes font réellement
Une balise <img> responsive sur WordPress ressemble à ceci :
<img src="image-1024x683.jpg"
srcset="image-300x200.jpg 300w, image-768x512.jpg 768w, image-1024x683.jpg 1024w"
sizes="(max-width: 600px) 100vw, 600px">
srcset liste les candidats de fichiers disponibles et leurs largeurs réelles en pixels. sizes indique au navigateur la largeur réelle d'affichage de l'image à différentes largeurs de viewport. Le navigateur combine les deux, avec la densité d'écran de l'appareil, pour choisir le plus petit fichier qui restera net — avant même de télécharger quoi que ce soit.
C'est le point à souligner : c'est le navigateur qui prend la décision, pas WordPress ni un plugin. Si sizes est exact, le navigateur prend automatiquement une bonne décision. Si sizes est incorrect, le navigateur prend une décision assurée, rapide et fausse — généralement en optant pour un fichier plus grand "par précaution".
Où l'estimation par défaut de WordPress échoue
WordPress calcule une valeur sizes par défaut selon une règle simple : il suppose que l'image s'affiche à sa propre largeur intrinsèque, jusqu'à la largeur du viewport. Cette hypothèse tient pour un simple article de blog en une colonne. Elle échoue dans de nombreuses mises en page WordPress courantes :
- Mises en page en grille et colonnes — une grille de produits affichant 3 images par ligne affiche chaque image à environ un tiers de la largeur du conteneur, pas à la largeur intrinsèque complète de l'image.
- Mises en page de constructeurs de pages — Elementor, Divi et constructeurs similaires définissent souvent les largeurs de conteneur via CSS, ce dont le calcul
sizescôté PHP de WordPress n'a aucune visibilité. - Thèmes avec barre latérale — la colonne de contenu réelle est plus étroite que le viewport, mais le calcul par défaut ne le sait pas.
Dans chaque cas, on indique au navigateur "cette image s'affiche proche de la pleine largeur du viewport", donc il télécharge un candidat dimensionné en conséquence — même si l'image est rendue bien plus petite à l'écran.
Comment vérifier si votre site a ce problème
- Ouvrez la page dans Chrome, faites un clic droit sur une image de contenu et choisissez Inspecter.
- Dans le panneau Elements, trouvez l'attribut
sizessur la balise<img>. - Comparez-le à la largeur réellement rendue de l'image — visible dans le panneau Computed sous
width. - Si
sizesprétend quelque chose de proche de la pleine largeur du viewport mais que l'image est rendue à, disons, 33 % du conteneur, le navigateur télécharge très probablement un fichier 2 à 3 fois plus gros que nécessaire.
Une vérification plus rapide : ouvrez l'onglet Network, filtrez par Img, et comparez les dimensions en pixels du fichier téléchargé (visibles dans l'onglet Preview) à sa taille CSS rendue. Un grand écart entre les deux est la signature d'une valeur sizes défectueuse.
Corriger l'attribut sizes
Pour la plupart des thèmes, cela signifie remplacer le calcul par défaut de WordPress par une valeur correspondant à votre mise en page réelle, à l'aide du filtre wp_calculate_image_sizes :
add_filter('wp_calculate_image_sizes', function ($sizes, $size) {
return '(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw';
}, 10, 2);
Les points de rupture exacts doivent correspondre au comportement réel de votre grille CSS ou conteneur de thème — cet exemple suppose une mise en page affichant une colonne sur mobile, deux sur tablette et trois sur desktop. Vérifiez les vrais points de rupture dans la feuille de style de votre thème plutôt que de les deviner.
Enregistrer les bonnes tailles d'image dès le départ
srcset ne peut proposer que des candidats qui existent réellement. Si votre thème n'enregistre qu'une taille de miniature 1024px et 300px, le navigateur n'a pas d'option 600px à choisir pour un viewport de taille moyenne — il doit choisir la plus proche disponible, qui reste souvent trop grande. Enregistrer des tailles intermédiaires avec add_image_size() donne au navigateur des options plus fines :
| Nom de taille | Largeur | Usage typique |
|---|---|---|
| thumbnail | 150px | Listes admin, cartes d'articles liés |
| medium | 600px | Largeur de contenu mobile |
| medium_large | 900px | Largeur de contenu tablette |
| large | 1200px | Largeur de contenu desktop |
| full | Téléversement original | Rarement le bon choix à livrer directement |
Enregistrer une taille ne la régénère pas pour les images déjà téléversées — les nouvelles tailles ne s'appliquent qu'à l'avenir, ou après avoir exécuté un outil de régénération sur les médias existants.
Un exemple concret
Lors d'un audit récent d'un blog WordPress utilisant une grille d'articles liés à 3 colonnes, l'attribut sizes par défaut prétendait que chaque miniature s'affichait à 100vw (pleine largeur du viewport) sur toutes les tailles d'écran. En réalité, chaque miniature était rendue à environ 320px sur desktop.
| Avant correction | Après correction | |
|---|---|---|
| Candidat choisi par le navigateur | Fichier de 1024px de large | Fichier de 384px de large |
| Taille moyenne de fichier par miniature | 145 Ko | 38 Ko |
| Poids total pour une grille de 6 miniatures | 870 Ko | 228 Ko |
Corriger un seul filtre sizes a réduit d'environ 640 Ko cette seule page — plus que ce que la plupart des réglages de compression d'image atteindraient seuls, car le problème n'était pas la compression, mais le fait de demander un fichier quatre fois plus grand que celui affiché.
Où l'optimisation de format garde son utilité
Bien régler srcset/sizes contrôle quelles dimensions sont téléchargées. Cela ne contrôle pas le format de ces fichiers. Un JPEG de 384px correctement dimensionné reste plus lourd que nécessaire si une version WebP ou AVIF de 384px pouvait paraître identique avec un fichier plus petit. C'est ici qu'Erdo Image Optimizer intervient comme correction complémentaire, pas comme remplacement : il convertit automatiquement chaque taille d'image enregistrée — y compris les plus petits candidats srcset générés par WordPress — en WebP et AVIF, afin que le choix correctement dimensionné du navigateur soit aussi servi dans le format le plus léger utilisable.
Pour en savoir plus sur le volet format, consultez notre guide de conversion des images WordPress en WebP et notre checklist PageSpeed Insights plus large, qui montre où les images responsives s'intègrent dans le tableau de performance global.
Pour aller plus loin
Pour la spécification technique complète de la façon dont les navigateurs évaluent srcset et sizes, le guide de web.dev sur les images responsives est la référence la plus fiable — il couvre la sélection basée sur la densité, l'art direction avec l'élément <picture>, et des cas limites que ce guide n'aborde pas.
Pour conclure
Les images responsives sur WordPress ne sont pas cassées par défaut — le mécanisme fonctionne automatiquement depuis 2015. Ce qui casse, c'est la valeur sizes sur des mises en page plus complexes qu'un blog en une colonne, indiquant silencieusement aux navigateurs de télécharger des fichiers deux à trois fois plus gros que ce qui est réellement affiché. Vérifiez l'attribut par rapport à votre mise en page réelle avant de supposer que vos images responsives fonctionnent déjà correctement, et associez la correction à la conversion de format pour un gain complet.