Compresser ses images pour le web : WebP, AVIF et poids cible

Une page d’accueil qui pèse 4 Mo alors que le texte n’en représente que 200 Ko : le coupable, neuf fois sur dix, ce sont les images. Selon les données du HTTP Archive, les médias représentent en moyenne plus de 50 % du poids total d’une page web en 2026. Compresser ses images pour le web n’est donc pas un luxe, c’est le levier le plus rapide pour gagner des secondes sur le temps de chargement, améliorer son score Core Web Vitals et réduire la consommation de bande passante.

Pourquoi la compression d’images est le premier levier de performance

Quand un visiteur arrive sur un site, son navigateur télécharge chaque ressource dans l’ordre de priorité qu’il détermine. Les images, même si elles sont chargées en différé, consomment de la bande passante et ralentissent le rendu global de la page. Sur mobile, avec une connexion 4G moyenne autour de 10 Mbit/s, une page contenant 3 Mo d’images met facilement plus de deux secondes rien qu’en transfert réseau.

Le score Largest Contentful Paint (LCP), l’un des trois Core Web Vitals de Google, dépend directement du poids de l’image principale visible à l’écran. Google considère qu’un LCP inférieur à 2,5 secondes est bon. Au-delà de 4 secondes, il est mauvais. J’ai vu des sites passer d’un LCP de 5 secondes à 1,8 seconde uniquement en convertissant leurs images JPEG en WebP et en les redimensionnant correctement. Aucun plugin de cache, aucun changement de serveur : juste la compression.

Au-delà de la vitesse, il y a aussi l’espace disque et la bande passante consommés par votre hébergement. Un site e-commerce avec 2 000 fiches produit à trois images chacune, c’est 6 000 fichiers. La différence entre des JPEG de 800 Ko et des WebP de 150 Ko représente presque 4 Go d’économie sur le serveur.

WebP, AVIF, JPEG, PNG : comprendre chaque format

Avant de compresser, il faut choisir le bon format. Chaque format a été conçu pour un usage précis, et les utiliser à mauvais escient annule les bénéfices de la compression.

JPEG : le standard historique

Le JPEG existe depuis 1992. Il utilise une compression avec perte qui supprime les détails peu perceptibles par l’œil humain. C’est le format idéal pour les photographies et les images riches en dégradés de couleurs. Son principal défaut : il ne gère pas la transparence et sa compression crée des artefacts visibles en dessous d’un seuil de qualité autour de 60 %.

PNG : la transparence sans perte

Le PNG offre une compression sans perte et gère la transparence via un canal alpha. Il est parfait pour les logos, les icônes et les captures d’écran contenant du texte. En revanche, une photo enregistrée en PNG pèse facilement 5 à 10 fois plus qu’en JPEG, ce qui le rend inadapté aux contenus photographiques.

WebP : le compromis moderne

Développé par Google, le WebP combine compression avec et sans perte, gestion de la transparence et même l’animation. En 2026, il est supporté par plus de 97 % des navigateurs selon Can I Use. C’est aujourd’hui le format que je recommande par défaut pour la majorité des images web.

AVIF : la nouvelle génération

L’AVIF, basé sur le codec vidéo AV1, pousse la compression encore plus loin. Il offre une qualité visuelle supérieure à WebP à poids égal, gère la transparence, le HDR et les espaces colorimétriques étendus. Son adoption progresse vite : Chrome, Firefox et Safari le supportent tous. Le principal frein reste la lenteur de l’encodage, environ 10 à 20 fois plus lent que WebP, ce qui complique son usage dans des pipelines temps réel.

Comparatif concret : poids et qualité selon le format

Pour illustrer les différences, j’ai pris une photo de 4 000 × 2 667 pixels (typique d’un appareil photo récent) et je l’ai exportée dans chaque format avec un réglage de qualité visuelle équivalent. Voici les résultats mesurés.

Ces chiffres parlent d’eux-mêmes. En passant d’un JPEG qualité 80 à un AVIF qualité 60, le poids chute de 620 Ko à 180 Ko sans différence visible à l’écran sur un moniteur standard. Le WebP qualité 75 reste un excellent compromis entre poids, vitesse d’encodage et compatibilité.

Il faut toutefois nuancer : ces résultats varient selon le contenu de l’image. Une photo avec beaucoup de détails fins (feuillage, cheveux, texture tissu) se compresse moins bien qu’un aplat de couleur. D’où l’importance de tester sur ses propres images plutôt que de se fier uniquement aux moyennes.

Quel poids cible viser pour chaque type d’image

La question que je reçois le plus souvent est : « à quel poids je dois arriver ? ». Il n’y a pas de réponse universelle, mais voici les repères que j’utilise au quotidien, basés sur les recommandations de Google sur la performance web.

Image hero / bannière pleine largeur (1 200 à 1 920 px de large) : viser moins de 150 Ko en WebP ou moins de 100 Ko en AVIF. C’est souvent l’image qui détermine le LCP, elle doit être la plus légère possible tout en gardant un rendu correct.

