Les images : principal levier pour un site web plus léger

Sur une page web moyenne, la moitié du poids vient des images. Pas le code, pas les polices, pas le JavaScript : les images. C'est toujours une des première chose que je regarde lorsque j'analyse les lenteurs d'un site.

Et le correctif est rapide à mettre en place. Quelques heures pour une première passe, des outils gratuits, un effet visible dans la foulée. Sur un site PME typique, c'est la différence entre une page de 3 Mo et une page de 1,2 Mo.

Cette optimisation est aussi la plus accessible pour une démarche d'éco-conception. Sur un site qui reçoit 10'000 visites par mois, passer de 3 Mo à 1 Mo par page, c'est environ 240 Go de données transférées en moins sur l'année. L'énergie (et donc le bilan carbon) économisée du datacenter au navigateur du visiteur n'est pas anecdotique. J'ai détaillé l'angle empreinte carbone dans le poids carbone de votre site web.

Et c'est obtenu sans repenser la stratégie de contenu, sans changer de CMS, sans rien casser.

Pourquoi les images pèsent autant

Le problème est presque toujours le même. Un appareil photo récent produit des fichiers de 4 à 8 Mo. Lors de la contribution du contenu, le fichier est uploadé tel quel, ou retravailé dans photoshopet sauvegarder sans en changer le format. Et la même image part vers tous les écrans, du 27 pouces au mobile, alors qu'envoyer 4'000 pixels de large à un téléphone qui en affiche 400, c'est 90% de pixel non utilisés.

Au bout du compte, une page d'accueil avec dix visuels peut dépasser les 20 Mo. La première question n'est d'ailleurs pas technique : ai-je vraiment besoin de toutes ces images ? Souvent, la réponse honnête est non. Pour celles qui restent, on peut faire beaucoup.

Quel format choisir

Avant de parler compression, beaucoup de sites ont un problème plus simple : ils utilisent le mauvais format.

Le JPEG reste le bon défaut pour les photos. Sa compression avec perte fait 5 à 10 fois mieux qu'un PNG équivalent sans dégradation visible.

Le PNG est souvent utilisé à tort. Comme il est « sans perte » et qu'il gère la transparence, on le croit plus propre. En pratique, il pèse 3 à 5 fois plus qu'un JPEG pour le même rendu. À garder pour les vrais cas de transparence, et encore.

Le WebP est le format à privilégier aujourd'hui. Google annonce 25 à 34 % de gain par rapport au JPEG à qualité comparable, et le support est désormais universel depuis que Safari l'a adopté en 2020. Pour un site qui se lance ou se refond en 2026, c'est le choix préféré pour s'assurer de son poids et compatibilité.

L'AVIF va encore plus loin (environ 30 % de gain supplémentaire par rapport au WebP), mais son support est plus récent. Dans un workflow moderne, je l'utilise comme format préféré avec un fallback WebP dans la cas ou le device du client ne supporte pas encore le AVIF.

Le SVG, lui, n'est pas une image au sens classique : c'est un format vectoriel, l'image est décrite mathématiquement plutôt qu'en pixels. Pour un logo, un pictogramme, une illustration simple, c'est presque toujours le bon choix : quelques kilo-octets, et une qualité parfaite à toutes les tailles.

La recette : format, compression, taille servie

Trois leviers, qui se cumulent. Changer de format (PNG/JPEG vers WebP ou AVIF) gagne facilement 30 %. Descendre la qualité de compression jusqu'au seuil où l'oeil ne voit plus de différence ajoute 20 à 40 %. Servir une version 800 px au mobile plutôt qu'une 4'000 px coupe encore 50 à 70 %. Cumulés, ces trois leviers ramènent une image de 2 Mo sous les 150 Ko, sans que vos visiteurs voient la différence.

Servir la bonne taille au bon écran

Imaginez une photo 4'000 × 2'667 px en haut de votre page d'accueil. Sur mobile, elle s'affiche en 400 × 267. Votre visiteur télécharge dix fois plus de données que nécessaire, pour voir exactement la même image, en plus lent, et en brûlant sa data.

