Compression par lots d'images pour les développeurs web | Bulk Image Compressor

Published December 18, 2025

Les images sont les actifs les plus lourds sur la plupart des sites web. Sur une page moyenne, elles représentent 40 à 60% du poids total. Si vous êtes développeur web et que vous ne compressez pas les images, vous livrez des pages gonflées, peu importe la propreté de votre code.

La question n’est pas de savoir s’il faut compresser. C’est de savoir où dans votre flux de travail la compression doit avoir lieu et quel outil convient à chaque situation.

Où la compression d’images s’intègre dans un flux de travail de développement

Il y a trois points principaux où vous pouvez compresser des images pendant le développement :

Avant le commit. Vous optimisez les images localement avant qu’elles n’entrent dans le contrôle de version. Cela maintient votre référentiel léger et signifie que chaque environnement (staging, production, machines des autres développeurs) reçoit automatiquement les versions optimisées.

Pendant le build. Les outils de build comme Vite ou webpack gèrent la compression dans le cadre du pipeline d’actifs. Les images sources restent en pleine qualité dans le dépôt, et le processus de build génère des versions optimisées pour le déploiement.

Au niveau du CDN. Des services comme Cloudflare, Imgix ou Cloudinary transforment et compressent les images à la volée en fonction de l’appareil et du navigateur qui les demande.

Chaque approche a ses compromis, et vous pouvez les combiner.

Outils en ligne vs plugins de build

Pour une tâche ponctuelle rapide, comme compresser un lot de captures d’écran pour un article de blog ou optimiser un jeu d’icônes, un outil en ligne est l’option la plus rapide. Ouvrez Bulk Image Compressor, déposez vos fichiers, ajustez la qualité et téléchargez. Fait en moins d’une minute.

Les plugins de build gèrent l’optimisation continue automatiquement. Voici à quoi cela ressemble en pratique.

Vite

Les utilisateurs de Vite peuvent utiliser vite-plugin-imagemin ou des plugins similaires :

// vite.config.js
import imagemin from 'vite-plugin-imagemin';

export default {
  plugins: [
    imagemin({
      mozjpeg: { quality: 80 },
      webp: { quality: 80 },
      pngquant: { quality: [0.7, 0.8] },
    }),
  ],
};

Ceci compresse les images pendant vite build. Les fichiers sources restent intacts. Le répertoire de sortie reçoit les versions optimisées.

webpack

Avec webpack, image-minimizer-webpack-plugin fait le même travail :

const ImageMinimizerPlugin = require('image-minimizer-webpack-plugin');

module.exports = {
  optimization: {
    minimizer: [
      new ImageMinimizerPlugin({
        minimizer: {
          implementation: ImageMinimizerPlugin.sharpMinify,
          options: {
            encodeOptions: {
              jpeg: { quality: 80 },
              webp: { quality: 80 },
            },
          },
        },
      }),
    ],
  },
};

Quand utiliser quoi

Utilisez un outil en ligne quand :

Vous ajoutez quelques images à un projet et voulez les optimiser immédiatement
Vous travaillez avec du contenu d’un client ou d’un designer qui a envoyé des fichiers non optimisés
Votre projet n’a pas d’étape de build (HTML statique, sites simples)
Vous voulez vérifier visuellement les résultats de compression avant de commiter

Utilisez les plugins de build quand :

Votre projet a déjà un pipeline de build
Plusieurs développeurs contribuent des images et vous voulez une optimisation cohérente
Vous avez besoin de conversion de format (par exemple, générer automatiquement des versions WebP)
Vous voulez des images sources en pleine qualité dans le dépôt pour un éventuel retraitement futur

Optimisation d’images dans le CI/CD

Les plugins de build s’exécutent lors des builds locaux, mais vous pouvez aussi ajouter l’optimisation d’images à votre pipeline CI/CD. Cela rattrape les images non optimisées qui passent entre les mailles du filet, quel que soit celui qui les a commitées.

Une approche simple consiste à exécuter un script dans votre pipeline CI qui vérifie la taille des fichiers image :

# Échoue le build si une image dépasse 500 Ko
find public/images -type f \( -name "*.jpg" -o -name "*.png" -o -name "*.webp" \) -size +500k | tee oversized.txt
if [ -s oversized.txt ]; then
  echo "Images surdimensionnées trouvées. Compressez avant de déployer."
  exit 1
fi

Pour une compression automatisée dans le CI, des outils comme sharp-cli ou imagemin-cli peuvent traiter les images comme une étape de build. Cela garantit que rien ne part en production sans être compressé.

Chargement paresseux et images responsives