Images de contenu (800 px de large maximum) : rester sous 80 Ko. À cette taille, un WebP qualité 75 y parvient sans difficulté.

Vignettes et miniatures (300 px ou moins) : viser moins de 30 Ko. Un WebP qualité 70 sur une image de 300 × 200 pixels pèse généralement entre 10 et 20 Ko.

Logos et icônes : privilégier le SVG quand c’est possible (quelques Ko seulement), sinon un PNG optimisé ou un WebP sans perte qui ne dépassera pas 15 Ko.

L’objectif global : maintenir le poids total des images d’une page sous 500 Ko. C’est ambitieux, mais c’est la cible qui permet d’atteindre un LCP correct même sur des connexions mobiles moyennes. Si votre page contient cinq images, chacune doit peser environ 100 Ko maximum. C’est un calcul simple qui guide vos choix de compression. Cela rejoint directement les problématiques de diagnostic de site lent : avant d’installer un plugin de cache, vérifiez d’abord le poids de vos images.

Les outils pour compresser ses images efficacement

Le marché des outils de compression est vaste. Voici ceux que j’utilise régulièrement, classés par contexte d’utilisation.

Outils en ligne de commande

cwebp (fourni par Google) est l’outil de référence pour convertir en WebP. Une commande type :

cwebp -q 75 -m 6 input.jpg -o output.webp

Le paramètre -q 75 fixe la qualité, -m 6 active la compression maximale (plus lente mais plus efficace). Pour un traitement par lot, un simple script Bash suffit :

for f in *.jpg; do cwebp -q 75 -m 6 "$f" -o "${f%.jpg}.webp"; done

avifenc, issu de la bibliothèque libavif, fonctionne de manière similaire :

avifenc --min 20 --max 40 -s 6 input.jpg output.avif

Les paramètres --min et --max définissent la plage de quantification (plus bas = meilleure qualité), et -s 6 contrôle la vitesse d’encodage.

Outils en ligne

Squoosh, développé par l’équipe Chrome, est l’outil en ligne que je recommande en premier. Il permet de comparer visuellement le résultat avant/après, de choisir entre WebP, AVIF, JPEG et d’ajuster la qualité au pixel près. Tout se passe dans le navigateur, aucun fichier n’est envoyé sur un serveur.

Pour les traitements en lot, Optimizilla et les outils d’Adobe Express font le travail correctement, mais attention aux limites de fichier et aux conditions d’utilisation.

Plugins WordPress

Sur WordPress, trois extensions se démarquent : ShortPixel, Imagify et Smush. Elles compressent les images automatiquement à l’envoi dans la médiathèque et génèrent les versions WebP (et parfois AVIF) en parallèle. L’avantage est l’automatisation complète ; l’inconvénient est la dépendance à un service tiers et des quotas mensuels sur les versions gratuites. C’est un choix pertinent si vous publiez régulièrement du contenu et ne souhaitez pas toucher à la ligne de commande.

Le gain de performance obtenu par la compression se combine idéalement avec un cache navigateur ou serveur bien configuré et un CDN qui distribue ces fichiers optimisés au plus près de l’utilisateur.

Intégrer WebP et AVIF dans son HTML avec la balise picture

Compresser ne suffit pas : il faut aussi servir le bon format au bon navigateur. La balise HTML <picture> permet de proposer plusieurs sources et de laisser le navigateur choisir celle qu’il supporte.

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="Description de l'image" 
       width="800" height="533" loading="lazy">
</picture>

L’ordre est important : le navigateur parcourt les <source> de haut en bas et utilise la première qu’il supporte. On place donc AVIF en premier (le plus léger), WebP ensuite, et JPEG en dernier recours. L’attribut type est essentiel, c’est lui qui permet au navigateur de sauter les formats qu’il ne reconnaît pas sans télécharger le fichier.

L’attribut loading="lazy" diffère le chargement des images situées hors de la zone visible. Attention cependant : ne l’appliquez jamais à l’image LCP (celle visible au premier écran), car cela retarderait son affichage et dégraderait le score.

Les attributs width et height sont indispensables pour éviter le décalage de mise en page (Cumulative Layout Shift). Le navigateur réserve l’espace avant même d’avoir téléchargé l’image. D’expérience, c’est un détail que beaucoup de développeurs oublient, et qui coûte des points de CLS inutilement.

Le cas des images responsives

Pour aller plus loin, combinez <picture> avec l’attribut srcset et sizes pour servir des tailles différentes selon la largeur d’écran :

<picture>
  <source srcset="image-400.avif 400w, image-800.avif 800w, image-1200.avif 1200w" 
          sizes="(max-width: 600px) 400px, (max-width: 1024px) 800px, 1200px" 
          type="image/avif">
  <source srcset="image-400.webp 400w, image-800.webp 800w, image-1200.webp 1200w" 
          sizes="(max-width: 600px) 400px, (max-width: 1024px) 800px, 1200px" 
          type="image/webp">
  <img src="image-800.jpg" alt="Description" width="800" height="533" loading="lazy">
</picture>

