Miniatures WordPress : supprimez les tailles d'images inutiles

Envoyez une seule photo de produit dans votre médiathèque et regardez votre dossier uploads par FTP : WordPress en a créé 6, 8, parfois 10 copies. Sur une boutique WooCommerce avec 2 000 produits, ce mécanisme multiplie silencieusement vos fichiers, alourdit vos sauvegardes et rallonge chaque migration. Le plus agaçant : une bonne partie de ces copies ne sont jamais affichées nulle part.

J’ai fait l’exercice récemment sur la boutique d’un client, un grossiste avec un gros catalogue. Voici la méthode complète : identifier ce qui sert vraiment, supprimer le reste, régénérer proprement.

D’où viennent toutes ces copies ?

Trois sources s’additionnent :

Le cœur de WordPress génère par défaut thumbnail (150×150), medium (300×300), medium_large (768), large (1024), et depuis WordPress 5.3, deux tailles supplémentaires en 1536 et 2048 pixels pour les écrans haute densité.

WooCommerce et le thème ajoutent les leurs : la vignette de galerie (100×100), l’image de fiche produit (600×600 par défaut), la taille de la grille produits, et parfois des formats hérités d’anciens thèmes qui ne sont plus utilisés depuis des années.

Les plugins enfin : un plugin SEO peut déclarer des formats pour les images de partage social (1200×675, 1200×900), un slider ses propres dimensions, et ainsi de suite.

Chaque taille déclarée = un fichier créé pour chaque image envoyée, pour toujours, que la taille soit affichée quelque part ou non.

Le cas -scaled : des doublons dont personne ne parle

Depuis WordPress 5.3, toute image de plus de 2 560 pixels est dupliquée en version -scaled, qui devient l’image « pleine taille » servie au front. Deux conséquences peu connues : les miniatures sont parfois générées à partir de l’original ET de la version scaled, d’où des doublons sur le disque, et surtout, à la suppression d’un média, les fichiers -scaled ne sont pas toujours nettoyés. Résultat : des orphelins qui s’accumulent, invisibles depuis la médiathèque.

Le seuil de 2 560 pixels est modifiable, et sur une boutique où aucune image ne s’affiche au-delà de 1 200 pixels, le descendre est du simple bon sens :

// Abaisser le seuil de creation des versions -scaled (2560px par defaut)
add_filter( 'big_image_size_threshold', function () { return 1200; } );

Étape 1 : identifier les tailles réellement servies

Ne supprimez rien avant d’avoir mesuré. La méthode que j’utilise : scanner une dizaine de pages représentatives (accueil, catégories, tags, fiches produit) et relever les dimensions demandées dans les attributs src et srcset des balises images. Les DevTools suffisent : onglet Réseau, filtre Images, colonne des dimensions affichées.

Sur la boutique de mon client, le verdict du scan était sans appel : sur toutes les tailles générées, seules 5 servaient réellement (la vignette d’admin en 150, le fallback de contenu en 300, la grille produits en 462, la fiche produit en 600 et la vignette de galerie en 100). Les 768, 1024, 1536, 2048 et deux formats hérités en 64×64 et 266×266 : jamais servis, sur aucune page. Des dizaines de milliers de fichiers pour rien.

Pour lister ce que votre installation déclare, une commande WP-CLI :

wp eval 'print_r( wp_get_registered_image_subsizes() );'

Étape 2 : supprimer les tailles inutiles

Une fois la liste des tailles mortes établie, un filtre suffit pour que WordPress cesse de les générer :

// Ne plus generer les tailles jamais servies
add_filter( 'intermediate_image_sizes_advanced', function ( $sizes ) {
	unset( $sizes['medium_large'] ); // 768, jamais servie
	unset( $sizes['large'] );        // 1024, jamais servie
	unset( $sizes['1536x1536'] );
	unset( $sizes['2048x2048'] );
	return $sizes;
} );

Adaptez la liste à VOTRE scan, pas au mien : si votre thème affiche du 1024 dans ses bannières, large doit rester. C’est tout l’intérêt de l’étape 1.

Étape 3 : régénérer et nettoyer l’existant

Le filtre n’agit que sur les futurs envois. Pour l’existant, on régénère, ce qui supprime les anciennes tailles et ne recrée que celles encore déclarées. Sauvegarde d’abord, toujours :

# Sauvegarde du dossier uploads
tar -czf uploads-backup-$(date +%Y%m%d).tar.gz wp-content/uploads/

# Regeneration : supprime les anciennes tailles, recree les declarees
wp media regenerate --yes

Sur un gros catalogue, lancez la régénération en heures creuses : elle est gourmande en CPU. Et si vous n’avez pas accès à WP-CLI, le plugin Regenerate Thumbnails fait le même travail, en plus lent.

Ce que ça rapporte, honnêtement

Soyons précis sur les gains, parce qu’ils ne sont pas où on les attend. Côté vitesse d’affichage, l’impact direct est modeste : le navigateur ne télécharge que la taille listée dans le srcset, les fichiers inutilisés dorment sur le disque sans ralentir vos pages. Le vrai gain est ailleurs : un dossier uploads deux à trois fois plus léger, des sauvegardes plus rapides et moins chères, des migrations qui ne durent plus des heures, et un serveur qui ne génère plus 10 fichiers à chaque envoi d’image.

L’exception qui change tout : si votre scan révèle qu’une page sert une taille inadaptée (une grille produits qui affiche du 600×600 dans des cases de 300 pixels, c’est un classique), là vous touchez directement au poids des pages et au LCP. Ce diagnostic fait partie de ma méthode d’audit, et les corrections d’images s’inscrivent dans le chantier global d’optimisation WooCommerce.

Mon conseil

Faites ce ménage à l’occasion d’un changement de thème : c’est le moment où les tailles utiles changent, où l’on ajuste la grille produits, et où une régénération complète est de toute façon nécessaire. C’est exactement ce qu’on a planifié chez mon grossiste, en même temps que sa refonte en thème FSE. Deux chantiers, une seule régénération.

Envie de savoir combien de tailles mortes traînent dans votre uploads, et ce qui ralentit vraiment votre boutique ? Demandez un audit gratuit : diagnostic sous 48h.