Images WebP, AVIF, JPEG : quel format choisir et pourquoi ça change tout
Les images représentent 50 % du poids moyen d'une page web. Bien choisir entre JPEG, WebP et AVIF peut diviser votre poids par 4. Guide pratique 2026.
Selon le HTTPArchive Web Almanac 2024, les images représentent en moyenne 47 % du poids d’une page web sur mobile. C’est le levier d’optimisation n°1 pour la performance — et donc pour le SEO et la conversion.
En 2026, trois formats dominent : JPEG (legacy), WebP (transition) et AVIF (moderne). Voici comment choisir.
Comparatif rapide
| Format | Compression | Support | Poids | Cas d’usage |
|---|---|---|---|---|
| JPEG | Lossy classique | 100 % | Référence | Fallback, compatibilité maximale |
| PNG | Lossless | 100 % | Très lourd | Logos, graphiques avec transparence |
| WebP | Lossy/Lossless | 97 % (depuis 2020) | -25 à -35 % vs JPEG | Standard de fait actuel |
| AVIF | Lossy/Lossless | 95 % (depuis 2024) | -50 à -70 % vs JPEG | Nouveau standard performance |
| SVG | Vectoriel | 100 % | Très léger | Logos, icônes, illustrations |
Source de support : Can I Use.
Le format pour quel usage
Photos (paysages, portraits, produits e-commerce)
→ AVIF en priorité, WebP en fallback, JPEG en dernier recours.
Exemple concret : une photo produit de 1 920 × 1 280 px
- JPEG qualité 80 : ~280 KB
- WebP qualité 80 : ~180 KB (-36 %)
- AVIF qualité 60 : ~95 KB (-66 %)
À qualité visuelle équivalente, AVIF économise 60-70 % du poids.
Logos, icônes, illustrations vectorielles
→ SVG systématiquement.
Le SVG est :
- Vectoriel (parfait à toute taille)
- Très léger (souvent < 5 KB)
- Stylisable en CSS (couleurs dynamiques, animations)
- Indexable par Google (texte alt et description accessibles)
Graphiques avec transparence et peu de couleurs
→ PNG-8 (256 couleurs max) si compatibilité requise, WebP lossless sinon.
Captures d’écran d’interfaces
→ WebP lossless (compression sans perte) ou PNG. Évitez JPEG qui crée des artefacts sur les bords nets.
Comment générer ces formats
Outils en ligne (ponctuel)
- Squoosh (Google) — interface graphique excellente, supporte AVIF + WebP
- TinyPNG — compression PNG/JPEG/WebP, freemium
Outils en ligne de commande
- Sharp (Node.js) — la référence, ultra-rapide via libvips
- ImageMagick — couteau suisse historique
- libavif — encodeur AVIF officiel
Intégrations frameworks
- Astro : composant
<Image />avec optimisation automatique en AVIF/WebP - Next.js : composant
<Image />similaire, optimisation au build - Nuxt : module
@nuxt/imageavec providers (Cloudinary, ImgIX, etc.)
→ C’est la méthode recommandée en 2026 : laisser le framework optimiser au build pour générer plusieurs formats et tailles automatiquement.
La balise <picture> pour le multi-format
Pour servir AVIF aux navigateurs compatibles et JPEG en fallback :
<picture>
<source srcset="photo.avif" type="image/avif">
<source srcset="photo.webp" type="image/webp">
<img src="photo.jpg" alt="Description précise" width="1920" height="1280" loading="lazy" decoding="async">
</picture>Le navigateur prend automatiquement la version la plus performante qu’il supporte. Pas besoin de polyfill.
Les attributs critiques pour les performances
Sur chaque <img> :
loading="lazy"
Charge l’image uniquement quand elle entre dans le viewport. Économise jusqu’à 50 % de bande passante sur les pages longues.
⚠️ Sauf pour la première image (souvent le LCP) : utilisez loading="eager".
decoding="async"
Permet au navigateur de décoder l’image en parallèle du rendu HTML. Améliore le LCP.
width et height
Obligatoires pour éviter les layout shifts (CLS). Spécifiez les dimensions intrinsèques de l’image, le navigateur calcule la bonne taille via CSS.
srcset et sizes
Pour servir des tailles différentes selon le viewport :
<img
src="photo-800.jpg"
srcset="photo-400.jpg 400w, photo-800.jpg 800w, photo-1600.jpg 1600w"
sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1600px"
alt="..."
>Un mobile chargera la version 400w (~50 KB), un desktop la version 1600w (~250 KB).
Combien d’optimisation est suffisant ?
Selon web.dev, une image au-dessus du fold doit charger en < 1,2 seconde pour ne pas affecter le LCP.
Concrètement, sur une connexion 4G typique (~10 Mbps utiles) :
- LCP target 1,2 s = ~150 KB max pour l’image principale
- Une page avec 10 images = ~1 MB total max
Si votre page fait 5 MB d’images, elle est trop lourde.
Le facteur qualité
JPEG, WebP et AVIF ont tous un curseur qualité (1-100). Le secret est de trouver le bon équilibre :
| Format | Qualité optimale | Notes |
|---|---|---|
| JPEG | 75-85 | En dessous, artefacts visibles |
| WebP | 75-85 | Idem, plus tolérant |
| AVIF | 50-65 | AVIF compresse beaucoup plus, qualité lower OK |
Astuce : utilisez Squoosh pour comparer visuellement avant de choisir.
Outils pour mesurer
- PageSpeed Insights : rapport sur le poids et le format des images
- Chrome DevTools → Network → onglet Image : liste détaillée
- Lighthouse : suggère des optimisations spécifiques (« Use modern image formats », « Properly size images », etc.)
Cas particulier : les images dans les emails
Dans un email transactionnel, PAS d’AVIF ni de WebP. La majorité des clients mail (Outlook surtout) ne les supportent pas. Restez en JPEG / PNG, voire SVG selon le client.
Résumé du workflow optimal
- Source haute qualité : photo originale en RAW ou JPEG haute résolution
- Génération multi-format au build via Sharp ou framework natif
- Servir via
<picture>ou<img srcset>avec AVIF + WebP + JPEG fallback - Lazy loading sur tout sauf le LCP
- Width/height systématiques pour zéro CLS
- CDN pour le caching (Cloudflare, Bunny CDN)
Avec cette approche, on passe typiquement d’un site avec 2-5 MB d’images à 300-800 KB, sans aucune perte visible. Lighthouse passe de 50 à 95+ sur le critère « Properly size images ».
Sources
- HTTPArchive Web Almanac 2024 — page weight
- web.dev — guide images performance
- Can I Use — support AVIF
- Can I Use — support WebP
- Squoosh by Google
Tous nos sites livrent des images en AVIF/WebP avec fallback JPEG, automatiquement optimisées au build. Inclus dans nos sites à partir de 450 € HT.