Un mobile qui affiche l’image sur 400 pixels ne téléchargera pas la version 1 200 pixels. Le gain est considérable : une image de 400 px en WebP pèse environ 4 fois moins que la même en 1 200 px.

Automatiser la compression dans son workflow

Compresser manuellement chaque image fonctionne pour un blog qui publie un article par semaine. Mais pour un site avec des mises à jour fréquentes ou un catalogue produit important, il faut automatiser. En tant que développeur, c’est la partie que je trouve la plus intéressante, car elle élimine le risque d’oubli.

Avec un task runner (Gulp, Webpack, Vite)

Dans un projet front-end moderne, la compression d’images peut s’intégrer au build. Avec Sharp (bibliothèque Node.js), quelques lignes suffisent :

import sharp from 'sharp';

await sharp('input.jpg')
  .resize(1200)
  .webp({ quality: 75 })
  .toFile('output.webp');

await sharp('input.jpg')
  .resize(1200)
  .avif({ quality: 50 })
  .toFile('output.avif');

Sharp est rapide, supporte WebP, AVIF, JPEG et PNG, et s’intègre facilement dans un script de build ou un plugin Vite. C’est l’outil que j’utilise sur la plupart de mes projets.

Avec un hook Git ou un pipeline CI/CD

Une approche que j’apprécie particulièrement : déclencher la compression automatiquement à chaque commit contenant des images. Un pre-commit hook vérifie si des fichiers image ont été ajoutés ou modifiés, et lance la conversion en WebP/AVIF avant le commit. Cela garantit que jamais une image non optimisée n’arrive en production.

Dans un pipeline CI/CD (GitHub Actions, GitLab CI), un job dédié peut effectuer la même opération. L’avantage est que la compression ne ralentit pas le poste du développeur, elle s’exécute sur le serveur de build.

Côté serveur avec la négociation de contenu

Certains serveurs ou CDN peuvent servir automatiquement le bon format selon l’en-tête Accept du navigateur. Cloudflare, par exemple, propose la fonctionnalité Polish qui convertit les images en WebP à la volée. Nginx peut aussi être configuré pour servir un fichier .webp s’il existe à côté du JPEG original. Cette approche côté serveur évite de modifier le HTML, ce qui est pratique sur des sites existants. Elle complète bien la mise en place d’un CDN performant.

Si vous envisagez de changer d’infrastructure pour bénéficier de ces fonctionnalités, pensez à consulter le guide sur le choix d’un hébergeur et les différences entre mutualisé, VPS et dédié pour dimensionner correctement votre solution.

Les erreurs fréquentes qui ruinent la compression

Même avec les bons outils, certaines erreurs reviennent régulièrement. Voici celles que je corrige le plus souvent lors de mes audits de performance.

Ne pas redimensionner avant de compresser

C’est l’erreur numéro un. Envoyer une photo de 4 000 × 3 000 pixels sur un site qui l’affiche en 800 pixels de large, c’est transporter 25 fois plus de pixels que nécessaire. La compression n’y change rien : vous envoyez un fichier énorme que le navigateur devra redimensionner côté client, consommant du CPU et de la mémoire. Redimensionnez toujours vos images à la taille d’affichage maximale prévue avant de les compresser.

Compresser un fichier déjà compressé

Passer un JPEG qualité 70 dans un second round de compression JPEG ne fait qu’ajouter des artefacts sans réduire significativement le poids. Si vous devez recompresser, partez toujours du fichier source original (RAW, PNG sans perte ou JPEG qualité maximale).

Oublier les métadonnées EXIF

Les photos prises avec un appareil ou un smartphone embarquent des métadonnées EXIF (modèle d’appareil, GPS, date, paramètres de prise de vue). Ces données peuvent peser plusieurs dizaines de Ko. La plupart des outils de compression les suppriment par défaut, mais vérifiez ce point, surtout pour des raisons de confidentialité si vos images contiennent des coordonnées GPS.

Utiliser le même réglage pour toutes les images

Une illustration vectorielle exportée en PNG et une photo de paysage n’ont pas les mêmes besoins de compression. Appliquer un réglage unique (par exemple WebP qualité 80 partout) laisse de l’optimisation sur la table. Les illustrations supportent souvent une qualité WebP de 60 sans perte visible, tandis que les photos de portrait peuvent nécessiter 80 pour éviter les artefacts sur les tons chair.

Négliger la version PHP et la configuration serveur

Sur un hébergement WordPress, la bibliothèque GD ou Imagick utilisée pour le traitement d’images dépend de la version de PHP installée. Les versions récentes de PHP (8.1+) offrent un meilleur support WebP natif. Si votre hébergeur tourne encore sur PHP 7.4, la génération de WebP peut échouer silencieusement ou produire des fichiers plus lourds que prévu.

Ignorer le lazy loading sélectif

Appliquer loading="lazy" à toutes les images, y compris celle du premier écran, est contre-productif. L’image LCP doit se charger le plus tôt possible, avec un fetchpriority="high" si nécessaire. Seules les images situées sous la ligne de flottaison doivent recevoir l’attribut lazy.