Guide de compression d'images : choisir entre JPG, PNG et WebP

Publié le 2026-04-13 8 min de lecture

Résumé (TL;DR)

Le week-end dernier, j’ai glissé une photo de chat de 4,2 Mo dans Squoosh à une qualité WebP de 80. Elle est ressortie à 380 Ko — une réduction de 91 % — et honnêtement, je ne parviens à la distinguer de l’original sur aucune taille d’écran réaliste. C’est exactement ce que la compression avec perte est censée faire. Chaque fois que je l’oublie, j’ouvre un blog, j’attends trois secondes qu’une image hero JPG de 2 Mo atterrisse sur la 4G, et la leçon me revient toute seule.

Choisir un format d’image, c’est moins trouver « le meilleur » que faire correspondre le format à un usage. Pour la photographie en tons continus, les formats avec perte comme JPEG, WebP avec perte et AVIF gardent des fichiers petits avec une différence perceptuelle minime ; à qualité visuelle équivalente, WebP produit généralement des fichiers environ 25–35 % plus petits que JPEG, et AVIF se situe souvent autour de 40–50 % plus petits que JPEG selon les réglages d’encodeur. Pour les logos, icônes, captures d’écran et tout ce où la netteté des bords ou la lisibilité du texte compte, les formats sans perte comme PNG, WebP sans perte et TIFF sont plus sûrs. Si vous avez besoin à la fois de transparence et d’animation, WebP, APNG et AVIF sont les principales options. La prise en charge navigateur est large début 2026 : WebP est livré depuis Chrome 32 (2014), Firefox 65 et Safari 14 (fin 2020), et AVIF fonctionne dans Chrome 85 (août 2020), Firefox 93 (octobre 2021) et Safari 16 (septembre 2022) et au-delà. Une base raisonnable est « SVG pour les logos vectoriels, WebP ou AVIF pour les photos, PNG pour les captures d’écran », avec un repli <picture> vers JPEG quand il faut prendre en charge des environnements plus anciens.

Contexte et concepts

Les formats avec perte (JPEG, WebP avec perte, AVIF) réduisent la taille des fichiers en écartant les informations auxquelles le système visuel humain est moins sensible. Deux techniques principales sous-tendent cela : la quantification, qui arrondit plus agressivement les coefficients du domaine fréquentiel pour les hautes fréquences spatiales, et le sous-échantillonnage chromatique (chroma subsampling), qui stocke les canaux de couleur à une résolution inférieure à celle de la luminance. Un réglage 4:4:4 préserve la chrominance à pleine résolution, tandis que le plus courant 4:2:0 réduit la chrominance de moitié dans les deux directions. Ce réglage par défaut convient à la plupart des photos, mais il peut rendre flous les contours de texte coloré, en particulier les caractères rouges et bleus sur fond sombre.

JPEG, normalisé en 1992, utilise une transformée en cosinus discrète (DCT) par blocs appliquée à des blocs de 8x8 pixels. WebP s’appuie sur les techniques intra-trame du codec vidéo VP8, et AVIF utilise l’ensemble intra-trame d’AV1. Ces deux formats sont donc nettement plus modernes que JPEG dans leur façon de prédire, transformer et quantifier les données d’image, avec des tailles de blocs plus grandes, une prédiction directionnelle et un meilleur codage entropique. PNG est une autre bête : c’est un format sans perte utilisant la famille de compression deflate, avec une prise en charge intégrée de la transparence alpha et des couleurs indexées par palette. PNG ne jette jamais de données, mais pour le contenu photographique, cette pureté se paie par des fichiers beaucoup plus lourds.

Un concept connexe est le décodage progressif. JPEG progressif et PNG entrelacé permettent à l’utilisateur de voir immédiatement une version basse résolution de l’image et de l’affiner à mesure que les octets arrivent. WebP et AVIF se décodent généralement en une seule passe aujourd’hui, ce qui importe surtout pour de très grandes images ou des connexions lentes. Enfin, SVG n’est pas du tout un format raster compressé mais une description vectorielle ; la taille du fichier dépend du nombre de formes et de la compression du texte lui-même (gzip et brotli sont très efficaces sur la source SVG).

