WebP vs AVIF en 2026 : lequel utiliser pour ton site
Comparaison honnête 2026 : WebP vs AVIF pour la performance web, support navigateur, taille de fichier, vitesse d'encodage et la chaîne de fallback pratique, avec de vrais benchmarks.
WebP est sorti en 2010. AVIF est sorti en 2019. En 2026, les deux sont matures, les deux ont ~94%+ de support navigateur mondial, et les deux écrasent JPG/PNG sur la taille de fichier. Mais choisir entre eux, ou comment utiliser les deux, fait encore trébucher développeurs et gestionnaires de contenu. Ce guide te donne de vrais benchmarks et une règle de décision propre.
TL;DR, la réponse 2026
Pour les sites statiques et les assets pré-construits : AVIF en premier, WebP en fallback, JPG/PNG en dernier. La balise <picture> gère la chaîne automatiquement.
<picture>
<source srcset="/img/photo.avif" type="image/avif" />
<source srcset="/img/photo.webp" type="image/webp" />
<img src="/img/photo.jpg" alt="…" />
</picture>Pour le redimensionnement dynamique, la génération en temps réel ou les budgets CPU contraints : WebP uniquement. L’encodage AVIF est trop lourd à la requête.
La décision en une phrase
Si l'image est générée une fois et servie pour toujours, utilise AVIF + fallback WebP. Si elle est générée par requête, utilise WebP uniquement.
Benchmarks réels : même source, les deux formats
10 photos représentatives compressées en qualité “visuellement sans perte” (SSIM ≥ 0,99 vs original) :
| Source (4000×3000 JPG) | JPG q90 | WebP q80 | AVIF q60 | AVIF vs JPG |
|---|---|---|---|---|
| Photo plage (ciel dégradé) | 2,4 MB | 1,3 MB | 0,7 MB | −71% |
| Portrait (tons de peau) | 1,8 MB | 0,9 MB | 0,55 MB | −69% |
| Produit sur fond blanc | 1,1 MB | 0,45 MB | 0,28 MB | −75% |
| Paysage urbain (haut détail) | 3,2 MB | 1,8 MB | 1,1 MB | −66% |
| Photographie culinaire | 2,1 MB | 1,0 MB | 0,62 MB | −70% |
| Paysage avec texture | 2,7 MB | 1,6 MB | 1,0 MB | −63% |
| Logo / illustration | 380 KB | 120 KB | 95 KB | −75% |
| Capture d’écran (UI) | 540 KB | 210 KB | 165 KB | −69% |
| Mode (haut contraste) | 1,9 MB | 0,95 MB | 0,58 MB | −69% |
| Macro / détail nature | 2,5 MB | 1,4 MB | 0,85 MB | −66% |
| Moyenne | 1,86 MB | 0,97 MB | 0,61 MB | −70% |
Pour une image typique, AVIF économise ~70% sur JPG, ~37% sur WebP. Les économies sont massives à l’échelle : 100 photos = 130 MB JPG, 60 MB WebP, 36 MB AVIF.
Vérification de la réalité du support navigateur
| Navigateur | WebP | AVIF | Part de marché (2026) |
|---|---|---|---|
| Chrome (desktop + Android) | 2014+ | Août 2020+ | 65% |
| Edge | 2018+ | 2021+ | 5% |
| Firefox | 2019+ | Oct 2021+ | 3% |
| Safari (iOS + macOS) | 2020 (14+) | Mars 2022 (16+) | 19% |
| Samsung Internet | 2019+ | 2021+ | 3% |
| Opera | 2014+ | 2020+ | 2% |
| Vieux IE / IE Mode | Jamais | Jamais | <1% |
| Support combiné | ~99% | ~94% | n/a |
L'écart de 6% AVIF
Les 6% sans AVIF sont principalement : (a) Android < 7 encore en usage dans certaines régions, (b) vieux Edge/IE en entreprise, (c) WebViews intégrés dans des apps plus anciennes. Livre toujours un fallback WebP, il les couvre tous.
Vitesse d’encodage : l’avantage WebP
La compression AVIF est plus lourde car le codec est plus complexe (dérivé HEVC). Sur une charge typique :
| Opération | WebP (libwebp) | AVIF (libaom) | Différence |
|---|---|---|---|
| Photo 4 MP → q80 | 0,8s | 4,2s | 5× plus lent |
| Photo 4 MP → q60 | 0,6s | 3,5s | 5,8× plus lent |
| Photo 12 MP → q80 | 2,1s | 12s | 5,7× plus lent |
| 100 vignettes (300×300) | 8s | 38s | 4,7× plus lent |
| Build de bibliothèque d’images entière (1000 imgs) | 14 min | 1h 12min | 5,1× plus lent |
Pour les builds de sites statiques c’est bien, encode une fois, sers pour toujours. Pour le redimensionnement dynamique (par exemple, les utilisateurs uploadent des avatars à la requête), le coût 5× est prohibitif.
Quand choisir WebP
Choisis WebP-uniquement quand
- Tu génères des images à la requête (redimensionnement dynamique)
- Le CPU/temps de build est contraint
- Tu veux un outillage plus simple (support de bibliothèque plus large)
- Ton CDN ne supporte pas encore AVIF
- Ton audience penche très-vieux-Android (régions avec vieux appareils)
Choisis AVIF + fallback WebP quand
- Site statique avec assets pré-construits
- Site lourd en photos (e-commerce, portfolio, news)
- Les coûts de bande passante comptent (factures CDN, utilisateurs mobile)
- Core Web Vitals sont critiques (le poids des images est ton goulot)
- Tu peux te permettre du CPU au build
La chaîne de fallback en pratique
L’élément HTML <picture> est la façon standard de livrer plusieurs formats. Le navigateur prend le premier format qu’il comprend.
<picture>
<source type="image/avif" srcset="/img/hero.avif" />
<source type="image/webp" srcset="/img/hero.webp" />
<img src="/img/hero.jpg" alt="Image héro" loading="lazy" />
</picture>Les frameworks modernes génèrent ça automatiquement :
| Framework | Comment |
|---|---|
| Astro | <Image src=... formats={['avif', 'webp']} /> |
| Next.js | next/image + config images.formats |
| Gatsby | gatsby-plugin-image avec formats |
| Vite | plugin vite-imagetools |
| Nuxt | @nuxt/image avec tableau format |
| Hugo | Page resources + Resize + Convert |
Ne livre pas AVIF sans WebP
Les 6% d'utilisateurs sans support AVIF ne voient pas une "image cassée", ils voient rien. La balise <picture> retombe sur le <img> si toutes les entrées <source> échouent. Inclus toujours WebP (ou JPG) comme filet de sécurité.
Cartographie du curseur de qualité
Le numéro que tu mets en q= pour AVIF ne mappe pas à JPG/WebP. Équivalents approximatifs :
| Qualité visuelle | JPG q | WebP q | AVIF q |
|---|---|---|---|
| Presque sans perte | 95 | 95 | 80 |
| Visuellement sans perte | 90 | 85 | 65 |
| Net en visualisation normale | 85 | 80 | 60 |
| Acceptable | 75 | 70 | 50 |
| Compression visible | 60 | 55 | 35 |
| Artefacts lourds | 40 | 35 | 20 |
Défaut pour le web : JPG 85, WebP 80, AVIF 60, tous produisent une sortie visuellement identique.
Conseils d’encodage pour les meilleurs résultats
- Encode toujours depuis l’original (pas depuis un JPG → ré-encodé en WebP), sinon tu cumules les pertes.
- Pour les photos, utilise AVIF q60 / WebP q80, le sweet spot.
- Pour les graphiques avec bords nets, passe à WebP sans perte ou fallback PNG. AVIF avec perte peut flouter les fines lignes.
- Ne te soucie pas d’AVIF pour les vignettes sous 100×100, la différence de taille de fichier est minuscule vs le coût d’encodage.
- Strip les métadonnées (EXIF, ICC) quand possible, économise encore 10–30 KB par image.
Et JPEG XL ?
JPEG XL (JXL) est un format plus récent que certains ont appelé “tueur d’AVIF” en 2022. En 2026 :
- Chrome a retiré le support en 2023 (décision controversée).
- Safari le supporte (depuis iOS 17).
- Firefox : derrière un flag.
Pas la peine de déployer en production encore. L’histoire du support navigateur est trop incertaine. Revisite en 2027.
Résumé
Pour 90% des sites web en 2026 :
- Le pipeline de build encode chaque image en AVIF + WebP + JPG/PNG.
- La balise
<picture>en HTML sert la bonne basée sur le navigateur. - Qualité JPG 85, WebP 80, AVIF 60 par défaut, visuellement identique.
- Saute AVIF uniquement pour les images minuscules ou les chemins de génération dynamique.
- Mesure avec Core Web Vitals avant et après, le poids des images devrait baisser de ~70%.
Tu peux convertir tes assets existants tout de suite avec JPG en WebP, PNG en WebP, ou batch-traiter via Convertir image. Tout tourne localement, pas d’upload, pas de serveur.