Une photo produit exportée à 4000 pixels de large et déposée telle quelle dans la médiathèque WooCommerce est servie à cette même taille à chaque visiteur, qu'il la voie en vignette de 300 pixels sur une page catégorie ou en plein écran sur une fiche produit. Le navigateur télécharge le fichier entier, le décode, puis le redimensionne dans la mise en page : de la bande passante dépensée pour rien. Multipliez ça par chaque image de chaque page vue, et l'écart entre « les images telles qu'uploadées » et « les images réellement nécessaires » devient une ligne de coût récurrente, pas une inefficacité ponctuelle.
Ce coût se loge à deux endroits. Le premier est direct : bande passante d'hébergement ou de CDN facturée au gigaoctet, stockage qui grossit avec le catalogue, CPU serveur dépensé à re-servir le même fichier surdimensionné des milliers de fois. Le second est indirect et généralement plus lourd : le temps de chargement. Le Largest Contentful Paint d'une fiche produit est très souvent l'image produit principale elle-même, et un LCP lent est corrélé de façon mesurable à un taux de conversion plus bas et à des signaux de classement moins bons dans les Core Web Vitals de Google. Quelques centaines de millisecondes de trop par page, multipliées sur tout un catalogue et une saison de trafic, ne sont pas une erreur d'arrondi pour une boutique qui dépend d'un trafic organique et payant qui doit convertir.
La solution n'est pas de réexporter chaque fichier à la main dans la bonne taille et le bon format pour chaque emplacement : ça ne tient pas au-delà de quelques dizaines de produits, et il faut tout recommencer dès qu'un nouveau format ou une nouvelle taille d'écran se répand. Les deux mécanismes qui règlent vraiment le problème sont structurels plutôt que ponctuels : calculer chaque variante nécessaire (un fichier donné, à une taille donnée, dans un mode de redimensionnement donné, dans un format donné) une seule fois puis la servir ensuite depuis un cache disque permanent, et choisir automatiquement le meilleur format selon ce que le navigateur du visiteur annonce réellement supporter via son en-tête Accept, plutôt que de deviner ou d'envoyer le même JPEG à tout le monde.
C'est exactement ce que fait ImagePipe à l'intérieur d'un site WordPress/WooCommerce : les presets définissent les tailles dont un catalogue a réellement besoin, chaque variante est générée une fois puis mise en cache, et la négociation de format sert de l'AVIF ou du WebP aux navigateurs qui le supportent, sans toucher aux fichiers originaux. Ça n'élimine pas le coût de servir des images, rien ne le fait, mais ça supprime le coût de servir la même image de la même façon, encore et encore, à des navigateurs qui auraient pu recevoir plus léger.