WordPress garde plusieurs copies de chaque image, et n'en optimise aucune

Envoyez une photo dans WordPress et vous n’obtenez pas un fichier. Vous obtenez une miniature, une taille moyenne, une moyenne-grande, une grande, la taille complète, et toutes les tailles supplémentaires que votre thème et votre page builder ont enregistrées. Six ou huit fichiers pour un seul envoi, c’est normal. Chacun est ré-encodé à la qualité JPEG par défaut de WordPress, puis plus jamais retouché.

Multipliez ça sur quelques années de publications et le dossier uploads est généralement l’élément le plus lourd de votre sauvegarde, et la partie la plus lente de vos pages. L’essentiel de ce poids est évitable.

Où se trouve vraiment le poids

Ce sont les JPEG. Les photos dominent une médiathèque type, et WordPress les encode à une qualité fixe (82 par défaut) avec un vieil encodeur. C’est un choix par défaut prudent et raisonnable, pas un petit fichier. Les captures d’écran et les logos stockés en PNG en rajoutent, car le PNG est le mauvais conteneur pour beaucoup d’entre eux.

Il y a deux façons honnêtes de réduire ça, avec des compromis différents.

1. Ré-encoder sur place

Prenez chaque taille générée et ré-encodez-la vers une version plus légère du même format : le JPEG reste du JPEG, le WebP reste du WebP. Un encodeur moderne retire environ un cinquième à un quart d’un JPEG WordPress par défaut, sans changement visible.

L’intérêt, c’est que rien d’autre sur votre site ne s’en aperçoit. Le nom de fichier, les dimensions et l’extension sont identiques, donc chaque URL continue de fonctionner, dans chaque thème, dans chaque page en cache, dans chaque <img> écrit en dur. C’est l’option ennuyeuse et sûre, et pour beaucoup de sites c’est la bonne.

Ce qu’elle ne fera pas : changer de format. Un JPEG reste un JPEG, vous n’avez donc pas les gains plus importants qu’un format plus récent vous donnerait.

2. Servir des formats nouvelle génération

Générez un AVIF (et un WebP) à côté de chaque original et servez-le via une balise <picture>, en gardant le JPEG ou le PNG d’origine comme repli pour les vieux navigateurs. C’est là que sont les vraies économies : à qualité équivalente, l’AVIF demande bien moins d’octets que le JPEG, et il couvre enfin vos PNG aussi. Nous avons mesuré l’écart sur environ 1 900 photos si vous voulez les chiffres.

Les réserves honnêtes, parce qu’il y en a :

• Elle réécrit le HTML de la page, ce qui la rend indépendante du thème, mais elle ne touche que les balises <img>. Un background-image en CSS ne sera pas remplacé.
• Un lazy-loader JavaScript qui réécrit src à l’exécution peut passer à côté. Le loading="lazy" natif ne pose pas de problème.
• Le GIF n’est pas encore couvert.

Les originaux restent exactement où ils sont, rien n’est donc perdu, et les navigateurs qui ne savent pas lire l’AVIF retombent sur le fichier qu’ils comprenaient déjà.

Ce qui inquiète vraiment les gens

Les deux approches gardent une sauvegarde de chaque original, donc n’importe quelle image se restaure à l’octet près en un clic. Un fichier n’est remplacé que lorsque le nouveau est strictement plus petit, rien ne grossit donc. Et si une optimisation échoue, elle est ignorée, pas fatale : votre envoi ne se bloque jamais et une image n’est jamais laissée à moitié écrite.

Le faire

C’est ce que fait Patu Optimizer. Les nouveaux envois s’optimisent automatiquement, une seule passe groupée traite tout ce qui est déjà dans la médiathèque, et vous choisissez sur place ou nouvelle génération par site. Il tourne sur l’API Patu, l’encodage se fait donc en dehors de votre serveur. Une clé gratuite suffit pour commencer.

Commencez par le sur-place si vous voulez zéro surprise. Passez à la nouvelle génération quand vous visez les octets et que vos pages utilisent des balises <img> normales. Dans les deux cas, le but est le même : arrêter de livrer une médiathèque deux ou trois fois plus lourde que nécessaire.