Comparaison et données

FormatAvec perteSans perteTransparenceAnimationCompression photo typiquePrise en charge navigateur 2025
JPEGOuiNonNonNonEnviron 10:1Tous les navigateurs
PNGNonOuiOuiExtension APNGEnviron 2–3:1Tous les navigateurs
WebPOuiOuiOuiOui25–35 % plus petit que JPEGSafari 14 (2020) et plus récent, quasi universel
AVIFOuiOuiOuiOui40–50 % plus petit que JPEGChrome 85+, Firefox 93+, Safari 16+
GIFOui (palette, 256 couleurs)Non1 bit seulementOuiMédiocre pour les photosTous les navigateurs

Traitez ces chiffres comme des tendances générales. La compression réelle dépend beaucoup du contenu source, de l’encodeur, du préréglage et de la qualité cible. Le même JPEG en qualité 85 et en qualité 60 peut différer d’un facteur 3–4 en taille, et l’avantage d’efficacité d’AVIF se réduit quand on utilise des préréglages rapides. Les benchmarks publiés par Google et Mozilla entre 2019 et 2023 ont rapporté des économies WebP d’environ 26 % à 34 % par rapport à JPEG à SSIM équivalent, et des économies AVIF d’environ 40 % à 50 % par rapport à JPEG — mais ces plages supposent des encodeurs en préréglage lent et des cibles de qualité ajustées, pas les valeurs par défaut en un clic de la plupart des applications d’édition.

Une autre dimension est le coût d’encodage et de décodage. JPEG se décode en fractions de milliseconde sur n’importe quel appareil. WebP est proche. Le décodage AVIF est plus gourmand en CPU, et l’encodage AVIF avec des préréglages haute qualité peut prendre plusieurs secondes par image. Ce profil de coût convient à un pipeline d’actifs en build-time, mais il est malaisé pour du contenu généré par l’utilisateur en direct où un serveur ré-encode chaque upload sur le chemin critique.

Scénarios concrets

Scénario 1 — Miniatures et images hero de blog. J’ai récemment audité mon propre site et trouvé une image hero livrée à 1,8 Mo. Une ré-exportation en WebP qualité 82 l’a fait passer à 210 Ko, et le Largest Contentful Paint de la page est tombé de 2,4 s à 1,1 s sur un profil 4G limité dans Lighthouse. Par défaut, utilisez WebP comme format principal et laissez un élément <picture> servir JPEG en repli pour les très anciens environnements. Redimensionnez toujours l’image exportée à la largeur d’affichage CSS réelle ; servir une photo de 3000 pixels de large dans un conteneur de 600 pixels gaspille de la bande passante quel que soit le format.

Scénario 2 — Logos et icônes. Si vous avez une source vectorielle, exportez d’abord en SVG. J’ai une fois revu une landing page où un logo rouge de marque avait été exporté en JPEG qualité 75 ; les bords rouges bavaient en un halo rose autour de chaque glyphe. Le sous-échantillonnage chromatique 4:2:0 ruine les bords rouges sur fond sombre avant presque tout le reste. Si seul un raster est disponible, choisissez PNG ou WebP sans perte. Traitez la compression avec perte sur les logos comme un signal d’alerte, pas comme une optimisation.

Scénario 3 — Captures d’écran et UI. Les captures d’écran devraient par défaut être en PNG. Le chrome du navigateur, les snippets de code et les polices CJK montrent fortement les artefacts JPEG — je l’ai appris après qu’un relecteur de doc a signalé « police monospace floue » sur deux PR consécutives. Si vous devez réduire le fichier, utilisez pngquant (sur macOS, brew install pngquant) pour descendre la palette à 256 couleurs ; les captures d’UI ne montrent presque jamais la différence, et le fichier rétrécit souvent de 4 à 6 fois. Pour les sites de documentation, envisagez d’associer PNG à un balisage CSS d’image responsive pour que les écrans retina reçoivent des actifs 2x tandis que les écrans plus anciens téléchargent la version 1x — cela économise habituellement plus d’octets que de changer de format.

