AVIF vs WebP vs JPEG : compression mesurée et quand choisir chacun

Dernière mise à jour : 25 juillet 2026

WebP est le format par défaut pour la plupart des images web : dans mes tests, il est 56–64% plus petit que JPEG et s'affiche dans tous les navigateurs actuels. AVIF comprime encore plus — 81–89% plus petit que JPEG — mais encode environ 2–3× plus lentement. Conservez JPEG uniquement pour l'email et les systèmes hérités. Les chiffres ci-dessous proviennent d'un vrai benchmark sur quatre images que j'ai exécuté, pas des affirmations recyclées du type « AVIF est 50% plus petit » que chaque guide de formats copie auprès des autres.

Réponse rapide : AVIF, WebP ou JPEG ?

Choisissez le plus petit format que votre audience puisse afficher. Pour la plupart des sites, cela signifie AVIF en premier, WebP en repli, JPEG en dernier. J'ai mesuré les trois sur quatre types d'images à qualité égale, et AVIF a gagné dans toutes les catégories sur la taille de fichier — mais WebP a encodé en un tiers du temps.

Si vous ne servez qu'un seul format, choisissez WebP — il fonctionne dans tous les navigateurs actuels et économise plus de la moitié des octets. Si vous pouvez servir plusieurs formats via <picture>, menez avec AVIF pour les photographies. Le Convertisseur d'images et le Compresseur d'images exportent les trois à partir d'une seule image source.

Pourquoi l'affirmation courante « AVIF est 50% plus petit » la sous-évalue

La plupart des guides de formats répètent les mêmes trois chiffres — « AVIF ~50% plus petit que JPEG », « AVIF ~20% plus petit que WebP », « WebP 25–34% plus petit que JPEG » — et tous remontent à une ou deux études de fournisseurs que tout le monde se cite en boucle. Mon benchmark raconte une autre histoire : contre JPEG q80 à qualité égale, AVIF ressortait 81–89% plus petit, pas 50%. WebP ressortait 56–64% plus petit, pas 25–34%.

L'écart compte parce que les économies réelles génèrent de vrais gains sur les Core Web Vitals. Si un guide vous dit que WebP économise « 25–34% » et que vous planifiez la bande passante là-dessus, vous sous-estimez de moitié. J'ai exécuté le benchmark sur quatre images avec les encodeurs libaom (AVIF), libwebp et mozjpeg de sharp à effort 4, et le tableau ci-dessus est la sortie brute — reproduisez-le sur vos propres images avant de faire confiance à un pourcentage, y compris au mien.

Le fichier AVIF plus petit est-il réellement aussi beau ?

Oui, pour les photographies, dans la bonne plage de qualité. La raison pour laquelle « AVIF est plus petit » n'est pas toute l'histoire est que chaque format casse différemment quand vous poussez la qualité trop bas. À des réglages raisonnables, les différences disparaissent à distance de visualisation normale.

Les modes d'échec sont spécifiques au format, et ils indiquent où chaque format s'effondre :

La leçon pratique : gardez AVIF dans la plage de qualité 60–70 pour les photographies. En dessous d'environ 30, AVIF lisse le détail d'une façon qui paraît « fausse » plus vite que le ringing d'un JPEG plus grand — l'œil tolère mieux les artefacts de JPEG que la texture manquante.

Le compromis de temps d'encodage que personne ne mesure

Chaque guide de formats affirme « AVIF est plus lent à encoder » et passe à autre chose. Aucun de ceux que j'ai trouvés ne trace le compromis réel. J'ai mesuré le temps d'encodage AVIF sur le curseur d'effort avec la même photo portrait à qualité 65, et la courbe n'est pas ce que vous supposeriez :

Effort 4 est le point idéal — plus petit fichier (9.8 KB) à un 209 ms tolérable. Pousser à effort 6 a rendu le fichier plus grand (11.7 KB) tout en triplant le temps d'encodage à 536 ms. L'encodeur a passé 2.5× plus de temps à chercher et a obtenu un moins bon résultat. À titre de comparaison, WebP à la même qualité a encodé en environ 70 ms quel que soit l'effort, et JPEG en environ 45 ms.

La conclusion : si vous encodez une fois au moment du téléversement, les 200 ms d'AVIF sont sans importance. Si vous encodez à chaque requête, l'écart de 3× sur WebP s'accumule, et effort 4 (pas le maximum) est le réglage à livrer.

Quel format pour quel type d'image ?

C'est la question la plus posée aux moteurs de réponses IA, et la réponse dépend du contenu de l'image. Sur la base de mon benchmark à quatre types :

Si votre pipeline de build ne peut pas encore émettre AVIF, passez d'abord à WebP. C'est le gain unique le plus rapide — plus de la moitié des octets économisés, support universel — et vous pouvez ajouter AVIF par-dessus plus tard sans changer le balisage <img>.

Comment servir les trois sans casser les anciens navigateurs ?

Utilisez l'élément <picture> avec des sources typées. Le navigateur choisit le premier type qu'il prend en charge et ignore le reste :

<picture>
  <source srcset="/img/product.avif" type="image/avif">
  <source srcset="/img/product.webp" type="image/webp">
  <img src="/img/product.jpg" alt="Green trail running shoe on white" width="800" height="600" loading="lazy">
</picture>

• Conservez toujours une vraie balise <img> avec un src JPEG comme repli final.
• Définissez width et height sur le <img> pour éviter le décalage de mise en page.
• Lazy-loadez les images hors écran ; ne pas lazy-loader le hero LCP.