La compression seule ne suffit pas. La façon dont vous chargez les images compte tout autant.

Le chargement paresseux diffère les images hors écran jusqu’à ce que l’utilisateur les atteigne en défilant. Ajoutez loading="lazy" à chaque image sous la ligne de flottaison. Ne mettez pas de chargement paresseux sur votre image hero ou tout contenu visible au chargement initial de la page, car cela nuirait à votre score Largest Contentful Paint.

Les images responsives servent différentes tailles en fonction de la largeur de l’écran. Un téléphone n’a pas besoin d’une image de 2400px destinée à un écran d’ordinateur. Utilisez les attributs srcset et sizes pour laisser le navigateur choisir la bonne version :

<img
  src="product-800.webp"
  srcset="product-400.webp 400w, product-800.webp 800w, product-1600.webp 1600w"
  sizes="(max-width: 640px) 400px, (max-width: 1024px) 800px, 1600px"
  alt="Photo produit"
  width="1600"
  height="1067"
  loading="lazy"
>

Générez ces variantes de taille dans le cadre de votre processus de build ou avec un outil par lots avant le téléchargement.

Livraison via CDN

Un CDN (Content Delivery Network) sert les images depuis des serveurs géographiquement proches de vos visiteurs. Cela réduit la latence, mais certains CDN vont plus loin avec l’optimisation d’images à la volée.

Cloudflare Image Resizing peut redimensionner et convertir les images en WebP ou AVIF automatiquement en fonction du navigateur du visiteur. Vous n’avez pas besoin de générer vous-même les variantes.

Imgix et Cloudinary sont des CDN d’images dédiés. Vous téléchargez une source de haute qualité, et ils génèrent la taille, le format et la qualité souhaités via des paramètres d’URL. C’est puissant mais a un coût par image.

Pour la plupart des projets, compresser les images avant le téléchargement et les servir via un CDN standard (Cloudflare, Fastly, AWS CloudFront) suffit. Les CDN d’images dédiés sont utiles quand vous avez des milliers d’images téléchargées par les utilisateurs et que vous avez besoin de redimensionnement dynamique. Pour comprendre pourquoi la compression est importante pour le web, notre guide sur pourquoi les images de sites web ont besoin de compression couvre les fondamentaux.

Erreurs courantes des développeurs

Commiter des images non optimisées. Un JPEG de 5 Mo dans votre dépôt reste dans l’historique git pour toujours, même si vous le remplacez plus tard. Compressez avant de commiter.

Utiliser PNG pour les photographies. Les PNG sont faits pour les graphiques, les captures d’écran et les images avec transparence. Une photographie en PNG est typiquement 3 à 5 fois plus grande que la même image en JPEG ou WebP. Utilisez le bon format pour le type de contenu. Consultez notre guide de comparaison des formats pour les spécificités.

Omettre les attributs width et height. Sans dimensions explicites, le navigateur ne sait pas combien d’espace réserver pour une image avant qu’elle ne se charge. Cela provoque des décalages de mise en page, ce qui nuit à votre score CLS et dérange les utilisateurs.

Sur-compresser. Pousser la qualité à 30 ou 40% pour obtenir des fichiers minuscules produit des artefacts visibles. Pour les images web, une qualité de 75 à 82% offre le bon équilibre entre taille et apparence.

Ignorer les dimensions des images. Compresser une photo de 4000px à 80% de qualité est une bonne chose, mais si elle s’affiche à 600px de large sur votre page, vous envoyez toujours beaucoup plus de pixels que nécessaire. Redimensionnez d’abord à vos dimensions d’affichage, puis compressez.

Ne pas utiliser WebP. La prise en charge de WebP par les navigateurs est désormais universelle. Si vous servez encore exclusivement du JPEG et du PNG, vous laissez passer 25 à 35% d’économies de taille de fichier.

Une approche pratique

Pour la plupart des projets web, voici ce qui fonctionne bien :

Redimensionnez et compressez les images avant de commiter, en utilisant un outil en ligne comme Bulk Image Compressor ou un script local.
Ajoutez un plugin de build comme filet de sécurité pour rattraper tout ce qui a glissé.
Utilisez le chargement paresseux et les images responsives dans votre HTML.
Servez via un CDN.

Vous n’avez pas besoin de faire les quatre dès le premier jour. Commencez par la première étape. Cela fera à lui seul une différence notable dans vos temps de chargement de page.

Ready to compress your images?

Bulk compress JPEG, PNG, WebP, and AVIF images right in your browser. No uploads, no sign-ups.

Try Bulk Image Compressor