Scénario 4 — Archivage des sources. Pour les originaux que vous pourriez retraiter plus tard (masters photographiques, scans bruts, photos produit), conservez une copie sans perte comme TIFF ou WebP sans perte en stockage froid et dérivez les variantes de livraison avec perte à la demande. Recomprimer un JPEG avec perte à plusieurs reprises dégrade la qualité à chaque cycle (« perte de génération »), donc vous voulez une source propre sur laquelle revenir.

Idées fausses courantes

« PNG est toujours la plus haute qualité. » C’est sans perte, ce qui signifie reproduction parfaite, mais pour les photographies cette pureté se traduit par des fichiers plusieurs fois plus lourds que nécessaire. Sur mobile, des photos de plusieurs mégaoctets nuisent au temps de chargement perçu et aux Core Web Vitals.

« WebP ne fonctionne pas dans tous les navigateurs. » Depuis Safari 14 fin 2020, WebP est pris en charge dans tous les navigateurs grand public. Si une prise en charge historique est réellement requise, un élément <picture> avec un repli JPEG est une solution propre.

« AVIF est magique. » L’efficacité de compression est excellente, mais l’encodage est significativement plus lent que JPEG ou WebP. Sur mon MacBook Air M2, avifenc --speed 4 prend 5–9 secondes pour une seule photo 2400×1600 ; à --speed 0, attendez-vous à 30 s ou plus. Le décodage sur les appareils mobiles plus anciens peut aussi être un souci. AVIF convient mieux aux pipelines batch et à l’optimisation build-time qu’au ré-encodage de chaque upload utilisateur sur le chemin critique.

« Utilisez simplement JPEG. » C’était raisonnable jusque vers 2015, mais WebP et AVIF modernes donnent généralement des fichiers plus petits à qualité comparable avec une prise en charge universelle ou quasi universelle. Les nouveaux pipelines devraient traiter WebP comme la base plutôt que JPEG.

« Des réglages de qualité plus élevés valent toujours le coup. » Au-dessus d’environ qualité 85 pour JPEG ou WebP, la taille du fichier croît plus vite que la qualité perceptuelle. Les spectateurs remarquent rarement la différence entre qualité 85 et 95, mais le fichier peut être deux fois plus gros. Mesurez avec une métrique perceptuelle (SSIM, butteraugli) plutôt que de faire confiance au curseur de qualité comme à une échelle linéaire.

« Le redimensionnement n’importe pas si je compresse bien. » Les plus grands gains uniques en livraison d’images viennent généralement du fait d’envoyer des images de taille appropriée plutôt que du réglage de compression. Un WebP de 800 pixels de large est presque toujours plus léger qu’un WebP de 3000 pixels, quel que soit le réglage de qualité, parce que vous supprimez des pixels plutôt que de les approximer.

Liste de vérification

  1. La source est-elle vectorielle ? Si oui, enregistrez en SVG.
  2. Avez-vous besoin de transparence ?
    • Oui et le contenu est photographique : WebP avec perte et alpha ou AVIF.
    • Oui et le contenu est un logo ou une icône : PNG ou WebP sans perte.
  3. Avez-vous besoin d’animation ? WebP animé, APNG ou AVIF. La palette 256 couleurs de GIF est médiocre pour les photos.
  4. Le contenu est-il photographique ou riche en dégradés ? Par défaut, WebP avec perte, et ajoutez AVIF là où la bande passante compte.
  5. Le contenu est-il une capture d’écran ou une UI chargée de texte ? Préférez PNG ou WebP sans perte.
  6. Avez-vous besoin d’une compatibilité maximale ? Utilisez un élément <picture> avec des sources AVIF → WebP → JPEG dans cet ordre.

Outil associé

Vous pouvez tester ces compromis directement dans le compresseur d’images Patrache Studio référencé dans relatedToolUrl. Les images font généralement partie d’un pipeline d’actifs plus large, donc lire les guides complémentaires aide : Fusion et découpage PDF dans le navigateur couvre ce qui se passe quand vos images atterrissent dans des contrats ou des lots scannés, et Sécurité des QR codes mérite lecture si vos images incluent des QR codes scannables sur des emballages produit ou des affiches.

Références

Outil associé

tools.patrache.studio/image/compress/