Optimiser les images, c'est la victoire la plus rapide sur presque chaque site que je profile, parce que les images sont d'habitude l'élément le plus lourd de la page et que le hero est en général le Largest Contentful Paint qui décide de la vitesse ressentie de l'ensemble. Réglez bien la livraison et vous perdez des mégaoctets pendant que vos Core Web Vitals grimpent et que votre facture de bande passante baisse en silence, sans toucher une ligne de logique applicative. Voici comment je m'y prends en 2026. Les formats qui gagnent vraiment, comment envoyer la bonne taille à chaque écran, et comment câbler tout ça une bonne fois pour que ça arrête de régresser.
The short answer
Servez d'abord un format moderne (AVIF, puis WebP, puis un fallback JPEG via
<picture>), tendez au navigateur un srcset responsive à quatre largeurs,
lazy-loadez tout sauf le hero, compressez à la qualité la plus basse que vous ne
pouvez pas voir, et fixez width et height sur chaque balise. Les cinq leviers
se multiplient, donc une page de plusieurs mégaoctets tombe couramment à quelques
centaines de kilooctets.
Les images. Sur presque tous les sites que j'ai profilés, c'est l'élément le plus lourd de la page, et le hero est en général le Largest Contentful Paint, celui qui décide de la vitesse ressentie de l'ensemble. Donc c'est là que je commence, à chaque fois. Réglez bien la livraison et vous perdez des mégaoctets sur la page pendant que vos Core Web Vitals grimpent et que votre facture de bande passante baisse en silence, sans avoir à toucher une seule ligne de logique applicative. Voici comment je m'y prends en 2026. Les formats qui gagnent vraiment. Comment envoyer la bonne taille à chaque écran, et comment câbler tout ça une bonne fois pour que ça arrête de régresser à la seconde où vous lâchez la surveillance.
Pourquoi le poids des images est la victoire à courir
Ouvrez le panneau réseau sur quasiment n'importe quel site de contenu et regardez les images dévorer le compteur d'octets. 60 à 70% de la page. À chaque fois. Et vos utilisateurs ressentent ce poids deux fois : dans le temps que met l'image principale à s'afficher (c'est le LCP, que Google veut sous les 2,5 secondes), et dans la part de leur forfait mobile que vous venez de dépenser à leur place sans leur demander. Un hero de 1,9 Mo qui aurait dû partir en AVIF de 180 Ko, ce n'est pas une erreur d'arrondi qu'on balaie d'un revers de main. Sur un téléphone milieu de gamme avec une connexion normale, c'est la différence entre une page qui paraît instantanée et une que vous regardez s'assembler, morceau par morceau, pendant que le pouce du visiteur dérive déjà vers le bouton retour.
Et voici la partie que j'aime vraiment. Le travail sur les images, c'est surtout mécanique. La perf JavaScript ? C'est du profilage, des prises de tête et du refactoring que franchement vous préféreriez éviter un mardi. Les images, c'est un pipeline que vous construisez une fois et que vous oubliez ensuite la plupart du temps. Et les cinq leviers ci-dessous s'empilent les uns sur les autres, en plus. Un format moderne sur une image bien dimensionnée, chargée en lazy, bien compressée et servie depuis un CDN peut atterrir à peut-être un dixième des octets que vous aurait coûté la version paresseuse. Un dixième. Personne n'y croit tant qu'il ne l'a pas vu se produire dans DevTools.
Choisissez d'abord le bon format
C'est le choix qui rapporte le plus. Un meilleur codec vous économise des octets à chaque niveau de qualité, pas seulement tout en haut de l'échelle où on s'y attendrait. En 2026 je n'agonise plus vraiment là-dessus. L'ordre est plutôt établi maintenant, ou suffisamment établi.
| Format | À utiliser pour | Notes |
|---|---|---|
| AVIF | Photos, images hero, tout ce qui est volumineux | La meilleure compression de loin ; plus lent à encoder. Pris en charge par tous les navigateurs actuels. |
| WebP | Photos et graphiques, fallback universel | ~30% plus petit que le JPEG, rapide à encoder, pris en charge partout où ça compte. |
| JPEG | Fallback ultime pour les clients antédiluviens | Toujours correct en qualité 75 à 82 ; utilisez MozJPEG pour 10% d'économie gratuite. |
| PNG | Logos, captures d'écran, tout ce qui exige des bords nets ou de la transparence | Ne l'utilisez jamais pour des photographies ; il est sans perte et énorme dessus. |
| SVG | Icônes, logos, diagrammes | Vectoriel, minuscule, infiniment redimensionnable. Minifiez avec SVGO et inlinez les plus critiques. |
Vous n'êtes pas obligé de couronner un seul gagnant et de jeter le reste, cela dit. L'élément <picture> remet le choix directement entre les mains du navigateur. Il attrape le meilleur format qu'il sait réellement lire, puis bascule tout seul sur le fallback sans la moindre aide de votre part :
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="..." width="1600" height="900">
</picture>Il lit de haut en bas et prend le premier type qu'il comprend, point. Les clients compatibles AVIF reçoivent de l'AVIF. Tous les autres retombent sur le WebP, et le matériel vraiment antédiluvien atterrit sur le JPEG posé dans le <img>. Un truc sur lequel je vais vous tanner jusqu'à ce que ça rentre : ne supprimez jamais ce dernier <img>, et gardez ses alt, width et height exactement là où ils sont. Cette balise, c'est le sol sur lequel tout l'édifice tient debout.
Servez une taille adaptée à l'écran
Juste derrière le mauvais format vient la mauvaise taille. Je le vois sans arrêt. Une image de 2560px balancée droit sur un téléphone de 390px, qui télécharge consciencieusement jusqu'au dernier pixel pour ensuite réduire la chose dans le navigateur de toute façon. Vous avez tout payé. Vous en avez jeté la majeure partie. Les images responsives règlent exactement ce problème. Vous tendez quelques largeurs au navigateur et vous le laissez choisir la bonne selon le viewport et le device pixel ratio :
<img
src="hero-800.jpg"
srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1600.jpg 1600w"
sizes="(max-width: 600px) 100vw, 800px"
alt="..." width="1600" height="900" loading="lazy">srcset, c'est votre liste de fichiers candidats, chacun étiqueté avec sa vraie largeur en pixels. sizes indique au navigateur la largeur à laquelle l'image va réellement s'afficher, pour qu'il puisse décider avant même que la mise en page ait lieu. N'exportez pas tout ça à la main. La vie est vraiment trop courte pour ça. Générez-les plutôt (l'automatisation arrive plus bas). Mon set par défaut, c'est 400, 800, 1200 et 1600px, ce qui couvre des téléphones jusqu'aux portables retina. Je n'ajoute un palier à 2400px que quand j'ai réellement de grands écrans à nourrir, et honnêtement la plupart des sites n'en ont juste pas.
Chargez les bonnes images au bon moment
Chaque octet que vous différez est un octet qui ne bloque pas votre premier paint. Et voici la bonne surprise : vous n'avez plus besoin d'une librairie de lazy-load pour tout ça, pas une seule. Une poignée d'attributs natifs portent toute la charge à eux seuls.
- Lazy-loadez sous la ligne de flottaison : collez
loading="lazy"sur tout ce qui n'est pas à l'écran au premier rendu. Le navigateur le laisse alors tranquille jusqu'à ce que l'utilisateur scrolle à proximité. Une victoire quasi gratuite. - Ne lazy-loadez jamais l'image LCP : le hero doit charger maintenant. Pas dans une seconde, maintenant. Laissez-le en
loading="eager"et ajoutezfetchpriority="high"pour que le navigateur l'attrape avant le reste, moins urgent. J'ai vu des gens sauter cette étape et saboter discrètement leur propre LCP sans jamais réaliser ce qu'ils avaient fait. - Préchargez le hero : pour cette unique image qui compte le plus, un
<link rel="preload" as="image">tout en haut dans le head, avec unimagesrcsetcalé sur votre set responsive, lance le téléchargement dès le parsing du HTML. Dans mes tests ça bouge le LCP, et je veux dire à chaque fois que je l'ai essayé.
L'erreur classique : quelqu'un lit « lazy-loadez vos images », l'applique à absolument tout, hero compris, puis regarde son score LCP sombrer. Il s'est optimisé à l'envers. Lazy-loadez le reste de la page, d'accord. Mais l'unique image que les gens voient en premier ? Donnez-lui la priorité qu'elle mérite.
Compressez sans perte visible
Format et taille réglés, la qualité est le dernier bouton qu'il reste à tourner. Vous cherchez la qualité la plus basse à laquelle vous ne repérez toujours pas la différence à distance normale de lecture, et ça tombe autour de la qualité 75 à 82 pour le WebP et le JPEG. Pour l'AVIF c'est plus bas, quelque part autour de 50 à 60, parce que son échelle mord plus fort que le chiffre ne le laisse paraître. Ne lisez pas le 55 de l'AVIF comme le 55 du JPEG. Ce ne sont absolument pas les mêmes bêtes. Voici les outils gratuits que je garde réellement sous la main :
- Squoosh (squoosh.app) pour quand je veux juste juger une image à l'œil directement dans le navigateur, en regardant la taille bouger en direct pendant que je tire le curseur.
- sharp, la librairie Node qui se trouve sous la plupart des pipelines de build, dès que j'en traite un paquet en batch.
- cwebp et avifenc en ligne de commande quand je scripte la chose.
- ImageMagick ou MozJPEG pour ces jours où quelque chose me ramène vers le JPEG contre mon gré.
# Batch a folder of photos to WebP and AVIF
for f in *.jpg; do
cwebp -q 80 "$f" -o "${f%.jpg}.webp"
avifenc --min 24 --max 30 -a end-usage=q "$f" "${f%.jpg}.avif"
doneEt tant que vous y êtes déjà, virez les métadonnées. L'EXIF, les profils colorimétriques dont vous ne vous servirez pas une seule fois, la miniature embarquée qui traîne. Ce déchet ajoute discrètement des dizaines de kilooctets par image. La plupart des encodeurs les suppriment par défaut de nos jours, mais je ne pars jamais du principe qu'ils l'ont fait. Vérifiez avec identify -verbose ou un inspecteur en ligne avant de leur faire confiance.
Automatisez-le, au build ou sur le CDN
L'optimisation manuelle finit toujours par pourrir. Toujours. Vous faites le travail, les scores ont l'air superbes, et trois semaines plus tard quelqu'un dépose une photo de téléphone de 4 Mo directement dans le CMS et vos chiffres glissent sans le moindre bruit. Donc j'automatise. Il y a deux approches sur lesquelles je m'appuie et qui tiennent vraiment la route sur le long terme.
Au build
Si vos images vivent dans le dépôt, transformez-les au moment du build. Les frameworks ont rendu ça presque trop facile maintenant. Next.js a next/image, Astro a son <Image>, et Nuxt Image et Eleventy Image complètent le tableau. Donnez à n'importe lequel d'entre eux une seule source et ils vous recrachent des variantes responsives en AVIF et WebP, plus le markup pour câbler le tout. Chacun d'eux ne fait qu'appeler sharp en dessous, donc si vous n'êtes pas du tout sur un framework, écrire le vôtre est un court script plutôt qu'un gros projet.
CDN à la volée
En revanche, quand ce sont vos utilisateurs qui uploadent, un CDN transformant est la réponse la plus propre, et de loin. Cloudflare Images, Cloudinary, imgix, Fastly Image Optimizer et tous les autres redimensionnent et réencodent à la volée, lisent l'en-tête Accept du navigateur pour choisir le meilleur format, puis mettent en cache ce qu'ils renvoient. Vous gardez un seul original de haute qualité et demandez simplement ?width=800&format=auto quand vous avez besoin d'une variante. Ça pousse le travail bien loin de vos propres serveurs. Et voici la partie que je préfère. Quand le prochain format débarque, vous l'obtenez gratuitement, sans toucher à quoi que ce soit.
Protégez la stabilité de la mise en page tant que vous y êtes
Tant que vous avez les images ouvertes de toute façon, c'est le moment de tuer le Cumulative Layout Shift, le troisième Core Web Vital et celui qui agace discrètement tous ceux qui ont déjà utilisé le web. Mettez des width et height explicites sur chaque <img> (ou un aspect-ratio en CSS) pour que le navigateur réserve la bonne case avant même qu'un seul octet du fichier n'arrive. Sautez l'étape et la page se remet en page à mesure que chaque image charge. Le contenu se décale vers le bas. Votre lecteur tape le mauvais lien parce que le paragraphe qu'il visait vient de sauter sous son pouce. Deux attributs. Voilà tout le correctif, et c'est à peu près la victoire CLS la plus facile qui existe.
Mesurez, puis continuez de mesurer
Prouvez que le travail a payé. Puis montez la garde pour que ça ne se défasse pas discrètement dans votre dos. Je lance Lighthouse (Chrome DevTools, ou npx lighthouse) pour un score de labo rapide. Quand je veux la pellicule montrant l'image exacte où le LCP s'affiche, je sors WebPageTest. Et pour ce que vivent réellement les vrais visiteurs, il y a le Chrome User Experience Report ou la Search Console, parce que les chiffres de labo et les chiffres de terrain ne racontent pas toujours la même histoire. Visez un LCP sous 2,5 secondes et un CLS sous 0,1. Lighthouse va même nommer les images précises qui sont surdimensionnées ou dans le mauvais format, donc il fait office de liste de tâches plutôt que d'un simple tableau d'affichage. Et tant que vous y êtes, câblez un budget dans la CI. Je préfère de loin qu'un upload surdimensionné fasse échouer le build plutôt qu'il se faufile en production pour réapparaître des semaines plus tard dans les données de terrain.
La stack que je sors en 2026 : AVIF avec un fallback WebP et JPEG via <picture>, un srcset responsive à quatre largeurs, loading="lazy" sur tout sauf le hero, le hero lui-même préchargé avec fetchpriority="high", le tout généré par votre framework ou un CDN transformant, et width et height fixés sur chaque balise. Faites ça et des pages de plusieurs mégaoctets tombent à quelques centaines de kilooctets. Je l'ai vu atterrir comme ça bien plus souvent qu'à son tour.
Sources et pour aller plus loin
Questions fréquentes
Faut-il utiliser AVIF ou WebP en 2026 ?
Les deux. Mettez l'AVIF en premier. Il compresse nettement mieux, à peu près 50% sous le JPEG contre 30% pour le WebP, et tous les navigateurs actuels le lisent maintenant. Donc je sers l'AVIF via un élément picture avec une source WebP planquée derrière et un JPEG dans le img, et chaque navigateur attrape juste le meilleur qu'il sait gérer. Le WebP gagne sa place comme option universelle du milieu. Et honnêtement, en partie parce qu'il encode tellement plus vite que l'AVIF, ce qui compte plus que vous ne l'imaginez la première fois que vous restez planté à regarder un gros batch AVIF avancer au ralenti.
Quel est le meilleur format d'image pour la vitesse d'un site ?
Pour les photos, l'AVIF vous donne les fichiers les plus petits à qualité égale, avec le WebP un cran derrière et le JPEG qui ferme la marche. Logos, icônes et diagrammes ? Optez pour le SVG. Il est minuscule et se redimensionne parfaitement à n'importe quelle taille. Gardez le PNG pour la poignée d'images qui ont réellement besoin de bords sans perte ou de transparence, et de grâce, n'allez pas y coller une photo. J'ai vu une photo en PNG faire dix fois la taille du même cliché dans un format moderne avec perte.
Comment optimiser des images sans perdre en qualité ?
Convertissez vers un format moderne (AVIF ou WebP). Puis baissez la qualité jusqu'au point le plus bas où vous ne repérez toujours pas de différence à distance normale de lecture, ce qui veut dire en général 75 à 82 pour le WebP et le JPEG, ou quelque part autour de 50 à 60 pour l'AVIF. Ensuite, servez une taille qui colle à l'écran plutôt que de réduire un géant dans le navigateur, et virez les métadonnées dont vous n'avez pas besoin. Squoosh est celui que je garde ouvert pour ça. Il met la taille et un diff visuel juste l'un à côté de l'autre, donc vous trouvez le seuil à l'œil en une dizaine de secondes.
Le lazy loading améliore-t-il les performances ?
Pour les images sous la ligne de flottaison, oui. loading=lazy les retient jusqu'à ce que l'utilisateur scrolle à proximité, ce qui libère de la bande passante pour ce qui doit s'afficher en premier. Mais ne lazy-loadez pas votre image Largest Contentful Paint, le hero que les gens voient à l'instant où la page s'ouvre, parce que le différer ralentit la métrique précise que vous vous échinez tant à gagner. C'est le piège que je vois le plus souvent, et de loin. Lazy-loadez tout le reste, puis donnez au hero sa priorité avec fetchpriority=high et un preload.
De combien l'optimisation des images va-t-elle accélérer mon site ?
Les images représentent en général 60 à 70% du poids de votre page, donc il y a beaucoup à prendre sur la table. Empilez un format moderne, le bon dimensionnement, la compression et le lazy loading les uns sur les autres et vous raboterez couramment 70 à 90% de vos octets d'image. Sur des pages chargées en images, c'est assez pour avancer le Largest Contentful Paint d'une seconde pleine ou plus sur mobile. Ce que vous gagnez réellement dépend bien sûr de l'état des choses au point de départ. Mais d'après mon expérience, c'est la plus grosse victoire de vitesse qui soit, juste là, à attendre que quelqu'un la réclame.