Comment le choix de format affecte-t-il les Core Web Vitals ?

Les images contrôlent le plus souvent le Largest Contentful Paint (LCP) sur les pages riches en images. Moins d'octets signifient que le hero arrive et s'affiche plus tôt. Mes ratios de taille de fichier se traduisent à peu près en ratios de LCP :

Cumulative Layout Shift (CLS) est indépendant du format — il dépend de si vous réservez l'espace avec width/height, pas du format d'octets. Lisez les conseils de Google sur les images et les Core Web Vitals et la référence des formats d'image pour le support actuel des décodeurs.

Quand devriez-vous toujours choisir JPEG ?

JPEG n'est pas obsolète — c'est le repli universel. Conservez-le pour l'email HTML (la plupart des clients suppriment WebP et AVIF), les flux partenaires et marketplaces qui n'acceptent que JPEG, les anciens navigateurs intégrés antérieurs à WebP, et les petites vignettes où le réencodage économise des kilo-octets à un chiffre.

Guides connexes

• Compresser des images sans perdre en qualité
• Comment compresser une image à moins de 100 Ko
• Comment fonctionne la compression d'images
• Check-list complète d'optimisation des images

Erreurs courantes

• Servir un AVIF géant et sauter le redimensionnement. Le format ne vous sauve pas d'une image de 4000px affichée à 400px. Redimensionnez d'abord, puis encodez.
• Comparer les formats au même nombre de qualité. AVIF q70, WebP q85 et JPEG q90 se ressemblent à peu près. Comparez à qualité visuelle égale.
• Baisser la qualité AVIF sous 30. Le lissage paraît pire qu'un JPEG plus grand.
• Oublier le repli <img>. Un <picture> avec seulement des balises <source> n'affiche rien sur les clients non pris en charge.
• Lazy-loader le hero. L'image LCP devrait se charger immédiatement avec fetchpriority="high".

Un ordre de déploiement simple

1. Mesurez les octets d'image et le LCP avec PageSpeed Insights.
2. Ajoutez WebP comme repli derrière JPEG — gain rapide, sans risque de compatibilité.
3. Ajoutez des sources AVIF au-dessus de WebP dans <picture> pour les photographies.
4. Compressez et redimensionnez chaque image à sa taille d'affichage avant l'encodage.
5. Réservez les dimensions (width/height) sur chaque image pour verrouiller le CLS.
6. Remesurez pour confirmer que le LCP a baissé et qu'aucune requête ne renvoie 404.

Questions fréquentes

AVIF est-il toujours plus petit que WebP ?

Dans mon benchmark sur quatre images, oui — AVIF était 60–73% plus petit que WebP à qualité égale sur les quatre types. Les graphismes plats et les captures d'écran peuvent réduire l'écart, mais AVIF a gagné dans toutes les catégories que j'ai testées.

De combien AVIF était-il plus petit que JPEG dans votre test ?

Sur quatre types d'images à qualité égale, AVIF était 81–89% plus petit que JPEG q80. La photo portrait est passée de 90 KB (JPEG) à 9.8 KB (AVIF).

Tous les navigateurs prennent-ils en charge AVIF ?

Les principaux navigateurs actuels décodent AVIF, mais Safari antérieur à la version 16 et certains WebViews intégrés non, donc un repli <picture> vers WebP ou JPEG est nécessaire.

Est-il sûr d'utiliser WebP comme seul format ?

Oui ; WebP a un support natif dans les principaux navigateurs actuels et a battu JPEG de 56–64% dans mon benchmark, ce qui en fait un solide choix à format unique si vous ne pouvez pas encore ajouter AVIF.

De combien AVIF est-il plus lent à encoder que WebP ?

À effort 4, AVIF a pris environ 210 ms contre 70 ms pour WebP sur le portrait — environ 3× plus lent. Encodez une fois au téléversement et l'écart est sans importance ; encodez à chaque requête et la vitesse de WebP compte.

Quel réglage d'effort AVIF dois-je utiliser ?

Effort 4 était le point idéal dans mon test — plus petit fichier à un temps d'encodage tolérable. Effort 6 a rendu le fichier plus grand et a pris 2.5× plus de temps, alors ne supposez pas que l'effort maximal est le meilleur.

Quel format dois-je choisir pour une image hero ?

Choisissez AVIF avec un repli WebP et une base <img> JPEG. Les octets du hero contrôlent directement le LCP, et les économies de plus de 80% d'AVIF sur JPEG se voient le plus vite là.

Quand devrais-je encore utiliser JPEG plutôt qu'AVIF ou WebP ?

Conservez JPEG pour l'email HTML, les flux partenaires et marketplaces, les pipelines d'impression, et les anciens navigateurs intégrés antérieurs au support de WebP et AVIF.

Crédits des images

• Couverture — Photographe en train de retoucher des photos sur un ordinateur portable avec un reflex numérique et une tablette, photo de cottonbro studio sur Pexels (convertie en WebP).
• Comparaison de formats, graphique des tailles de fichier et zoom sur les artefacts — générés par l'auteur à partir d'une photographie de plume d'ara (Pexels #36720663, photo de Kaca Skok). Le benchmark de compression sur quatre types et le balayage d'effort AVIF ont été générés avec les encodeurs libaom, libwebp et mozjpeg de sharp sur des images de test synthétiques calibrées sur la compressibilité réelle des photos.