WebP vs AVIF vs JPEG vs PNG: quel format d’image choisir et comment réduire le poids des fichiers ?

En 2026, les quatre formats restent utiles, mais pour des usages différents :

• AVIF gagne le plus souvent en poids pour les photographies et les images complexes.
• WebP offre un excellent équilibre entre compression, fonctionnalités, compatibilité et coût d’intégration.
• JPEG reste le fallback le plus sûr pour la photographie et les systèmes dont les contraintes sont inconnues.
• PNG reste pertinent pour les graphiques raster sans perte, les captures d’interface, les détails pixelisés et la transparence précise.

TL;DR : pour les photos, servez AVIF en premier, WebP ensuite et conservez JPEG en fallback. Pour les captures d’écran, les graphiques simples et la transparence, comparez WebP ou AVIF sans perte à PNG. Pour les icônes et logos, SVG est généralement préférable aux quatre formats raster.

Fonctionnalités, compatibilité et recommandations vérifiées le 23 juillet 2026.

Comparaison rapide

AVIF prend en charge la compression avec ou sans perte, la transparence, l’animation, le HDR et le large gamut. WebP combine lui aussi modes avec et sans perte, canal alpha et animation. PNG est sans perte et gère la transparence partielle, mais devient généralement trop lourd pour les photographies.

Quel format choisir selon le visuel ?

La bonne stratégie est une politique par type d’asset, pas la conversion uniforme de tous les fichiers vers AVIF.

1. JPEG : toujours utile, rarement le meilleur format principal

JPEG a été conçu pour les photographies. Sa compression avec perte supprime une partie des informations peu perceptibles par l’œil humain. Les fichiers deviennent bien plus petits qu’un PNG sans perte, mais une compression excessive crée blocs, changements de couleur et perte de détails.

Avantages

• compatibilité presque universelle,
• fallback fiable pour les photos,
• encodage et décodage rapides,
• prise en charge du JPEG progressif,
• outils matures comme MozJPEG.

Le JPEG progressif affiche d’abord une version approximative sur toute la surface puis l’affine progressivement. Il peut être légèrement plus petit qu’un JPEG baseline et donner une meilleure sensation sur une connexion lente.

Limites

• pas de canal alpha,
• pas d’animation,
• compression destructive,
• artefacts rapides sur texte, traits fins et interfaces,
• dégradation lors des recompressions successives,
• WebP et AVIF sont souvent plus petits à qualité comparable.

Une étude officielle de l’équipe WebP a mesuré des fichiers WebP 25 à 34 % plus petits que JPEG à SSIM comparable. Ce chiffre ne constitue pas une promesse universelle : source, version d’encodeur, réglages et métrique influencent le résultat.

Quand choisir JPEG ?

• lorsqu’un seul fichier doit fonctionner dans le plus grand nombre de systèmes,
• lorsque le client final n’est pas contrôlé,
• pour un ancien CMS, un e-mail, un document ou une plateforme externe,
• comme fallback dans <picture>,
• lorsque la chaîne AVIF/WebP n’est pas encore prête.

Sur un frontend moderne maîtrisé, mieux vaut généralement servir un format plus récent avant JPEG.

2. PNG : fidélité, netteté et transparence au prix du poids

PNG utilise une compression sans perte et conserve les pixels sans perte liée à l’encodage. Il prend également en charge un canal alpha avec de nombreux niveaux de transparence.

Avantages

• texte, lignes et interfaces très nets,
• transparence alpha complète,
• pas de perte générationnelle,
• compatibilité universelle,
• bon format de référence raster.

Limites

• photographies nettement plus lourdes que JPEG, WebP ou AVIF,
• le PNG classique n’est pas animé ; APNG est la variante animée,
• le raster se redimensionne moins bien que SVG,
• métadonnées, canaux ou palettes mal optimisés augmentent le fichier,
• la transparence seule ne justifie plus automatiquement PNG.

web.dev indique que PNG n’est presque jamais un bon format de livraison pour une photographie. Les graphiques simples avec semi-transparence doivent être comparés à WebP ou AVIF.

Quand PNG reste-t-il pertinent ?

• capture avec petit texte et lignes fines,
• copie raster sans perte,
• plateforme qui accepte PNG mais pas WebP/AVIF,
• petite palette de couleurs,
• reproduction parfaite prioritaire,
• source destinée à être réencodée plus tard.

Pour un logo, une icône, un diagramme ou une illustration simple, commencez par SVG.

3. WebP : le format par défaut le plus pratique

Google a développé WebP comme alternative plus efficace à JPEG, puis y a ajouté compression sans perte, transparence et animation. Il peut donc remplacer de nombreuses photos JPEG, images PNG et animations GIF.

Avantages