La parade existe depuis longtemps et ne demande aucun outil spécial : on prépare plusieurs versions (par exemple 400, 800 et 1'600 px de large) et on laisse le navigateur choisir. C'est ce que fait la balise <picture> avec l'attribut srcset :

<picture>
  <source
    srcset="hero-small.webp 400w, hero-medium.webp 800w, hero-large.webp 1600w"
    type="image/webp">
  <source
    srcset="hero-small.jpg 400w, hero-medium.jpg 800w, hero-large.jpg 1600w"
    type="image/jpeg">
  <img src="hero-large.jpg" alt="Hero image">
</picture>

Sur mobile, ce mécanisme à lui seul réduit le poids des images de 50 %, sans rien changer au rendu sur les autres écrans.

Les outils gratuits qui font le travail

Pas besoin de logiciel payant.

TinyPNG est le plus simple : on dépose jusqu'à vingt images, on récupère le résultat compressé. Cinq minutes, zéro configuration, ratio qualité/poids très honnête.

Squoosh est l'outil de Google qui tourne dans le navigateur. On charge une image, on compare les formats côte à côte, on bouge un curseur de qualité et on voit en direct ce qu'on perd (ou pas). C'est aussi un excellent moyen d'apprendre, parce qu'on visualise le compromis.

Pour les sites qui ont des centaines ou des milliers d'images, l'automatisation devient vite indispensable. ImageMagick en ligne de commande fait ça très bien :

mogrify -format webp -quality 80 *.jpg

Une commande, toutes vos JPEG deviennent des WebP compressées à 80 %. Sur 500 images, ça prend moins d'une minute.

Lazy loading : ne charger que ce qui est visible

Dernière optimisation, et probablement celle au meilleur rapport effort/effet : ne charger les images qu'au moment où le visiteur les voit. Inutile de télécharger la photo en bas de page si la personne repart avant d'avoir scrollé. C'est natif dans tous les navigateurs modernes, sans JavaScript :

<img src="image-en-bas-de-page.webp" loading="lazy" alt="…">

Sur une page riche en visuels, on enlève typiquement 20 à 30 % des requêtes image au premier chargement. C'est aussi ce qui se ressent le plus côté visiteur : la page apparaît vite, le reste se charge « pendant qu'on lit ».

Côté CMS : ce qui est déjà fait pour vous

Sur un site WordPress ou Drupal récent, une partie du travail est déjà faite. Drupal 11 expose les image styles avec format WebP en standard, et WordPress 6.5 et plus propose la conversion automatique à l'upload. Le piège récurrent, c'est que le thème continue souvent à servir l'image originale via une simple balise <img> qui ignore les dérivés générés. Vérifiez dans le HTML rendu que vos pages utilisent bien <picture> avec un srcset complet : sinon vous payez le coût de génération des dérivés sans en récolter le bénéfice. C'est l'écart le plus fréquent que je trouve en audit. La machine fait le travail, le thème ne le récupère pas.

Cas concret : un site e-commerce

Sur un site e-commerce que j'ai optimisé récemment, voici les chiffres avant/après. Comme toujours, ce sont les chiffres de ce site-là. Les gains dépendent du point de départ.

Avant : douze photos JPEG non compressées (≈200 Ko pièce) plus cinq PNG sur les sections principales. Total : environ 3,15 Mo d'images par page produit.

Après : conversion en WebP, compression raisonnable, trois tailles responsives, lazy loading activé. La même page charge environ 670 Ko d'images au premier affichage. Soit 78 % de moins, et un temps de chargement divisé par quatre.

L'effet sur les conversions a été mesurable. Pour situer l'ordre de grandeur sans trop extrapoler : l'étude Milliseconds Make Millions (Deloitte × Google, 37 marques, 30 millions de sessions) observe qu'un gain de 0,1 seconde sur le mobile se traduit par +8 % de conversions dans le retail et +10 % dans le voyage, avec aussi un panier moyen en hausse. Les chiffres exacts ne sont pas transposables d'un site à l'autre, mais la corrélation, elle, est solide. Sur mobile, chaque dixième de seconde compte. C'est aussi pour ça que les Core Web Vitals que Google regarde vraiment accordent au temps de chargement un poids structurant.

Quand passer à un service spécialisé

Gérer manuellement trois tailles de chaque image, dans deux formats, pour des centaines de visuels, ça devient ingérable. C'est là qu'un service d'optimisation automatique a du sens. Cloudinary, imgix, Bunny Optimizer : vous envoyez l'image une fois, le service génère et sert la bonne version pour chaque appareil à la volée. La plupart ont un palier gratuit qui suffit aux petits sites, et facturent quelques dizaines de francs par mois au-delà.

Je recommande cette option dès qu'un site dépasse quelques centaines d'images, ou quand des contributeurs ajoutent régulièrement des visuels sans passer par un développeur (on connaît tous le PNG de 4 Mo glissé en pièce jointe).

Une checklist pour cette semaine

Pour tester sur votre propre site :

1. Lancer Website Carbon Calculator sur votre page d'accueil et noter le chiffre
2. Ouvrir Lighthouse (F12 → Performance) et lire les recommandations, notamment « Serve images in next-gen formats » et « Properly size images »
3. Prendre cinq à dix images clés du site et les passer dans Squoosh
4. Comparer avant/après et vérifier que le rendu tient
5. Relancer Website Carbon Calculator pour mesurer l'écart

Comptez une trentaine de minutes. Si les résultats parlent, vous avez de quoi justifier une passe complète sur le reste du site.

À retenir

Sur la quasi-totalité des sites PME, les images sont le principal levier de poids. La moitié du travail de performance web passe par là. Les outils existent depuis des années, ils sont gratuits et bien documentés. Servir des photos non optimisées en 2026, ce n'est plus un manque de moyens, c'est qu'on n'a pas regardé.

Si vous voulez un coup de main pour faire le tri sur votre site, écrivez-moi. C'est presque toujours un chantier court, avec un retour visible dès la première semaine.