Formats d'images web : lequel choisir pour un site rapide ?

En bref
WebP et AVIF réduisent le poids des fichiers de 25 à 50 % par rapport au JPEG à qualité visuelle équivalente. Pour les photos et images complexes, utilise WebP comme standard (support navigateur 90 %+) avec AVIF comme amélioration progressive. Le PNG reste essentiel pour les graphiques avec transparence, tandis que le GIF doit être remplacé par des formats modernes dans presque tous les cas.
- WebP réduit le poids des photos de 25-35 % vs JPEG sans perte de qualité visible
- AVIF compresse encore mieux mais Safari n'a ajouté le support complet qu'en 2023
- PNG reste requis pour la transparence, mais les plateformes modernes servent du WebP avec canal alpha
- Le choix du format impacte les Core Web Vitals — gains de 0,5-1,5 s sur le LCP sont fréquents
Tu as probablement entendu que les images ralentissent les sites web. Tu as peut-être même lancé un test PageSpeed Insights et vu la recommandation de « diffuser les images dans des formats nouvelle génération ». Mais quand tu regardes ta bibliothèque d'images, des centaines de JPEG, quelques PNG, peut-être un ou deux GIF, le conseil reste abstrait. Quel format fait réellement une différence ? Et plus important, lequel tu utilises où ?
La réponse n'est pas « convertis tout en WebP et c'est réglé ». Différentes images servent différents objectifs. Une photo produit avec fond transparent a des besoins différents d'une image héros, qui a des besoins différents d'un logo. Le format qui fonctionne pour l'une va gonfler le poids du fichier ou casser le rendu pour l'autre.
Cet article passe en revue les cinq formats qui comptent vraiment : WebP, AVIF, JPEG, PNG et GIF. Tu repars avec un cadre de décision fondé sur l'endroit où l'image apparaît sur ton site et sur ce qu'elle doit faire. Pas de jargon empilé, pas de « ça dépend » sans réponse claire.
Pourquoi tes images ralentissent ton site plus que tu ne le crois ?
Les images restent le type de ressource le plus lourd d'une page d'accueil : environ 1 054 Ko sur la page bureau médiane, pour un poids total médian de 2 652 Ko, soit autour de 40 % selon le Web Almanac 2024 (HTTP Archive). Une seule image héros JPEG non compressée peut peser 2-3 Mo. Sur une connexion 4G, ça seul peut prendre 1,5-2 secondes à charger. Google mesure le Largest Contentful Paint (LCP), le temps que prend le plus gros élément visible à s'afficher, comme métrique Core Web Vitals. Si cet élément est une image lourde, tu pars dans le rouge avant même que le reste de la page ne charge.
Le problème n'est pas juste la taille. C'est aussi l'inefficacité du format. JPEG a été conçu en 1992. Il compresse correctement les photos, mais il gaspille beaucoup d'espace comparé aux codecs modernes. Un JPEG de 500 Ko descend généralement autour de 330-375 Ko en WebP sans différence de qualité visible. Ces kilo-octets économisés peuvent faire la différence entre un LCP de 2,8 secondes (« à améliorer ») et de 1,8 seconde, sous le seuil de 2,5 secondes que Google considère comme bon.
La plupart des propriétaires de sites téléversent les images directement depuis leur appareil photo ou designer sans y penser deux fois. Les plateformes comme Webflow et Shopify gèrent une certaine optimisation automatiquement, mais elles ne peuvent pas compenser un fichier source fondamentalement inefficace. Si tu téléverses un PNG de 5 Mo quand un WebP de 200 Ko ferait le même travail, aucun CDN ne te sauve.
AVIF, WebP, JPEG, PNG, GIF : c'est quoi la vraie différence qui compte ?
JPEG est la référence. C'est le standard web pour les photos depuis les années 1990. Il compresse bien, il est reconnu par tous les navigateurs, et sa dégradation reste prévisible : tu peux monter la compression jusqu'à voir des artefacts, puis reculer d'un cran. La faiblesse : il ne supporte pas la transparence, et l'algorithme de compression est dépassé comparé aux formats plus récents.
PNG a été conçu pour la compression sans perte et la transparence. C'est le choix par défaut pour les logos, icônes, captures d'écran, et tout graphique avec contours nets ou texte. Le compromis : les tailles de fichier sont significativement plus grosses que JPEG pour le contenu photographique. Un JPEG de 200 Ko peut facilement devenir un PNG de 1,2 Mo si tu le convertis sans changer le type de contenu.
WebP est la réponse de Google au JPEG et PNG. Selon la documentation de Google, il compresse les photos 25-34 % plus petit que JPEG à qualité équivalente (indice SSIM), et il supporte la transparence comme PNG. Aujourd'hui, WebP est reconnu par plus de 96 % des navigateurs utilisés dans le monde, d'après Can I use. Le seul retardataire était Safari, qui a ajouté le support complet dans macOS Big Sur et iOS 14. Pour la plupart des cas d'usage, WebP est maintenant le défaut pratique.
AVIF est le format le plus récent de la comparaison. Il s'appuie sur le codec vidéo AV1 et produit des fichiers sensiblement plus légers : en déployant l'AVIF, le CDN Imgix a rapporté environ 35 % d'économies de poids par rapport au WebP et 60 % par rapport au JPEG, des chiffres relayés par web.dev. Le hic : le support navigateur était incohérent jusqu'à ce que Safari ajoute le support complet fin 2023. AVIF peut aujourd'hui être utilisé sans risque avec un repli en WebP, mais il n'est pas encore le format principal de la plupart des plateformes. Shopify ne génère pas automatiquement de variantes AVIF. Webflow le fait, mais seulement si tu téléverses la source dans un format compatible.
GIF est fonctionnellement obsolète pour la plupart des usages web. Il a été conçu pour les animations simples et les graphiques bas en couleurs, mais les formats vidéo modernes (MP4, WebM) compressent le contenu animé beaucoup plus efficacement : dans l'exemple de web.dev, un GIF de 3,7 Mo tombe à 551 Ko en MP4 et à 341 Ko en WebM, soit 85 à 91 % de moins. Si tu utilises GIF pour autre chose qu'une minuscule icône ou un meme, tu laisses des gains de performance massifs sur la table. Remplace les GIF animés par de courts MP4 en boucle et les GIF statiques par PNG ou WebP.
Quel format choisir selon l'emplacement sur ton site ?
Images héros et grandes photos : WebP, avec AVIF comme amélioration progressive si ta plateforme le supporte. Ce sont les images qui dominent ton score LCP. Une image héros 1920x1080 en JPEG peut peser 800 Ko. La même image en WebP pèsera 250-300 Ko. C'est une amélioration de 0,8-1,2 seconde en temps de chargement sur une connexion mobile typique. Si tu es sur Webflow ou Shopify, téléverse un JPEG haute qualité et laisse la plateforme générer les variantes WebP automatiquement. Si tu es sur WordPress, utilise un plugin comme ShortPixel ou Imagify pour gérer la conversion et la logique de fallback.
Photos produits avec transparence : WebP avec canal alpha. Le PNG était longtemps la seule option, mais le WebP gère aussi bien la transparence et produit des fichiers 26 % plus légers en mode sans perte, et jusqu'à trois fois plus légers en mode avec perte. Shopify et la plupart des plateformes e-commerce modernes servent du WebP par défaut pour les images produits. Si tu exportes manuellement depuis Photoshop ou Figma, exporte en PNG d'abord, puis passe-le dans un convertisseur comme Squoosh pour générer une version WebP. Garde le PNG comme fallback pour les navigateurs plus anciens, mais sers le WebP à tout le monde d'autre.
Logos et icônes : SVG si le graphique est vectoriel, PNG s'il est rastérisé. SVG (Scalable Vector Graphics) est un format texte qui s'étire infiniment sans perte de qualité et pèse typiquement moins de 5 Ko. C'est idéal pour les logos, icônes et illustrations simples. Si ton logo a été conçu dans Illustrator ou Figma, exporte-le en SVG. Si c'est une image raster (photographiée ou fortement texturée), utilise PNG. WebP fonctionne pour les logos aussi, mais la différence de taille de fichier est négligeable aux petites dimensions, et PNG a un meilleur support d'outillage pour les designers.
Captures d'écran et maquettes d'interface : PNG pour la netteté, WebP si le poids du fichier est une préoccupation. Les captures d'écran contiennent beaucoup de texte et contours nets, que PNG gère mieux que JPEG. Mais une capture plein écran peut encore peser 600-800 Ko en PNG. La passer dans un convertisseur WebP coupera ça à 200-300 Ko sans flouter le texte. Si tu intègres beaucoup de captures d'écran (documentation, études de cas, tutoriels), WebP vaut l'effort de conversion.
Images de fond et textures : WebP ou AVIF, fortement compressé. Les images de fond sont souvent décoratives et n'ont pas besoin du même seuil de qualité que le contenu de premier plan. Tu peux pousser la compression WebP à 70-80 % de qualité (vs les typiques 85-90 % pour les photos) et la plupart des utilisateurs ne remarqueront pas la différence. Si l'image de fond est purement esthétique (gradient subtil, texture légère), considère la remplacer par des gradients CSS ou des motifs SVG à la place, zéro requête HTTP, zéro taille de fichier.
Faut-il toujours compresser une image avant de la mettre en ligne ?
Oui, mais le type de compression compte. Il y en a deux sortes : avec perte et sans perte. La compression avec perte (JPEG, WebP, AVIF) jette des données pour réduire la taille du fichier. Tu contrôles combien de données sont jetées via le curseur de qualité. La compression sans perte (PNG, GIF) réarrange les données sans rien jeter. Le fichier devient plus petit, mais l'image est identique pixel par pixel à l'original.
Pour les photos, utilise la compression avec perte. Un JPEG ou WebP à 85 % de qualité est visuellement indiscernable de 100 % de qualité mais pèse 40-50 % moins, selon les mesures d'Addy Osmani dans Essential Image Optimization. Les photographes et designers exportent souvent à 100 % de qualité par défaut, ce qui est excessif pour l'usage web. L'œil humain ne peut pas percevoir la différence sur un écran, surtout sur mobile. La plupart des plateformes modernes (Webflow, Shopify, Squarespace) appliquent une compression avec perte automatiquement quand tu téléverses, mais si tu téléverses un fichier source de 5 Mo, la plateforme doit travailler plus fort et le résultat est encore plus gros que si tu l'avais pré-compressé.
Pour les graphiques avec texte ou contours nets, utilise la compression sans perte. PNG supporte la compression sans perte : ImageOptim s'appuie par défaut sur des optimiseurs sans perte, alors que TinyPNG utilise une compression avec perte (la « quantification » fusionne les couleurs voisines) pour une réduction moyenne de 75 % de la taille des fichiers, les pixels, eux, sont bel et bien modifiés. C'est particulièrement important pour les captures d'écran, logos et diagrammes où toute perte de qualité rend le texte plus difficile à lire.
Une erreur courante : compresser une image plusieurs fois. Si tu exportes un JPEG à 80 % de qualité, puis le téléverses sur une plateforme qui le compresse à nouveau à 75 %, tu composes la perte de qualité. La deuxième passe de compression amplifie les artefacts de la première. Compresse toujours une fois, depuis la source la plus haute qualité que tu as, et évite de recompresser des images déjà compressées.
Quels outils gratuits permettent d'optimiser ses images sans Photoshop ?
Squoosh est le compresseur d'images à code ouvert de Google. Il fonctionne entièrement dans ton navigateur : tes images ne quittent jamais ta machine. Tu glisses une image dedans, choisis un format (WebP, AVIF, JPEG, PNG), ajustes le curseur de qualité, et compares l'avant/après côte à côte. C'est la façon la plus rapide de tester différents réglages de compression et voir exactement ce que tu échanges. La seule limitation : c'est une image à la fois. Si tu dois traiter 50 photos produits, tu voudras un outil batch.
ImageOptim (Mac seulement) est une appli glisser-déposer qui gère la compression sans perte pour PNG, JPEG et GIF. C'est rapide, c'est local, et ça s'intègre au menu clic-droit de macOS. Tu peux déposer un dossier complet d'images et ça les compressera toutes sans changer le format de fichier. Ça ne convertira pas JPEG en WebP, ça rend juste tes fichiers existants plus petits.
XnConvert (Windows, Mac, Linux) est un processeur d'images batch qui gère la conversion de format, le redimensionnement et la compression. C'est plus complexe que Squoosh ou ImageOptim, mais c'est la meilleure option gratuite si tu dois convertir 200 images de PNG à WebP en une passe. L'interface est datée mais fonctionnelle. Tu configures un pipeline de traitement une fois (format d'entrée, format de sortie, réglages de qualité), puis tu y glisses des dossiers d'images.
TinyPNG (web) compresse les fichiers PNG et JPEG en utilisant des techniques avec perte qui préservent la qualité perçue. Tu téléverses jusqu'à 20 images à la fois (5 Mo chacune), et il retourne des versions compressées. C'est commode pour de petits batches, mais la limite de 20 images le rend impraticable pour de gros projets. La compression est bonne, une réduction de taille de fichier substantielle avec perte de qualité visible minimale, mais tu téléverses des fichiers sur un serveur tiers, ce qui peut poser problème si tu manipules des visuels de clients ou du contenu confidentiel.
Si tu es sur WordPress, des plugins comme ShortPixel, Imagify ou Smush gèrent la compression et conversion de format automatiquement au téléversement. Ils généreront des variantes WebP, les serviront aux navigateurs modernes, et feront un fallback sur JPEG/PNG pour les plus anciens. Les forfaits gratuits plafonnent habituellement à 100-500 images par mois (100 crédits gratuits par mois chez ShortPixel, 500 compressions gratuites par mois chez TinyPNG) ; les forfaits payants restent sous 10 $ par mois pour la plupart des besoins d'une PME.
Comment Webflow et Shopify gèrent-ils les formats d'images automatiquement ?
Webflow auto-génère des variantes WebP et AVIF pour chaque image que tu téléverses. Quand un visiteur charge ton site, le CDN de Webflow détecte son navigateur et sert le format le plus efficace qu'il supporte. Les navigateurs modernes (Chrome, Edge, Firefox, Safari 14+) reçoivent du WebP. Les navigateurs qui supportent AVIF (Chrome 90+, Firefox 93+, Safari 16+) reçoivent AVIF. Les navigateurs plus anciens reçoivent le JPEG ou PNG original. Tu ne configures pas ça, ça arrive automatiquement comme partie du pipeline d'hébergement Webflow.
Webflow génère aussi des variantes responsive à multiples tailles (typiquement 500px, 800px, 1080px, 1600px et 2000px de large) et utilise l'attribut srcset pour servir la bonne taille basée sur la résolution d'écran du visiteur. Ça veut dire qu'un visiteur mobile sur un écran de 375px de large reçoit une image de 500px, pas la version complète de 2000px. Combiné avec l'optimisation de format, ça peut réduire la charge d'images de 70-90 % sur les plus petits écrans, selon les cas documentés par CSS-Tricks.
Shopify génère des variantes WebP automatiquement pour les images produits, collections et toute image téléversée via l'admin. Début 2026, Shopify ne génère pas de variantes AVIF, ils utilisent WebP par défaut pour les navigateurs modernes et JPEG en fallback. C'est un choix délibéré : WebP a un support quasi-universel et les gains de compression incrémentaux d'AVIF ne justifient pas le coût de traitement CDN additionnel à l'échelle de Shopify. Pour la plupart des boutiques, c'est correct. La différence de performance entre WebP et AVIF est plutôt de l'ordre de 25-30 % de poids de fichier, un test à qualité visuelle égale (DSSIM) mesure une réduction médiane de 31,5 % pour le WebP contre 50,3 % pour l'AVIF, face aux mêmes JPEG de référence, ce qui compte souvent moins que d'autres leviers d'optimisation (lazy loading, dimensions d'images, latence CDN).
Shopify recadre et redimensionne aussi automatiquement les images basé sur les réglages de thème. Si ton image produit fait 3000x3000 pixels mais que le thème l'affiche à 600x600, Shopify sert une variante de 600px. Ça fonctionne bien pour les cas d'usage standard mais peut causer des problèmes si tu fais du travail front-end custom et as besoin de contrôle précis sur les dimensions d'images. Dans ces cas, tu voudras téléverser des images pré-dimensionnées ou utiliser les URLs de transformation d'image de Shopify pour demander des tailles spécifiques à la volée.
Les deux plateformes retirent les métadonnées EXIF (info de caméra, coordonnées GPS, timestamps) des images téléversées. C'est bon pour la vie privée et la taille de fichier, les données EXIF alourdissent le fichier sans aucun bénéfice visuel à l'affichage, mais ça veut dire que tu perds ces données si tu en as besoin plus tard. Si tu es photographe ou tu dois préserver les métadonnées pour des raisons de licence, garde les fichiers originaux haute résolution archivés hors plateforme.
Quand l'optimisation d'images ne suffit plus, qu'est-ce qui vient ensuite ?
Le format et la compression d'images sont fondamentaux, mais ce ne sont pas les seuls leviers. Une fois que tu as converti en WebP, compressé à 80-85 % de qualité, et confirmé que ta plateforme sert des variantes responsive, le prochain goulot est habituellement le lazy loading. Le lazy loading diffère le téléchargement des images sous la ligne de flottaison jusqu'à ce que l'utilisateur scrolle près d'elles. Sur les pages longues avec beaucoup d'images, les tests de web.dev montrent que le lazy loading retranche de 50 à 70 % des octets d'images chargés au départ. Webflow et Shopify activent le lazy loading par défaut pour la plupart des images, mais si tu es sur une plateforme custom, tu devras l'implémenter toi-même en utilisant l'attribut loading="lazy" ou une bibliothèque JavaScript comme lazysizes.
Le prochain niveau est un CDN avec optimisation d'images adaptative. Des services comme Cloudflare Images, Imgix ou Cloudinary se placent entre ton site et le visiteur et prennent des décisions en temps réel sur le format, la taille et la compression basées sur le type d'appareil, le navigateur et les conditions réseau. Un visiteur sur une connexion 3G lente reçoit une image plus agressivement compressée que quelqu'un sur fibre gigabit. C'est excessif pour la plupart des petits sites, mais si tu sers des millions d'images par mois ou tu as une audience mondiale sur des vitesses de connexion très variées, c'est la façon la plus efficace d'extraire les derniers 10-20 % de performance.
Au-delà des images, le prochain goulot est habituellement le JavaScript. Un site peut avoir des images parfaitement optimisées et encore sembler lent si 500 Ko de JavaScript bloque le thread principal pendant 2-3 secondes. L'optimisation d'images te rapproche beaucoup d'un bon score LCP. Mais pour respecter les seuils de réactivité au clic (INP) et de blocage du navigateur (TBT), tu devras auditer tes scripts. C'est un autre article, mais le principe est le même : mesure ce qui te ralentit, priorise les changements à plus gros impact, et itère.
Une dernière chose : n'optimise pas prématurément. Si ton site a 10 pages et 50 images, les convertir manuellement en WebP dans Squoosh est correct. Si tu as 500 pages et 2 000 images, tu as besoin d'une approche systématique, soit une plateforme qui le gère automatiquement (Webflow, Shopify) soit un pipeline de build qui convertit les images comme partie du déploiement. L'objectif est de rendre l'optimisation automatique pour qu'elle suive la croissance de ton contenu. Les optimisations ponctuelles ne tiennent pas.
FAQ
Oui, si ta plateforme gère les fallbacks automatiques pour les navigateurs plus anciens. WebP réduit le poids de 25-35 % par rapport au JPEG à qualité perçue égale, ce qui améliore directement ton score Largest Contentful Paint (LCP). Webflow et Shopify gèrent ça automatiquement — ils servent du WebP aux navigateurs modernes et du JPEG aux plus anciens. Si tu es sur WordPress ou une plateforme custom, assure-toi que ton CDN ou ton plugin gère la logique de fallback. Convertir manuellement sans fallback cassera les images pour 5-8 % des visiteurs encore sur navigateurs legacy.
AVIF compresse 20-30 % plus petit que WebP à qualité visuelle égale, mais le support navigateur a traîné jusqu'à ce que Safari ajoute le support complet fin 2023. WebP est stable sur tous les navigateurs majeurs depuis 2020. En pratique, AVIF est mieux utilisé comme amélioration progressive : sers AVIF aux navigateurs qui le supportent, fallback sur WebP pour les autres. Les gains de compression sont réels mais pas transformateurs — passer de JPEG à WebP est un gain plus gros que passer de WebP à AVIF.
PNG reste le standard pour les captures d'écran, éléments d'interface, et tout graphique avec contours nets ou texte superposé. WebP gère bien la transparence (canal alpha), mais la compression sans perte du PNG produit des résultats plus nets pour le texte et les traits. Si ton image est une photo produit avec fond transparent, WebP est correct. Si c'est un diagramme avec petit texte ou lignes précises, PNG rendra plus clairement aux petites tailles. La différence de poids compte moins quand l'image fait déjà moins de 50 Ko.
Shopify ne convertit pas automatiquement les images téléversées en AVIF début 2026 — ils utilisent WebP par défaut pour les navigateurs modernes et JPEG en fallback. Tu peux téléverser des fichiers AVIF directement, mais tu perdras le redimensionnement responsive automatique et la négociation de format que Shopify fournit pour JPEG/PNG/WebP. Pour la plupart des boutiques, WebP est le plafond pratique jusqu'à ce que Shopify ajoute le support AVIF natif à leur pipeline CDN. Si tu es sur Shopify Plus avec un front-end custom, tu peux implémenter AVIF toi-même, mais ce n'est pas clé en main.
Pas directement, mais indirectement via les Core Web Vitals. Google mesure le Largest Contentful Paint (LCP) comme partie des signaux d'expérience de page — un facteur de classement depuis 2021. Les grandes images héros en JPEG causent routinièrement des scores LCP au-dessus de 2,5 secondes (seuil d'échec). Passer à WebP peut faire tomber ça à 1,5-2,0 secondes, te faisant passer de « à améliorer » à « bon ». Le choix du format ne surclassera pas un meilleur contenu, mais il retire une pénalité technique. Les utilisateurs mobiles sur connexions lentes voient l'impact le plus gros.
Garde les originaux. Si ta plateforme gère la négociation de format automatique (Webflow, Shopify, la plupart des CMS modernes), tu téléverses un JPEG et le système génère les variantes WebP/AVIF à la volée. Supprimer le JPEG source casse ce pipeline. Même si tu as manuellement converti tout en WebP, garde les originaux haute résolution archivés hors plateforme. Tu en auras besoin si tu redesignes ton site, changes les ratios d'aspect, ou si un futur format (JPEG XL, par exemple) devient standard.
Ouvre Chrome DevTools, va dans l'onglet Network, filtre par « Img », et recharge ta page. Clique sur n'importe quelle requête d'image et vérifie la colonne « Type » — ça devrait dire « webp » si la conversion fonctionne. Si ça dit encore « jpeg » ou « png », ta plateforme ne sert pas de formats optimisés. Tu peux aussi cliquer droit sur une image de ton site live et choisir « Ouvrir l'image dans un nouvel onglet » — l'extension d'URL ou l'en-tête Content-Type dans DevTools confirmera le format.
Squoosh (squoosh.app) est le compresseur open-source de Google qui fonctionne dans le navigateur — glisse une image dedans, choisis WebP ou AVIF, ajuste la qualité, et télécharge. Ça roule localement dans ton navigateur, donc tes images ne quittent jamais ta machine. Pour du traitement par batch, utilise ImageOptim (Mac) ou XnConvert (Windows/Linux) — les deux sont gratuits et gèrent des dossiers d'images d'un coup. Évite les outils en ligne qui demandent de téléverser des fichiers sur leurs serveurs sauf si tu contrôles les images source.
Articles connexes /
Articles connexes /
Articles connexes /
Articles connexes /
Articles connexes /
Articles connexes /