• modes avec et sans perte,
• transparence,
• animation,
• très large compatibilité dans les navigateurs actuels,
• écosystème mature dans les CMS, bibliothèques et CDN d’images,
• généralement plus petit que JPEG ou PNG,
• encodage souvent plus simple et rapide qu’AVIF.

Limites

• pas d’affichage progressif,
• certains anciens logiciels exigent JPEG ou PNG,
• les valeurs « quality » ne sont pas comparables entre formats,
• WebP n’est pas toujours plus petit qu’un AVIF bien réglé,
• WebP sans perte ne bat pas toujours un PNG fortement optimisé.

Quand WebP est-il le meilleur choix ?

WebP convient lorsqu’une équipe veut :

• réduire rapidement le poids des images,
• conserver la transparence,
• couvrir presque tous les navigateurs actuels avec un format moderne,
• traiter localement ou à la demande,
• limiter le nombre de variantes en production,
• équilibrer qualité, poids et coût d’encodage.

Le Convertisseur et optimiseur d’images POLPROG traite localement PNG, JPG et WebP, avec conversion, compression, redimensionnement et suppression des métadonnées.

4. AVIF : transfert minimal et fonctions modernes

AVIF repose sur le codec AV1 et le conteneur HEIF. Il prend en charge compression avec et sans perte, transparence, animation, HDR et large gamut.

Avantages

• excellente efficacité de compression,
• bonne qualité à faible bitrate,
• modes avec et sans perte,
• transparence et animation,
• images 8, 10 et 12 bits, HDR,
• prise en charge dans tous les navigateurs majeurs actuels,
• très bon comportement sur photos, dégradés et visuels complexes.

AVIF fait partie de Baseline depuis janvier 2024, donc les versions actuelles des grands moteurs de navigateur le prennent en charge.

Limites

• pas de rendu progressif : le fichier doit généralement être téléchargé avant affichage,
• encodage potentiellement plus coûteux que JPEG ou WebP,
• qualité et poids très dépendants de l’encodeur, de la vitesse et du sous-échantillonnage,
• certaines plateformes externes refusent encore .avif,
• petits visuels et icônes simples parfois plus lourds que SVG, PNG ou WebP,
• mauvais réglages pouvant lisser les textures ou les petits textes.

MDN indique qu’AVIF peut compresser légèrement mieux que WebP, mais ne prend pas en charge le rendu progressif. Il faut éviter les promesses fixes du type « toujours 50 % plus petit ».

Quand déployer AVIF ?

• lorsque les images représentent une grande partie du transfert,
• pour de nombreux visuels produit ou hero,
• lorsqu’une pipeline automatisée existe,
• lorsque les fichiers sont encodés une fois et servis souvent,
• pour HDR, large gamut ou profondeur de couleur supérieure,
• lorsqu’un fallback WebP/JPEG reste disponible.

5. AVIF est-il toujours plus petit que WebP ?

Non. web.dev le présente comme le meilleur candidat pour des catalogues photographiques, avec WebP en fallback moderne et JPEG comme défaut le plus fiable. Le résultat dépend toutefois :

• du contenu et de la résolution,
• du bruit,
• du texte et des lignes fines,
• du mode avec ou sans perte,
• de la profondeur et du sous-échantillonnage,
• de la version de l’encodeur,
• du réglage de vitesse,
• de la métrique de qualité.

Comparez les formats à qualité visuelle équivalente, pas avec le même numéro de curseur. quality=75 ne signifie pas la même chose dans JPEG, WebP et AVIF.

6. Core Web Vitals et LCP

Un format moderne peut réduire le temps de transfert et améliorer la composante téléchargement du LCP. Il ne corrige pas une découverte tardive, un serveur lent, de mauvaises dimensions ou un rendu piloté par JavaScript.

Pour une image LCP :

• ne pas utiliser loading="lazy",
• la placer tôt dans le HTML,
• envisager fetchpriority="high",
• définir width et height,
• fournir la bonne résolution via srcset et sizes,
• réduire redirections et dépendances,
• éviter de télécharger plusieurs variantes inutiles.

web.dev déconseille le lazy loading des images au-dessus de la ligne de flottaison, notamment les candidates LCP. fetchpriority="high" peut aider à les prioriser plus tôt.

Voir aussi Audit de site web en 2026 et Core Web Vitals en pratique.

7. Implémentation correcte avec <picture>

<picture>
  <source
    type="image/avif"
    srcset="/images/hero-800.avif 800w,
            /images/hero-1280.avif 1280w,
            /images/hero-1920.avif 1920w"
    sizes="100vw"
  >
  <source
    type="image/webp"
    srcset="/images/hero-800.webp 800w,
            /images/hero-1280.webp 1280w,
            /images/hero-1920.webp 1920w"
    sizes="100vw"
  >
  <img
    src="/images/hero-1280.jpg"
    srcset="/images/hero-800.jpg 800w,
            /images/hero-1280.jpg 1280w,
            /images/hero-1920.jpg 1920w"
    sizes="100vw"
    width="1920"
    height="1080"
    fetchpriority="high"
    alt="Tableau de bord d’analyse des performances du site"
  >
