Comment compresser les images pour le web
L’essentiel du poids d’une image est gaspillé bien avant que l’encodeur n’intervienne. Voici l’ordre d’opérations qui supprime réellement des octets — et les réglages qui méritent votre attention.
Pourquoi le poids des images compte
Sur la plupart des sites, les images sont le premier contributeur au poids de la page — souvent plus que tous les scripts, styles et polices réunis. Deux conséquences. D’abord, les visiteurs en données mobiles attendent plus longtemps et paient pour ce privilège. Ensuite, le poids des images se répercute directement sur le Largest Contentful Paint, le Core Web Vital le plus souvent mis en cause dans un mauvais score de performance, car l’élément le plus grand d’une page est généralement une image d’en-tête.
Bonne nouvelle : le poids des images est aussi ce qu’il y a de plus facile à corriger. Rien de tout cela n’exige de revoir la chaîne de build.
Travaillez par ordre d’impact
Les outils de compression vous poussent à attraper d’abord le curseur de qualité. C’est le plus petit des trois leviers. L’ordre devrait être :
- Redimensionner — le gain le plus important, de loin.
- Choisir le format — un gain important et unique.
- Régler la qualité — du peaufinage, avec des gains réels mais limités.
1. Redimensionnez d’abord
Une photo de 4000 pixels de large affichée dans un emplacement de 800 pixels transporte environ 25 fois plus de pixels qu’elle ne peut en montrer. Aucun codec ne peut combler cet écart. Servir une image surdimensionnée puis la compresser agressivement est l’erreur classique : vous payez deux fois, et le résultat visible est pire que si vous aviez simplement redimensionné correctement.
Redimensionnez à la taille d’affichage réelle, doublée pour les écrans haute densité si l’image compte. En règle générale, une image d’en-tête pleine largeur dépasse rarement 2000 pixels de large, et les images de contenu dans la page rarement plus de 1200.
2. Choisissez le format
Les photographies devraient partir en AVIF ou WebP. Les graphiques à bords nets, avec du texte ou de la transparence, devraient rester en PNG ou WebP sans perte. Le guide des formats détaille les compromis ; en bref, le choix du format se décide par type d’image, pas de façon globale.
3. Réglez la qualité
Pour les formats avec perte, la qualité est un réglage de 0 à 100 qui échange de la fidélité contre du poids. Ce n’est pas linéaire : passer de 90 à 80 retire souvent un tiers du fichier sans différence perceptible, alors que passer de 50 à 40 ne produit guère que des artefacts visibles.
Points de départ raisonnables :
| Contenu | Cible approximative | Remarques |
|---|---|---|
| Photographies pour le web | qualité JPEG/WebP ~75 | Le point d’équilibre habituel ; AVIF atteint une qualité comparable à une valeur encore plus basse |
| Vignettes, avatars | qualité 60–70 | Une petite taille d’affichage masque plus que vous ne l’imaginez |
| Captures d’écran, UI, texte | Sans perte (PNG / WebP sans perte) | Toute compression avec perte bave sur les bords d’un pixel et sur les glyphes |
| Archivage / impression | Qualité 90+, ou l’original | Conservez l’original ; ce n’est pas un scénario de diffusion web |
Jugez à la taille d’affichage, pas en zoomant. Comparez l’image compressée et l’original à la taille à laquelle elles apparaîtront réellement. Les différences flagrantes à 400 % de zoom sont généralement invisibles en contexte.
Un flux par lots qui passe à l’échelle
- Rassemblez tout dans un dossier — captures d’écran, photos, exports.
- Séparez en deux groupes : photographique et graphique. Ils demandent des formats et des réglages différents.
- Redimensionnez chaque groupe à ses dimensions de diffusion.
- Compressez le groupe photographique en AVIF et WebP ; compressez le groupe graphique sans perte.
- Comparez chaque résultat à son original. Tout ce qui a grossi est écarté — c’est un signal, pas un échec.
- Conservez les originaux. La sortie compressée est un artefact de build ; vos originaux sont l’archive.
tinyimg prend en charge les étapes 4 et 5 pour jusqu’à 30 fichiers à la fois, et peut produire plusieurs formats en une seule passe afin de comparer les poids directement. Le traitement par lots dans le navigateur signifie aussi qu’un dossier de photos clients ou personnelles ne quitte jamais votre machine — un atout réel si les politiques d’envoi entrent en ligne de compte.
Les erreurs qui gaspillent le plus d’octets en silence
- Servir une seule image énorme à tous les appareils. Un unique JPEG de 2000 pixels n’est pas une stratégie responsive. Utilisez
srcsetpour que les téléphones récupèrent une variante plus légère. - Réenregistrer des JPEG en boucle. Chaque génération avec perte cumule les dégâts. Réencodez toujours depuis l’original.
- Utiliser le PNG pour des photographies. Souvent 5 à 10× plus lourd que le JPEG équivalent, sans bénéfice visible.
- Courir après le « plus petit possible » au-delà de l’utile. Une économie de 40 % est excellente ; 45 % avec un ciel qui présente des bandes visibles, non.
- Oublier le chargement différé. Les images sous la ligne de flottaison ne devraient pas bloquer le premier rendu. Le chargement différé, c’est un attribut modifié pour un effet considérable.
- Ne jamais remesurer. Fixez un budget, puis vérifiez-le — sinon il dérive vers le haut, un asset à la fois.
Savoir quand vous avez terminé
Choisissez un budget de page et tenez-le. Un objectif raisonnable pour une page de contenu est de garder la charge d’images totale sous environ un mégaoctet, l’image d’en-tête fournissant le plus gros effort. Si une page explose ce plafond, les coupables habituels sont une image d’en-tête non redimensionnée, une photographie stockée en PNG, ou plusieurs images décoratives qui pourraient être du SVG ou du CSS.
L’exercice manque de glamour mais il est court : redimensionner, choisir un format, régler une qualité raisonnable, vérifier à la taille d’affichage et conserver les originaux. Cette séquence élimine l’écrasante majorité du poids d’images évitable sur à peu près n’importe quel site.