Optimisation des images en 2026 : AVIF, WebP, srcset et lazy loading

Servez de l’AVIF avec repli WebP, dimensionnez chaque image selon l’écran réel (pas selon le fichier d’origine), et ne mettez jamais loading="lazy" sur l’image au-dessus de la ligne de flottaison. Ces trois règles règlent la grande majorité des problèmes d’images que je rencontre en audit. Le reste, c’est du détail.

La plupart des guides s’arrêtent à « convertissez en WebP ». C’est utile, mais c’est rarement là que se perdent les secondes. Voici ce que je fais concrètement sur mes livraisons, une idée reçue que je démonte, et un calcul de dimensionnement que vous pouvez refaire vous-même avec un crayon.

AVIF, WebP, JPEG : lequel servir en 2026 ?

La réponse courte : AVIF en premier, WebP en repli, JPEG en dernier recours. Les trois, empilés dans une balise <picture>, laissent le navigateur choisir le premier format qu’il sait lire.

Le support d’AVIF n’est plus un sujet. D’après Can I Use, il tourne autour de 94 à 95 % des navigateurs dans le monde en 2026, le reliquat étant surtout de vieilles versions d’iOS et quelques navigateurs embarqués dans des applications. Pour un site de PME française dont la majorité du trafic vient de Chrome et de Safari récents, c’est suffisant pour en faire le format par défaut, avec le repli qui couvre les 5 % restants.

Côté poids, les comparatifs publiés donnent couramment AVIF à moins de la moitié du poids d’un JPEG équivalent. Je ne cite pas de chiffre universel, parce que le gain réel dépend entièrement de l’image : une photo avec beaucoup de textures compresse très bien, une capture d’écran avec du texte fin beaucoup moins.

Voici le tableau que j’utilise pour décider, projet par projet :

Type d’image	Format principal	Repli	Remarque
Photo (hero, réalisation)	AVIF	WebP	Qualité 60 à 70 suffit presque toujours
Capture d’écran avec texte	WebP (qualité 80)	PNG	AVIF pâtit parfois sur les contours nets
Logo, icône, schéma	SVG	aucun	Un logo en bitmap est une erreur de départ
Photo avec transparence	AVIF ou WebP	PNG	Évitez le PNG photo : il pèse dix fois plus
Animation courte	<video> muet MP4	aucun	Un GIF animé est le pire format possible

Ce que je ne fais pas : encoder à la main dans un outil de bureau. Sur un site avec 30 images, la prochaine mise à jour de contenu réintroduira des fichiers non optimisés. Il faut que la conversion fasse partie du build.

Mettre la conversion dans le build avec Astro

Sur mes sites Astro, c’est le module astro:assets qui s’en charge. J’importe l’image depuis src/, j’utilise le composant <Picture> avec formats={['avif', 'webp']}, et le build génère les variantes avec sharp. Plus personne n’a à penser au format : un éditeur dépose un JPEG de 4 Mo issu d’un smartphone, le site en sert une version de quelques dizaines de ko.

Le point important est que cette conversion se fait au build, une fois, et non à chaque visite. Le résultat part sur le CDN de Netlify avec un cache long. Pas de service d’images à payer, pas de latence de transformation à la volée. Pour un site vitrine, c’est la bonne architecture. Un service d’images dynamique (Cloudinary, Netlify Image CDN) devient pertinent quand les images viennent d’un back-office qui change tous les jours, typiquement un catalogue e-commerce.

Sur vitriersparis.fr, la règle que je mets en place est simple : toute photo de réalisation passe par <Picture>, avec des largeurs prédéfinies, et un script de vérification fait échouer le build si une balise <img> brute pointe vers un fichier .jpg de plus de 200 ko. C’est un garde-fou de quelques lignes, et il évite qu’un ajout de contenu maladroit ruine le travail.

Le calcul que presque personne ne fait : la bonne largeur

Le gain de format se voit tout de suite. Le gain de dimensionnement, lui, est plus gros et plus discret.

Prenons un téléphone courant avec un écran de 390 px de large en pixels CSS et un ratio de pixels de 3. Une image qui occupe toute la largeur a besoin, au maximum, de 390 × 3 = 1 170 px de large pour être nette. Sur un écran avec un ratio de 2, il en faut 780. Or j’ouvre régulièrement des sites où l’image hero fait 3 000 px de large : le téléphone télécharge près de sept fois plus de pixels que ce qu’il peut afficher (3 000 × 3 000 contre 1 170 × 1 170 pour une image carrée, soit environ 6,6).

La parade, c’est srcset et sizes. Vous proposez plusieurs largeurs (par exemple 480, 800, 1 200 et 1 600 px), vous indiquez au navigateur la place que l’image occupera dans la mise en page, et c’est lui qui choisit selon l’écran et la connexion. MDN documente ce mécanisme en détail.

L’erreur classique est d’oublier sizes. Sans cet attribut, le navigateur suppose que l’image occupe 100 % de la largeur de la fenêtre et choisit une variante trop grande si votre image est en réalité dans une colonne de 50 %. Avec le composant d’Astro, je passe sizes="(min-width: 768px) 50vw, 100vw" et le HTML généré est correct.

L’idée reçue à démonter : « il faut lazy-loader toutes les images »

C’est le conseil le plus répété, et il est faux pour une image précise : celle qui est visible au chargement.