</picture>

Le navigateur choisit la première source prise en charge. AVIF doit donc précéder WebP, tandis que <img> fournit le fallback.

Google peut découvrir l’image dans l’attribut src de <img>, y compris à l’intérieur de <picture>. Google Search prend en charge JPEG, PNG, WebP et AVIF.

Pour les images hors écran :

<img
  src="/images/example.webp"
  width="960"
  height="640"
  loading="lazy"
  decoding="async"
  alt="Comparaison du poids des fichiers image"
>

N’ajoutez pas loading="lazy" automatiquement aux images hero, produit ou LCP.

8. Les images responsives comptent plus que le format seul

Convertir un fichier 2400 × 1600 en AVIF ne règle rien si le téléphone ne l’affiche qu’à 360 px. Servir le bon nombre de pixels peut économiser davantage qu’un changement de codec.

Pensez à :

• plusieurs largeurs dans srcset,
• un attribut sizes correct,
• un cadrage mobile spécifique si nécessaire,
• haute densité uniquement lorsqu’elle est visible,
• limites de dimensions dans le CMS,
• vraies miniatures au lieu d’un grand fichier réduit en CSS.

Format, dimensions et compression forment un seul système.

9. Comparer la qualité correctement

1. Partir de l’original ou d’une source sans perte.
2. Générer plusieurs niveaux de qualité pour chaque format.
3. Comparer à la taille d’affichage finale.
4. Examiner visages, cheveux, dégradés, texte, bords et zones sombres.
5. Mesurer le coût d’encodage et de décodage.
6. Choisir le plus petit fichier restant acceptable.
7. Répéter pour plusieurs catégories d’images.

SSIM peut aider à automatiser les comparaisons, mais ne remplace pas le contrôle visuel.

10. Erreurs fréquentes

Réencoder un JPEG déjà très compressé

AVIF ne peut pas restaurer les détails perdus. Utilisez l’original ou une source sans perte.

Utiliser un seul niveau de qualité

Portrait, capture, photo nocturne et dégradé réagissent différemment. La pipeline doit utiliser des profils ou un contrôle qualité.

Oublier les dimensions

Sans width et height, CLS peut apparaître quel que soit le format.

Charger l’image hero en lazy loading

Même un petit AVIF arrivera trop tard s’il est découvert après le rendu ou marqué loading="lazy".

Générer trop de variantes

Plusieurs largeurs dans quatre formats augmentent stockage et temps de build. Ne générez que les variantes utiles.

Utiliser PNG pour toute transparence

WebP et AVIF disposent aussi d’alpha. Gardez PNG lorsqu’il fournit de meilleurs bords, un fichier plus petit ou une compatibilité requise.

Utiliser du raster pour logos et icônes

SVG est généralement plus léger, plus net et plus facile à adapter.

11. SEO des images : le format n’est qu’un élément

Google Search prend en charge les quatre formats. Aucun bonus de classement n’est documenté pour l’extension .avif ou .webp. Le bénéfice est indirect : moins de transfert peut améliorer performance et expérience.

Vérifiez aussi :

• URL stable et descriptive,
• extension conforme au vrai type,
• type MIME correct,
• texte alternatif utile,
• contexte textuel visible,
• accès pour Googlebot,
• dimensions correctes,
• sitemap d’images pour les sites très visuels,
• métadonnées de licence si nécessaire.

Utilisez État du site web pour les contrôles techniques et Aperçu Open Graph pour les cartes sociales.

12. Politique recommandée

Option simple

• WebP principal,
• JPEG en fallback photo,
• PNG pour quelques graphiques,
• SVG pour logos et icônes,
• srcset sur les images importantes.

Option optimale

• AVIF en premier,
• WebP en second,
• JPEG fallback,
• WebP/AVIF sans perte ou PNG pour les captures,
• largeurs automatiques,
• budget qualité et transfert,
• suivi LCP et RUM.

E-commerce

• photos produit en AVIF et WebP,
• fallback JPEG,
• variantes grandes et miniatures séparées,
• zoom chargé après interaction,
• image principale sans lazy loading,
• contrôle des textures, couleurs et transparences,
• cache et CDN d’images.

Verdict

AVIF est le meilleur choix quand le transfert minimal est prioritaire et que la pipeline est solide. WebP est le meilleur format général pour sa simplicité, sa compatibilité et sa forte compression. JPEG reste le fallback photo le plus sûr, tandis que PNG doit être réservé consciemment aux graphiques sans perte et à la transparence.

La stratégie 2026 :

AVIF → WebP → JPEG

pour les photos, et :

AVIF/WebP sans perte ↔ PNG

pour les visuels nets ou transparents, après comparaison réelle.