On a vu un site éditorial sous WordPress perdre 40 % de son trafic organique en deux semaines. Le motif n’était pas une pénalité manuelle, ni un problème de contenu. C’était un LCP qui avait grimpé de 2,1 s à 4,8 s après le passage à un thème « performant » qui régénérait des miniatures sans aucune discrimination. En nettoyant les tailles inutilisées et en imposant une stratégie de redimensionnement côté serveur, on est redescendus à 2,3 s. Voici ce qu’on a appris et pourquoi la gestion des miniatures n’est pas un détail cosmétique, mais un levier de performance web de premier plan.
WordPress génère trop de miniatures par défaut, et ça coince
Quand vous uploadez une image dans WordPress, le cœur et le thème actif enregistrent des tailles supplémentaires. Une installation classique avec un thème du commerce et trois plugins actifs peut créer entre 8 et 15 miniatures : thumbnail, medium, large, medium_large, 1536x1536, 2048x2048, plus les tailles déclarées par le thème pour les sliders, les grilles de portfolio, les vignettes de blog. Chaque miniature est un fichier physique stocké sur le serveur, généré en une seule fois au moment de l’upload via la librairie GD ou Imagick.
Le problème n’est pas seulement le stockage. C’est que 80 % de ces images ne seront jamais servies dans le front-end. Sur un site à forte production éditoriale, des milliers de fichiers s’accumulent dans wp-content/uploads, ralentissant les sauvegardes, la restauration et parfois même la pagination des médias dans l’admin. Pire, le redimensionnement lors de l’upload pompe du CPU et peut allonger le temps de traitement si le fichier source est un PNG de 20 Mo envoyé par un rédacteur depuis Lightroom.
La pratique saine consiste à auditer les tailles enregistrées avec la fonction get_intermediate_image_sizes() et à désactiver celles que le thème actif n’utilise pas. On peut le faire en filtrant intermediate_image_sizes dans un mu-plugin. On évite ainsi de fabriquer du gras numérique qui ne servira jamais le visiteur.
Le vrai coût d’une miniature mal dimensionnée sur le LCP
Le Largest Contentful Paint se mesure sur l’élément le plus grand visible dans le viewport. Dans une majorité de pages WordPress, cet élément est une image : une photo d’article, une bannière, une image de produit. Si la miniature chargée pour cet emplacement est plus large que nécessaire, vous envoyez des pixels inutiles sur le réseau.
Prenons un cas réel. Un site d’actualité local affiche en une des vignettes d’articles dans une grille où chaque image occupe 380 px de large en desktop. Le thème demandait la taille medium_large (768 px de large par défaut) alors que rien dans le CSS ne dépassait 400 px. Résultat : chaque miniature pesait 110 ko au lieu de 45 ko si elle avait été générée à la bonne dimension. Sur une page listant 12 articles, le poids total des images passait de 1,3 Mo à 540 ko simplement en créant une taille sur mesure de 400 px et en l’attribuant à ce contexte via wp_get_attachment_image_src.
Le diagnostic se fait en ouvrant la Network Tab des DevTools, en filtrant par img et en vérifiant le naturalWidth des images affichées dans la console. Si le naturalWidth dépasse de plus de 20 % la largeur réelle d’affichage, vous avez un gisement de millisecondes à exploiter.
Redimensionner côté serveur ou laisser le navigateur choisir dans srcset ?
Beaucoup de thèmes s’en remettent entièrement à l’attribut srcset que WordPress génère automatiquement. L’idée est séduisante : on produit plusieurs tailles, le navigateur pioche la bonne selon la densité de pixels et la largeur du viewport. En pratique, ça dérape souvent.
Si l’attribut sizes n’est pas déclaré avec précision, le navigateur part du principe que l’image occupe 100 % de la largeur du viewport. Sur un écran large, il choisit alors une miniature bien plus lourde que nécessaire pour un simple emplacement de 400 px dans une sidebar. On se retrouve avec des images de 1200 px de large chargées dans des contextes où 600 px suffiraient.
Nous, on préconise une approche hybride. On garde le srcset pour la couverture des hautes densités, mais on durcit le sizes avec des valeurs explicites qui correspondent aux breakpoints réels du thème. Et pour l’image qui déclenche le LCP, on force manuellement la taille choisie dans le template plutôt que de laisser le navigateur négocier avec une dizaine de candidats. C’est un basculement comparable à ce qu’on fait quand on choisit entre un state management global et un état local dans une app React : parfois, la simplicité de Zustand pour un store partagé l’emporte sur une machinerie plus complexe ; ici, une taille explicite l’emporte sur un srcset non maîtrisé.
Un script de nettoyage qui nous a fait gagner 2 Go et 200 ms de TTFB
Sur un site avec 15 000 articles et 8 ans d’uploads, on a exécuté un audit des tailles réellement utilisées. On a croisé les appels dans les templates avec les métadonnées des médias. Verdict : 60 % des fichiers présents sur le disque n’avaient jamais été servis depuis au moins 12 mois. On a écrit un script en WP-CLI qui supprime toutes les miniatures non référencées par la librairie active, puis régénère uniquement les quatre tailles nécessaires au thème.
wp media regenerate --only-missing --yes --image_size=thumbnail,medium,large,hero-blogCe script a libéré 2 Go d’inodes, réduit le temps de backup incrémental de 40 %, et surtout retiré 200 ms de TTFB sur les pages d’archives. Pourquoi ? Parce que les pages qui chargeaient des galeries dynamiques parcouraient soudainement moins de fichiers et que le filesystem du serveur respirait. On ne pense jamais au temps d’accès disque quand on parle de LCP, mais sur un serveur mutualisé ou un VPS non optimisé, le nombre de fichiers dans un dossier d’uploads peut dégrader les performances de façon insidieuse.
Formats modernes : le piège de la conversion automatique sans fallback
Convertir toutes les miniatures en WebP ou AVIF à l’aide d’un plugin de cache, c’est tentant. La promesse d’un gain de 30 à 40 % de poids est réelle. Le piège, c’est l’absence de fallback pour les navigateurs anciens et certains robots sociaux qui ne comprennent pas ces formats. Un mauvais réglage peut casser l’affichage des images sur Twitter Cards, LinkedIn ou tout environnement qui ne négocie pas le Accept: image/webp.
La bonne méthode consiste à utiliser le tag <picture> avec une source en WebP et un fallback en JPEG, ou à configurer le serveur pour servir une version alternative basée sur l’en-tête Accept. On peut le faire avec une règle de réécriture Nginx ou via un CDN qui négocie le format à la volée. Si vous voulez creuser l’impact de ce type de décision sur le score Core Web Vitals, on en parle dans notre section optimisation core web vitals. L’essentiel est de ne jamais activer le remplacement global sans vérifier ce que voit un crawler social.
Le lien entre miniatures et CLS : quand une image sans dimensions explicites décale tout
Le Cumulative Layout Shift est souvent causé par des images dont le navigateur ne connaît pas les dimensions avant de les avoir chargées. WordPress, depuis la version 5.5, ajoute automatiquement les attributs width et height sur les balises <img>. C’est un progrès. Mais si le CSS du thème écrase ces dimensions avec height: auto et que l’image n’est pas dans un conteneur ratio, le layout peut encore sauter lorsque le navigateur découvre le ratio réel.
Sur un site e-commerce, on a mesuré un CLS de 0,18 sur des fiches produits parce que les miniatures de galerie n’avaient pas de aspect-ratio explicite dans le CSS. Le navigateur réservait un espace nul, puis chargeait l’image, poussant la description produit vers le bas. La correction a tenu en une ligne de CSS : img { aspect-ratio: attr(width) / attr(height); } combinée à un lazy-loading natif avec loading="lazy" pour les images hors viewport.
Là encore, la solution n’est pas un plugin miracle. C’est la compréhension du mécanisme de rendu. Les miniatures générées par WordPress sont une matière première ; c’est le thème qui décide comment elles se comportent dans le flux.
Pourquoi on a déporté le redimensionnement vers le CDN
À force de traquer les TTFB anormalement longs les jours de pic éditorial, on a fini par isoler un coupable : la génération PHP des miniatures lors des imports massifs. Chaque fichier traité consommait de la RAM et bloquait un worker PHP-FPM. On a déplacé le redimensionnement et la compression dans le pipeline du CDN, avec un proxy d’image qui redimensionne à la volée en fonction de paramètres d’URL.
Cette approche retire la charge du serveur d’origine et permet de servir exactement la dimension demandée par le client, sans jamais générer de fichier intermédiaire sur le disque. Elle demande une configuration précise des règles de cache pour éviter de transformer le CDN en goulot. Mais une fois en place, elle élimine définitivement le problème des tailles inutilisées. Le serveur WordPress ne stocke que l’original haute résolution et le CDN en dérive toutes les variantes.
C’est un changement de paradigme qui fait écho à ce qu’on observe dans les environnements de développement modernes : le débat Claude Code vs Cursor IDE par exemple ne se résout pas en choisissant un outil meilleur que l’autre, mais en redéfinissant où la transformation doit avoir lieu. Ici, le traitement passe du serveur applicatif à la edge. Et le LCP descend mécaniquement.
Questions fréquentes
Faut-il supprimer toutes les tailles d’image et ne conserver que l’originale ?
Non. Conserver uniquement l’originale oblige le navigateur à charger une image lourde même dans un petit emplacement, sauf à déporter le redimensionnement sur un CDN ou un proxy externe. Mieux vaut conserver trois tailles contrôlées, par exemple thumbnail pour les listes, medium pour les entêtes d’article et large pour les bannières pleine largeur.
Les plugins comme Imagify ou ShortPixel suffisent-ils à régler le problème ?
Ils réduisent le poids des fichiers existants, mais ne corrigent pas une mauvaise stratégie de taille. Si votre thème continue d’appeler une miniature trop large en src, la compression seule ne rattrapera pas les pixels superflus. Utilisez-les en complément d’un audit des tailles, pas en remplacement.
Comment auditer les miniatures servies sur un site avec des milliers d’articles ?
Extrayez un échantillon représentatif de 50 URLs couvrant tous les types de pages (article, archive, page d’accueil). Pour chaque page, relevez dans la Network Tab le naturalWidth des images et comparez avec la largeur d’affichage. Identifiez les tailles de la librairie WordPress qui sont systématiquement trop larges et proposez des dimensions sur mesure.
