La refonte passe toutes les bannières en AVIF — gain Lighthouse spectaculaire. Sauf que le CRM interne du client cible encore Safari 14 sur macOS d'entreprise : un simple <img src="hero.avif"> affiche un carré gris. Le support parle de « site cassé » ; le marketing parle de « modernisation ». Les deux ont raison sur leur périmètre.
WebP et AVIF réduisent le poids sans sacrifier la qualité perçue — si la livraison reste progressive : meilleur format pour les navigateurs capables, fallback universel pour les autres. Moderniser le format d'image n'est pas une case à cocher ; c'est un contrat de livraison avec votre audience réelle.
Support navigateur et stratégie picture
L'élément <picture> reste l'approche la plus prévisible côté origin :
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="Description" width="1200" height="630">
</picture>
| Format | Support | Note |
|---|---|---|
| AVIF | Chrome, Firefox, Safari récents | Meilleur ratio compression |
| WebP | Très large | Fallback intermédiaire |
| JPEG | Universel | Fallback final |
Toujours renseigner width et height sur la balise img — cela évite le décalage de mise en page (CLS). L'attribut alt doit rester sur l'image fallback ; c'est elle que les crawlers et les lecteurs d'écran utilisent en dernier recours.
Servir uniquement AVIF, c'est optimiser pour Lighthouse en oubliant le parc navigateur réel — souvent les clients B2B à fort panier moyen.
CDN, négociation Accept et Vary
Un CDN qui négocie le format via le header Accept: image/avif,image/webp,/ simplifie le HTML — mais impose Vary: Accept et une clé de cache correcte. Sans Vary, le CDN peut servir un AVIF à un navigateur incompatible.
Sur un origin sans CDN, <picture> reste plus prévisible qu'une réécriture opaque côté serveur. Sous WordPress, les plugins ShortPixel ou Imagify génèrent les variantes — vérifiez que le fallback s'affiche dans l'aperçu admin et sur un vieux Safari.
Alignez cette stratégie avec vos headers de cache : les images négociées par Accept exigent une politique Vary cohérente entre origin et edge.
Qualité, dimensions et srcset
Servez plusieurs résolutions via srcset et sizes pour le mobile. Une qualité AVIF à 50 équivaut souvent visuellement à un JPEG à 80 — ajustez par asset, pas avec un réglage global.
Évitez l'agrandissement : redimensionnez la source, ne compressez pas un fichier 4000 px affiché en 400 px via CSS. Les logos restent en SVG — pas en AVIF.
Pour les bannières avec recadrage différent mobile/desktop, l'attribut media sur <source> permet l'art direction sans dupliquer la page entière.
Pipeline de conversion : build ou à la volée
Build statique (Sharp, Squoosh, ImageMagick en CI) convient aux assets connus : hero, icônes, visuels marketing. Générez AVIF, WebP et JPEG depuis un master PNG ou TIFF. Nommez avec hash + Cache-Control long.
Conversion à la volée (imgproxy, Cloudflare Polish, service image dédié) s'adapte aux uploads utilisateur en e-commerce ou CMS. Encodez en asynchrone — un upload ne doit pas attendre trente secondes de conversion AVIF. Mettez en cache agressivement le résultat.
Accessibilité et SEO images
L'attribut alt descriptif reste sur la balise img fallback. Pour les images décoratives, alt="" explicite. Les URLs stables et un sitemap images aident l'indexation — Google lit WebP et AVIF, mais le JPEG fallback rassure les crawlers conservateurs.
Ne supprimez pas le JPEG « parce que personne ne l'utilise » sans mesurer : analytics et logs serveur montrent souvent une queue legacy sous-estimée.
Le sommet : format moderne, audience exclue
Voici ce que le score Lighthouse ne mesure pas.
Bonnes images = négociation de format plus fallback plus dimensions — pas un seul type MIME imposé à tous.
Décider et avancer sans angle mort
Avant la prochaine refonte visuelle :
- Implémentez
<picture>avec AVIF, WebP et JPEG fallback sur les visuels hero. - Configurez
srcsetetsizespour le responsive — width/height sur chaqueimg. - Choisissez build statique ou conversion à la volée selon la source des images (marketing vs uploads CMS).
- Vérifiez Vary: Accept si le CDN négocie le format — croisez avec la politique de cache.
- Testez sur Safari 14, Edge legacy et avec JavaScript désactivé : les images hero restent-elles visibles ?
- Comparez CDN image et hébergement via l'annuaire et le comparateur.
Pour les assets statiques, enchaînez vers HTTP/2 : moins de poids par image multiplie l'effet du multiplexage.
Questions fréquentes
AVIF ou WebP en priorité ?
AVIF compresse mieux (souvent 20 à 50 % de moins que WebP) mais encode plus lentement et son support est légèrement plus récent. WebP reste un excellent compromis. Servez AVIF en première source, WebP en seconde, JPEG en fallback via <picture>.
Comment servir le bon format ?
Via <picture> avec des balises <source type="image/avif"> et <source type="image/webp">, plus un <img src="...jpg"> fallback. Alternative : CDN négociant le header Accept — avec Vary: Accept et clé de cache adaptée.
Et le SEO images ?
Conservez un alt descriptif sur l'image fallback, des URLs stables et un sitemap images. Google indexe WebP et AVIF ; le JPEG fallback rassure les crawlers les plus conservateurs.
Conversion côté build ou à la volée ?
Build pour les assets marketing connus (CI + Sharp). Conversion asynchrone à la volée pour les uploads CMS — avec cache agressif sur le résultat. Ne bloquez jamais une requête utilisateur sur un encodage AVIF lent.
Moderniser le format sans fallback, c'est accepter des carrés gris là où le business compte encore.