🗜️ Compression

Compression WebP vs JPEG : analyse chiffrée

⏱ 9 min de lecture 📅 Mis à jour mars 2026

Les chiffres clés : ce que disent les benchmarks

Le chiffre le plus souvent cité est celui des benchmarks publiés par Google lors de l'introduction du format WebP en 2010, puis confirmés par des études indépendantes depuis : à qualité visuelle équivalente, WebP produit des fichiers 25 à 35 % plus petits que JPEG. Ce gain s'applique aux images avec pertes (lossy).

En mode lossless (sans pertes), WebP surpasse PNG de 25 à 34 % selon le type d'image; mais cette comparaison sort du périmètre JPEG, qui est un format exclusivement lossy.

Ces chiffres sont des moyennes. Les résultats varient selon le type de contenu, le niveau de qualité cible et l'encodeur utilisé. Voici ce qu'on observe sur des cas concrets :

Type d'image	JPEG (qualité 85)	WebP (équivalent visuel)	Gain WebP
Photo de paysage, 1920×1080 px	320 Ko	215 Ko	−33 %
Portrait en studio, 800×1000 px	145 Ko	98 Ko	−32 %
Capture d'écran UI, 1440×900 px	280 Ko	175 Ko	−37 %
Illustration e-commerce, 600×600 px	95 Ko	72 Ko	−24 %
Image avec texte superposé, 1200×630 px	210 Ko	148 Ko	−30 %

Méthodologie : Ces mesures comparent JPEG à qualité 85 (MozJPEG) avec WebP à un niveau de qualité ajusté pour obtenir un SSIM (Structural Similarity Index) équivalent sur les deux fichiers. Ce n'est pas une comparaison à paramètre fixe, mais à qualité visuelle perçue équivalente, ce qui est la seule comparaison utile en pratique.

Comment fonctionne WebP : prédiction et entropie

Comprendre l'avantage de WebP nécessite de comprendre pourquoi il est structurellement plus efficace que JPEG.

JPEG découpe l'image en blocs de 8×8 pixels, applique une transformée en cosinus discrète (DCT) pour convertir les données spatiales en données fréquentielles, puis quantifie les coefficients. C'est une approche solide, mais le découpage en blocs crée des artefacts visibles à haute compression (artefacts de macroblocs) et ne tire pas parti des corrélations entre blocs adjacents.

WebP lossy est dérivé du codec vidéo VP8. Il utilise deux techniques supplémentaires que JPEG n'implémente pas :

Codage prédictif (intra-prediction) : Chaque macro-bloc de 16×16 pixels est encodé en prédisant sa valeur à partir des blocs voisins déjà encodés, et en ne stockant que le résidu (différence entre prédiction et valeur réelle). Sur les zones uniformes, ciel, peaux, fonds, les résidus sont proches de zéro et s'encodent en très peu de bits.
Codage entropique arithmétique : WebP utilise un codage arithmétique booléen, plus efficace que le codage de Huffman utilisé par JPEG pour compresser les coefficients quantifiés. Ce seul changement représente un gain de 5 à 10 %.

La combinaison de ces deux mécanismes explique l'essentiel de l'avantage de WebP sur JPEG.

Mesurer la qualité visuelle : SSIM et DSSIM

Comparer des images compressées à paramètre fixe (ex. "JPEG 80 vs WebP 80") n'a pas de sens : les échelles de qualité des deux formats ne sont pas linéairement comparables. La bonne approche est de mesurer la qualité visuelle objectivement.

Le SSIM (Structural Similarity Index) est la métrique la plus courante. Il mesure la similarité structurelle entre deux images sur une échelle de 0 à 1 (1 = identiques). Une valeur SSIM ≥ 0,95 est généralement considérée comme visuellement indiscernable de l'original pour des images photo.

Le DSSIM est la distance SSIM (1 − SSIM), utile pour comparer des encodeurs : un DSSIM plus bas signifie une meilleure fidélité à qualité de compression égale.