L’attribut loading="lazy" dit au navigateur d’attendre que l’image approche de la zone visible avant de la télécharger. Pour les images situées plus bas dans la page, c’est exactement ce qu’il faut. Mais si vous l’appliquez à l’image hero, vous retardez volontairement la ressource qui détermine votre LCP. web.dev le dit sans ambiguïté dans son guide sur le lazy loading natif : ne chargez pas en différé les images susceptibles d’être dans la fenêtre au chargement, en particulier celle du LCP.

Ma règle, appliquée partout :

1. Image hero : loading="eager" (la valeur par défaut) et fetchpriority="high".
2. Images sous la ligne de flottaison : loading="lazy" et decoding="async".
3. Toujours width et height renseignés, pour que le navigateur réserve l’espace et que le CLS reste à zéro.

L’attribut fetchpriority="high" mérite une explication. Par défaut, le navigateur traite les images avec une priorité basse jusqu’à ce qu’il constate qu’elles sont visibles. Le signaler d’emblée fait gagner un temps appréciable, et web.dev détaille cette API Fetch Priority avec des mesures. Je l’ajoute sur une seule image par page : si tout est prioritaire, plus rien ne l’est.

Sur urgenceserrures.fr, où la cible est quelqu’un devant sa porte avec un téléphone à 15 % de batterie, cette combinaison (AVIF, bonne largeur, fetchpriority) fait la différence entre une page qui apparaît pendant que l’utilisateur lève le pouce vers son écran, et une page qu’il quitte.

Les erreurs qui annulent tout le reste

Après plusieurs dizaines d’audits depuis 2021, voici celles que je retrouve le plus souvent :

• L’image de fond en CSS. Un background-image n’est découvert qu’après le téléchargement du CSS, donc tard. Si c’est votre élément LCP, passez-le en vraie balise <img>, ou ajoutez un <link rel="preload" as="image">.
• Le slider d’accueil. Quatre images en pleine largeur, dont une seule visible. Gardez la première, supprimez le reste, ou ne chargez les suivantes qu’à la demande.
• Les plugins de « compression automatique » sur WordPress. Ils aident, mais ils recompressent des fichiers déjà trop grands et ne règlent pas le dimensionnement. Si le thème sort une image de 2 400 px dans une colonne de 400 px, le plugin produit simplement une image de 2 400 px un peu plus légère.
• L’absence de width et height. Le contenu saute au chargement de l’image, et votre CLS en prend un coup.
• Les images d’origine publiées telles quelles. Un smartphone sort des JPEG de 3 à 6 Mo. Ils n’ont rien à faire sur un serveur public.

Mon budget d’images par page

Une règle de travail vaut mieux qu’un principe. Voici le budget que je fixe au démarrage d’un projet, en cohérence avec ma cible de page à moins de 500 ko :

• Image LCP : 80 ko maximum en AVIF pour la variante mobile.
• Galerie ou réalisations : 40 ko maximum par vignette.
• Total des images au premier chargement : 250 ko, soit la moitié du budget de la page.

Ce sont des plafonds de conception, pas des mesures tirées d’un site en particulier. Leur intérêt est de rendre la décision mécanique : si une photo dépasse, on réduit la qualité ou la largeur, on ne négocie pas.

Pour la mesure, je teste depuis Marseille sur une connexion mobile bridée, parce que les visiteurs d’un artisan en PACA ne sont pas tous sur la fibre. Je regarde l’onglet Réseau de Chrome filtré sur « Img », puis PageSpeed Insights pour les données de terrain. Si le LCP de votre site est dans le rouge malgré tout cela, relisez mon guide sur les Core Web Vitals mobile : le problème est peut-être ailleurs, côté serveur ou polices.

Faut-il le faire sur un site WordPress existant ?

Oui, mais avec des attentes réalistes. WordPress génère des tailles d’images intermédiaires et sait servir du WebP et de l’AVIF nativement dans les versions récentes. Le vrai travail est de vérifier que le thème utilise bien ces tailles et déclare un sizes cohérent. Dans ma pratique, c’est le thème qui sabote. J’ai détaillé les autres pistes dans mon article sur WordPress lent.

Résumé

Servez l’AVIF avec un repli WebP, générez ces variantes au build plutôt qu’à la main, et dimensionnez chaque image pour l’écran réel : un téléphone de 390 px à ratio 3 n’a besoin que de 1 170 px, pas de 3 000. Réservez loading="lazy" aux images hors écran, et donnez fetchpriority="high" à l’image LCP, une seule par page.

Ce qu’il faut retenir

• AVIF couvre environ 94 à 95 % des navigateurs en 2026 : utilisez-le par défaut, avec WebP en repli.
• Le dimensionnement pèse plus que le format : calculez la largeur utile en pixels CSS × ratio de pixels.
• Renseignez toujours sizes avec srcset, sinon le navigateur surestime la largeur nécessaire.
• Ne mettez jamais loading="lazy" sur l’image au-dessus de la ligne de flottaison.
• Ajoutez fetchpriority="high" sur l’image LCP, et uniquement sur elle.
• Posez width et height sur chaque image pour garder un CLS à zéro.
• Fixez un budget (par exemple 80 ko pour l’image LCP mobile) et faites échouer le build quand il est dépassé.