Pourquoi PageSpeed Insights affiche encore « Dimensionnez correctement les images » alors que j'ai un srcset ?

Vous avez fait ce qu'on vous a dit de faire. Vos images ont un srcset bien rempli, plusieurs largeurs générées, du WebP (un format d'image nouvelle génération, plus léger que le JPEG ou le PNG). Et pourtant l'audit PageSpeed Insights affiche toujours Dimensionnez correctement les images, avec plusieurs centaines de Ko d'économies indiquées.

Ce n'est pas un bug de PageSpeed. C'est une méprise très répandue sur le fonctionnement réel des images responsives. Voyons cela une bonne fois pour toutes.

Ce que srcset fait, et ce qu'il ne fait pas

Prenons un cas typique :

<img
  src="photo-1200.jpg"
  srcset="photo-400.jpg 400w,
          photo-800.jpg 800w,
          photo-1200.jpg 1200w,
          photo-2000.jpg 2000w">

Beaucoup pensent que le navigateur va « choisir la plus adaptée ». En réalité, srcset à lui seul n'est qu'un menu. Il dit : voici les tailles disponibles et leur largeur réelle en pixels. Il ne dit rien sur l'espace que l'image occupe dans votre page.

Sans information sur la largeur d'affichage, le navigateur applique une valeur par défaut : sizes="100vw" (vw = largeur du viewport, la largeur de la fenêtre), ce qui signifie « suppose que l'image occupe toute la largeur de la fenêtre ». Et c'est là que tout dérape.

La vraie cause : l'attribut sizes (et le piège de la densité d'écran)

Le calcul que fait le navigateur est simple :

Prenons deux scénarios sur un mobile de 400px de large avec un écran Retina (DPR = 2, la norme sur mobile) :

La conclusion qui fait mal : un srcset sans un sizes correct est presque inutile. Le navigateur, dans le doute, prend trop grand, et PageSpeed le voit.

Le DPR est le facteur que tout le monde oublie : sur mobile, la plupart des écrans sont en DPR 2 ou 3. Une image affichée à 200px physiques a besoin d'une source de 400 à 600px. Ce n'est pas du gaspillage ; au-delà, ça l'est.

Le cas WordPress : le sizes par défaut est souvent faux (la cause n°1 en pratique)

Si vous êtes sous WordPress, il y a de fortes chances que votre problème vienne de là, et ce n'est pas un sizes absent, mais un sizes automatique et erroné.

WordPress génère tout seul le srcset et un sizes. Mais la valeur qu'il met par défaut ressemble à :

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

Autrement dit : « cette image occupe toute la largeur du contenu ». C'est vrai pour une image d'article en pleine largeur. C'est faux dès que l'image se trouve dans une grille, une colonne, une barre latérale, une carte, une galerie, ce qui est le cas la plupart du temps. Résultat : sizes annonce une largeur bien plus grande que la réalité, le navigateur charge trop lourd, et PageSpeed le voit.

Pire : beaucoup de page builders (Divi, Elementor…) et de thèmes n'ajustent pas ce sizes à la colonne réelle. Vous avez donc un srcset impeccable, des variantes bien générées… et un sizes qui les sabote. C'est la cause la plus fréquente du reproche « Dimensionnez correctement les images » sur un site WordPress, celle qu'on ne pense jamais à vérifier précisément parce que « WordPress s'en occupe ».

Diagnostiquer en 30 secondes (sans deviner)

Ouvrez les DevTools de Chrome, l'onglet Elements, survolez la balise <img>. Chrome affiche :

• Rendered size : la taille à laquelle l'image est réellement affichée.
• Rendered aspect ratio et Intrinsic size : la taille du fichier téléchargé.
• Current source : quelle variante du srcset a été choisie.

Le verdict est immédiat. Si vous voyez une taille rendue de 180px mais que le current source est photo-800.jpg, votre sizes est absent ou faux. Si la taille rendue est 180px et que le current source est photo-400.jpg, c'est correct : 400 = 180 × DPR 2, arrondi au palier supérieur.

Vous pouvez aussi utiliser l'onglet Network : triez par taille, rechargez, et observez quelle variante transite sur le réseau.

Le correctif générique (ce que fait un développeur à la main)

a. Écrivez un sizes qui correspond à votre mise en page réelle

C'est le cœur du problème. sizes doit refléter la largeur réelle de l'image, celle imposée par votre CSS, à chaque breakpoint (la largeur d'écran à laquelle la mise en page change). Exemple pour une image en pleine largeur sur mobile mais sur 3 colonnes sur desktop :

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

b. Générez les bonnes variantes

Inutile d'avoir une variante 2000w si votre image ne dépasse jamais 600px à l'écran. Et inversement : prévoyez les paliers qui couvrent vos largeurs réelles × DPR (jusqu'à 2, parfois 3).

c. N'oubliez pas width et height

. Ils ne changent pas le poids, mais ils évitent le CLS (Cumulative Layout Shift, contenu qui saute pendant le chargement), l'autre reproche récurrent de PageSpeed.

Le cas où même un sizes parfait ne suffit pas

Certains éléments n'ont aucun srcset du tout : les sliders (Nivo, Swiper, beaucoup de thèmes), les images de fond CSS, ou tout balisage qui produit une balise <img src="..."> brute. Là, il n'y a littéralement rien à réécrire : aucun plugin d'optimisation ne peut agir, car il n'y a pas de srcset/sizes à corriger. C'est un problème à part (images sans srcset), qui appelle une approche différente de celle décrite ici.

Pourquoi c'est si pénible à maintenir à la main

Écrire le bon sizes suppose de connaître, pour chaque image et chaque breakpoint, la largeur d'affichage CSS réelle. Sur un site vitrine de 5 pages, c'est faisable. Sur un site avec des dizaines de gabarits, des grilles qui changent, du contenu éditorial… c'est ingérable, et ça se désynchronise à chaque refonte.

En résumé

• srcset = un menu de tailles. sizes = l'instruction de choix. Sans la seconde, le premier est presque inutile.
• Le DPR mobile (×2, ×3) double ou triple la largeur cible, d'où le sur-téléchargement.
• Diagnostiquez avec Rendered size vs Current source dans les DevTools.
• Le correctif = un sizes fidèle à votre mise en page réelle + les bonnes variantes. À la main c'est fastidieux et fragile ; mesuré et automatisé, c'est fiable.