Des outils comme Butteraugli (développé par Google) vont plus loin en modélisant la perception humaine du système visuel : deux images peuvent avoir un SSIM identique mais des scores Butteraugli différents si les artefacts sont distribués dans des zones que l'œil humain est plus ou moins sensible à.

Pour les développeurs : L'outil cjpeg-static de Mozilla et cwebp de Google permettent d'encoder des fichiers JPEG et WebP avec un niveau de qualité cible en termes de SSIM plutôt qu'un paramètre numérique arbitraire. C'est la meilleure façon de faire une comparaison équitable entre les deux formats.

Quand JPEG reste le meilleur choix

Malgré son avantage technique, WebP n'est pas toujours le format optimal. Il existe des situations où JPEG reste préférable :

Compatibilité universelle : JPEG est supporté par 100 % des navigateurs, clients email, applications, logiciels de retouche et appareils photo. WebP atteint 97 % de support navigateur en 2026, mais reste absent de nombreux outils de traitement d'image professionnels et de clients email (Outlook bureau notamment).
Métadonnées Exif complètes : Les fichiers JPEG peuvent stocker des métadonnées Exif étendues, données GPS, paramètres d'appareil photo, profils ICC, informations IPTC. WebP supporte les métadonnées Exif et XMP, mais l'écosystème de lecture de ces métadonnées est moins mature.
Compatibilité avec les outils de traitement : Photoshop, Lightroom, les CMS legacy et de nombreux pipelines d'automatisation traitent le JPEG nativement sans configuration supplémentaire. WebP nécessite des plugins ou des bibliothèques dédiées sur certains outils anciens.
Encodage rapide : L'encodage JPEG est significativement plus rapide que l'encodage WebP, notamment aux niveaux de qualité élevés. Pour des pipelines de traitement en temps réel ou à très haute volumétrie, cela peut avoir un impact mesurable sur les coûts.

Cas particulier : les emails. WebP n'est pas supporté par Outlook bureau (versions 2016–2021), qui représente encore une part significative des ouvertures en contexte B2B. Pour les images destinées aux campagnes email, continuez à utiliser JPEG et PNG sans exception.

JPEG, WebP et AVIF : tableau comparatif des gains de compression

Critère	JPEG	WebP	AVIF
Compression vs JPEG (même qualité visuelle)	Référence	−25 à −35 %	−40 à −55 %
Support navigateurs (2026)	100 %	97 %	93 %
Transparence (alpha)	Non	Oui	Oui
Animation	Non	Oui	Oui
Vitesse d'encodage	Très rapide	Rapide	Lent
Vitesse de décodage	Très rapide	Rapide	Moyen
Métadonnées Exif	Complet	Partiel	Partiel
Support email	Universel	Partiel	Non

Stratégie de migration vers WebP

Pour un site web existant, la migration de JPEG vers WebP ne nécessite pas de reconstruire l'ensemble des assets. La stratégie recommandée en 2026 est le service conditionnel : servir WebP aux navigateurs qui le supportent, JPEG aux autres.

La balise HTML <picture> permet cette logique nativement, sans JavaScript :

<picture>
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="Description de l'image">
</picture>

Pour les sites à fort volume d'images, une règle de négociation de contenu HTTP côté serveur est plus scalable, elle ne nécessite aucune modification du HTML :

# Apache : servir WebP si le navigateur le supporte et que le fichier existe
<IfModule mod_rewrite.c>
  RewriteCond %{HTTP_ACCEPT} image/webp
  RewriteCond %{REQUEST_FILENAME}.webp -f
  RewriteRule ^(.+)\.(jpe?g|png)$ $1.$2.webp [T=image/webp,E=accept:1]
</IfModule>

Les CDN modernes (Cloudflare, Fastly, AWS CloudFront avec Lambda@Edge, Cloudinary) proposent cette conversion automatique à la volée, sans toucher aux fichiers source. Un gain de 30 % sur le poids des images se traduit directement par un meilleur score LCP et un meilleur référencement.

Essayez les outils imgpact

Convertissez vos JPEG en WebP en un clic et comparez le gain de poids à qualité visuelle équivalente, directement dans votre navigateur, sans installation.

Convertir JPEG en WebP