WebP alourdit tes images au lieu de les alléger : que faire
Le WebP n’allège pas systématiquement un JPEG : sur une source déjà bien compressée, une conversion en qualité perceptuelle équivalente peut produire un fichier plus lourd, pas plus léger. Le gain réel dépend du niveau de compression déjà présent dans le JPEG, du paramètre de qualité choisi à l’encodage, et surtout du dimensionnement de l’image, pas seulement du format.
Rien de grave ici : c’est un réflexe technique mal calibré, pas un bug. Le problème, c’est que beaucoup de sites convertissent tout leur catalogue d’images en WebP par automatisme, sans jamais vérifier le résultat sur un échantillon. Ils gagnent parfois zéro, perdent parfois du poids, et surtout ratent le vrai levier de performance : servir la bonne taille d’image au bon appareil.
Pourquoi le WebP ne gagne pas toujours
Plusieurs facteurs expliquent pourquoi la conversion peut décevoir, voire se retourner contre toi :
- La source JPEG est déjà finement compressée. Un JPEG passé par un bon export (Photoshop, sips, un outil dédié) a déjà éliminé une grande partie de la redondance que le WebP cible.
- Le paramètre de qualité choisi à l’encodage est trop haut. Une conversion en
-q 95avec cwebp cherche à préserver un maximum de détail, ce qui gonfle le poids au lieu de le réduire. - La comparaison se fait au même chiffre de qualité, pas à qualité perceptuelle équivalente. Un JPEG à 85 % et un WebP à 85 % n’ont pas le même rendu visuel ni le même poids : comparer les chiffres bruts ne veut rien dire.
- L’image n’est pas redimensionnée. Le format change, mais la résolution reste celle de la photo source, souvent bien plus grande que ce que l’écran affiche réellement.
- L’étude de référence sur WebP porte sur des JPEG non optimisés. Google précise que ses chiffres de gain (25 à 34 % à indice SSIM équivalent) proviennent d’une comparaison sur des JPEG collectés sur le web, pas sur des sources déjà travaillées source : WebP Compression Study, Google. Le SSIM (Structural Similarity) désigne un indice de mesure de similarité perceptuelle entre deux images, utilisé pour comparer la qualité visuelle réelle plutôt que le seul poids du fichier.
1. Mesurer sur un échantillon avant de convertir tout le site
Ne convertis jamais un dossier complet sans test préalable. Prends 5 à 10 images représentatives de ton site (une photo de produit, un portrait, une image avec beaucoup de texte ou de zones plates) et compare les poids réels.
Sur macOS, sips (Scriptable Image Processing System) permet d’inspecter et de convertir des images en ligne de commande sans installer d’outil tiers. Sur les autres environnements, cwebp est l’outil de référence pour encoder en WebP, avec un contrôle fin via -q (qualité), -lossless (sans perte) et -preset (profil prédéfini comme “photo” ou “icon”) source : documentation cwebp, Google.
2. Comparer à qualité perceptuelle égale, pas au même chiffre
Ne compare pas un JPEG 85 à un WebP 85 : les échelles de qualité des deux encodeurs ne sont pas alignées. Ouvre les deux fichiers côte à côte à taille réelle, cherche le point où les artefacts (flou, bandes de couleur, pixelisation autour du texte) deviennent visibles, et compare le poids à ce niveau de qualité visuelle équivalent.
Sur un projet hôtelier repris chez Peechy à l’été 2026, les JPEG sources pesaient déjà 6 323 Ko après un premier passage d’optimisation. Convertis en WebP à q95, ils grimpaient à 9 411 Ko, soit 49 % de poids en plus. Le JPEG était déjà trop bien compressé pour que le WebP fasse mieux à ce niveau de qualité.
3. Vérifier si la source JPEG est déjà bien compressée
Avant toute conversion, regarde d’où viennent tes images. Une photo exportée depuis un appareil photo brut ou une capture d’écran non compressée profitera souvent du WebP. Une image déjà passée par un plugin d’optimisation ou un export soigné a moins de marge, parfois aucune.
Ce constat rejoint ce que rappelle la comparaison des plugins d’optimisation d’images WordPress : la compression appliquée en amont conditionne tout ce qui vient après. Convertir une image déjà optimisée n’ajoute rien, ça peut retirer du gain.
4. Le vrai levier : redimensionner et servir en srcset
Sur le même projet hôtelier, redimensionner les images à 1024 px de large avant conversion ne faisait gagner que 6 % au WebP par rapport au JPEG équivalent. Le format changeait peu de chose une fois la taille corrigée : la vraie perte de poids venait du redimensionnement lui-même, pas du format.
La décision finale a été de garder le JPEG et de générer des variantes en q92 à 640 px et 1024 px avec sips, servies via srcset. Résultat : 46 % de poids en moins sur mobile, sans changer de format.
Un srcset est un attribut HTML qui liste plusieurs variantes d’une même image, chacune associée à sa largeur intrinsèque, pour laisser le navigateur choisir la plus adaptée à l’écran de visite. Combiné à l’attribut sizes, le navigateur évalue la taille d’écran, la densité de pixels et la vitesse réseau, détermine quelle règle de sizes s’applique, puis charge la variante du srcset la plus proche de ce besoin source : Responsive images, MDN. Servir une image taille desktop à un mobile peut utiliser 2 à 4 fois plus de données que nécessaire source : web.dev, 2018.
5. Automatiser la génération des variantes
Une fois la bonne taille identifiée, automatise. Un script sips ou un pipeline de build peut générer les variantes 640 px, 1024 px et 1920 px à chaque ajout d’image, dans un dossier dédié, avec une convention de nom claire (photo-640.jpg, photo-1024.jpg). Ce chantier rejoint directement ce qu’on couvre dans le lazy loading des images WordPress : dimension correcte et chargement différé se complètent, l’un sans l’autre laisse du poids sur la table.
6. Garder l’AVIF et le WebP pour les cas où ils gagnent vraiment
WebP reste pertinent sur des PNG lourds, des captures d’écran, des images avec de grandes zones plates ou des sources JPEG non optimisées. La règle reste la même : mesure avant de généraliser. Un format plus récent ne bat pas systématiquement l’ancien sur toutes les images, seulement sur celles où la compression source laissait de la marge.
| Situation | Ce qui se passe | Solution |
|---|---|---|
| JPEG source déjà optimisé (export soigné, plugin de compression) | WebP à qualité équivalente peut peser autant ou plus | Garder le JPEG, mesurer avant conversion |
| JPEG non optimisé ou capture d’écran | WebP gagne réellement en poids | Convertir en WebP avec cwebp, qualité 80-85 |
| Image affichée en grande résolution mais redimensionnée en CSS | Le poids réel ne baisse presque pas avec le format seul | Générer des variantes et servir en srcset |
| Comparaison au même chiffre de qualité entre JPEG et WebP | Résultat trompeur, pas comparable | Comparer à qualité perceptuelle équivalente (SSIM ou test visuel) |
| PNG avec grandes zones plates ou texte | WebP réduit fortement le poids | Convertir systématiquement, le gain est net |
FAQ
Le WebP est-il toujours plus léger que le JPEG ?
Non. Sur des JPEG déjà bien compressés, un WebP à qualité perceptuelle équivalente peut peser autant, voire plus. L’écart dépend de la source, pas seulement du format cible.
Faut-il abandonner WebP sur son site ?
Non. WebP reste efficace sur des PNG, des captures d’écran et des JPEG non optimisés. Il faut simplement mesurer sur un échantillon avant de convertir tout un catalogue d’images.
Quelle qualité cwebp choisir pour ne pas perdre en netteté ?
Commence autour de -q 80 à -q 85 et compare visuellement à taille réelle. Au-delà de -q 90, le gain de netteté devient marginal et le poids remonte vite.
L'AVIF remplace-t-il le WebP et le JPEG ?
AVIF compresse souvent mieux que WebP à qualité équivalente, mais le principe reste identique : mesure sur un échantillon avant de généraliser, et redimensionne d’abord les images avant de changer de format.
Comment savoir si mes JPEG sont déjà bien compressés ?
Regarde leur origine : un export soigné ou un passage par un outil d’optimisation laisse peu de marge. Une photo brute d’appareil photo ou une capture d’écran, à l’inverse, profite presque toujours d’une recompression.
Quand passer la main à un pro
Mesurer un échantillon d’images prend une heure. Automatiser la génération de variantes, brancher un srcset cohérent sur tout un site, et vérifier l’impact réel sur le LCP et les Core Web Vitals demande plus de temps et une méthode répétable. Si ton catalogue d’images dépasse quelques dizaines de fichiers ou que le site tourne sur plusieurs types de gabarits, un audit ponctuel évite de refaire ce travail à moitié, puis de le refaire une deuxième fois six mois plus tard.
Ce problème, Peechy s'en occupe
Plutôt que de tout gérer seul, confiez votre site à une agence qui s'occupe de tout, hébergement, sécurité, maintenance et corrections. Encore plus simple en abonnement : on règle les soucis avant même que vous les remarquiez.
Confier mon site à Peechy