Comment compresser des images pour un site web sans en gâcher la qualité

La réponse pratique

Pour compresser des images de site sans gâcher la qualité, ne commencez pas par pousser le curseur de qualité au plus bas encore « acceptable ». Partez plutôt du rôle réel de l’image dans la page. Un hero, une photo produit à zoomer, une illustration de blog, un avatar, une capture d’écran et une texture de fond n’ont pas les mêmes dimensions, formats ou niveaux de qualité.

La règle utile est la suivante : redimensionnez d’abord à la plus grande taille effectivement affichée, puis compressez juste ce qu’il faut pour que l’image reste identique dans la mise en page. Si une image de blog s’affiche à 760 pixels CSS de large, une source de 1500 à 1600 px suffit généralement pour les écrans haute densité. Un original d’appareil photo de 5000 px, c’est des données gaspillées. Un export à 760 px peut sembler flou sur écran retina. Le bon fichier se trouve entre ces deux extrêmes.

« Sans perdre en qualité » mérite aussi une définition simple. En web, cela veut dire pas de perte visible à la taille où les visiteurs regardent réellement l’image, pas une perfection mathématique au pixel près. Un WebP compressé n’est pas identique à l’original, mais il peut être visuellement indiscernable dans la page.

Identifiez d’abord le type d’image

Avant de choisir WebP, AVIF, JPEG, PNG ou un niveau de qualité, classez l’image :

Ce tableau est volontairement tranché. La plupart des mauvaises compressions d’images web viennent du fait qu’on traite tous les fichiers de la même façon. Un hero d’accueil peut affecter le Largest Contentful Paint. Une image de fiche produit peut peser sur la confiance et la conversion. Un fond décoratif peut être bien plus léger parce que personne ne le regarde en détail.

D’abord redimensionner : les dimensions font l’essentiel du travail

La compression réduit le nombre d’octets utilisés pour stocker une grille de pixels fixe. Le redimensionnement change la grille elle-même. Si la source a beaucoup plus de pixels que la page ne peut en afficher, redimensionner est le gain le plus propre.

Formule simple de dimensionnement :

largeur source cible = plus grande largeur CSS affichée × device pixel ratio

Par exemple :

• Une image de carte affichée à 320 CSS px devrait avoir une source de 640 px pour les écrans 2x.
• Une image de blog affichée à 760 CSS px devrait avoir une source de 1500–1600 px.
• Un hero pleine largeur autour de 1200 CSS px peut nécessiter une source de 2000–2400 px, selon le cadrage et les appareils du public.

N’utilisez pas aveuglément du 3x pour tout. web.dev rappelle que le DPR et la mise en page comptent ensemble et que, dans bien des cas, les utilisateurs ne perçoivent pas le bénéfice d’une source à très haut DPR. Un hero de 2400 px peut être justifié. Un hero de 5000 px « parce que plus de pixels, c’est plus sûr » ne fait souvent que brûler de la bande passante.

PhotoTools sépare ces deux tâches. Utilisez Resize quand vous avez besoin de pixels exacts ou d’un côté long plus petit. Ensuite, Compress permet de choisir JPEG, WebP ou AVIF et d’ajuster la qualité.

Choisir le format avant de toucher à la qualité

Le format décide quel type de détail peut être retiré proprement.

• Utilisez WebP pour la plupart des photos web. Il est largement pris en charge dans les navigateurs modernes et donne en général des fichiers plus petits que JPEG à qualité visuelle équivalente. La documentation WebP de Google fait état de 25–34 % de gain par rapport à un JPEG équivalent.
• Utilisez AVIF quand chaque octet compte. AVIF peut battre WebP sur les gros fichiers photographiques, mais il est plus lent à encoder et ajoute de la complexité côté pipeline. Servez-le avec des fallbacks, pas seul.
• Utilisez JPEG comme fallback de compatibilité. Toujours utile pour l’e-mail, les CMS anciens, les téléchargements et comme source de fallback dans <img>.
• Utilisez PNG ou WebP sans perte pour les captures d’écran et le texte. JPEG/WebP avec perte peut brouiller les petits textes d’UI et créer du bruit de couleur autour des arêtes dures.
• Utilisez SVG pour les logos et icônes. Un logo raster en WebP peut être plus léger qu’un PNG, mais un SVG propre reste en général plus net et plus léger.

Si vous utilisez <picture>, placez le format le plus efficace en premier et gardez un fallback compatible dans l’img imbriqué :

<picture>
  <source
    type="image/avif"
    srcset="/images/hero-1200.avif 1200w, /images/hero-2000.avif 2000w"
    sizes="100vw"
  />
  <source
    type="image/webp"
    srcset="/images/hero-1200.webp 1200w, /images/hero-2000.webp 2000w"
    sizes="100vw"
  />
  <img
    src="/images/hero-1200.jpg"
    width="1200"
    height="800"
    alt="Cuisine rénovée avec meubles en noyer et lumière naturelle"
  />
</picture>

L’élément img reste important. Il porte la source de fallback, alt, width et height. Ne cachez pas d’informations d’accessibilité ou de mise en page dans les éléments source.

Réglages de qualité vraiment utiles

Les valeurs de qualité ne sont pas standardisées. Une qualité JPEG 80 dans un encodeur ne correspond pas forcément à la qualité 80 dans un autre. WebP 80, JPEG 80 et AVIF 50 ne sont pas non plus équivalents. Considérez la qualité comme un point de départ, puis inspectez le fichier exporté.

Un piège courant est d’exporter tout à qualité 95 ou 100 parce que « ça fait plus sûr ». Sur la plupart des photos web, les octets en trop se voient dans le waterfall réseau, pas dans la page. Autre piège : forcer la qualité sous 50 pour atteindre une cible arbitraire. Si la qualité doit tomber si bas, redimensionnez ou changez de format avant de dégrader davantage.

Cibles de poids selon le rôle de la page

Ce ne sont pas des règles Google ni des seuils magiques de ranking. Ce sont des cibles pratiques pour repérer les images visiblement trop lourdes.

Si une image de blog à 760 px pèse 900 Ko, il y a probablement quelque chose à revoir. Si une image portfolio pleine largeur pèse 410 Ko et rend superbement, la ramener à 90 Ko n’est peut-être pas le bon objectif.

Compresser les images LCP et hero

L’image qu’il vaut le plus la peine d’optimiser est souvent la plus grande au-dessus de la ligne de flottaison. Dans le vocabulaire des Core Web Vitals, c’est fréquemment l’image du Largest Contentful Paint. La compresser aide, mais seulement si elle est aussi découverte et chargée tôt.

Pour un hero :

1. Recadrez-le au ratio réellement utilisé dans la page.
2. Exportez des largeurs responsive, par exemple 1200 px et 2000 px.
3. Utilisez AVIF en premier et WebP/JPEG en fallback si votre stack le permet.
4. Ne mettez pas de lazy-load sur le hero ni sur un autre candidat LCP au-dessus de la ligne de flottaison.
5. Ajoutez width et height pour que le navigateur réserve la place.
6. Utilisez fetchpriority="high" uniquement sur l’image la plus susceptible d’être l’élément LCP.

Exemple d’img de fallback :

<img
  src="/images/hero-1200.jpg"
  srcset="/images/hero-1200.jpg 1200w, /images/hero-2000.jpg 2000w"
  sizes="100vw"
  width="1200"
  height="800"
  fetchpriority="high"
  alt="Cuisine rénovée avec meubles en noyer et lumière naturelle"
/>

N’appliquez pas fetchpriority="high" à toute une galerie. Les hints de priorité sont des outils tranchants : réservez-en un à l’image qui doit vraiment arriver la première.

Comment comparer les résultats de compression

La bonne comparaison n’est pas « fichier original vs fichier compressé à 100 % de zoom ». C’est ainsi qu’on s’autorise à mettre en ligne des images surdimensionnées. Comparez à la taille et dans le contexte où les visiteurs voient l’image.

Passez cette revue :

1. Placez l’image compressée dans la vraie page ou une maquette de test de même largeur.
2. Regardez-la en largeur desktop et mobile.
3. Passez sur les zones à risque : visages, peau, ciel, dégradés, tissu, étiquettes produit, petit texte et arêtes très contrastées.
4. Basculez entre l’original et la version compressée à la taille rendue.
5. Zoomez brièvement à 100 % uniquement pour attraper les artefacts évidents, pas pour exiger une perfection que personne ne verra.

Les artefacts de compression ont leur personnalité. JPEG montre souvent des arêtes en blocs, du ringing ou du bruit de couleur. Un WebP trop compressé peut noyer la texture. AVIF peut produire du banding ou un aspect plastique s’il est trop poussé. Les captures PNG échouent en général dans l’autre sens : parfaites à l’œil mais bien trop lourdes.

Un workflow PhotoTools pour les images de site

PhotoTools est utile avant que l’image atteigne votre CMS, votre CDN ou votre dépôt. Il ne remplace pas une chaîne de build complète, mais il offre un workflow manuel propre pour les petits sites, les articles de blog, les previews client et les fichiers ponctuels.

1. Ne touchez pas au fichier source original.
2. Décidez du rôle de l’image : hero, image de contenu, photo produit, capture, vignette ou fond.
3. Utilisez Resize en premier quand l’original est bien plus grand que la taille d’affichage.
4. Ouvrez Compress, choisissez JPEG, WebP ou AVIF et partez de qualité 80 pour WebP/JPEG.
5. Cliquez sur « Compress all » et lisez, pour chaque carte, la taille d’origine, la taille de sortie et le pourcentage économisé.
6. Téléchargez le résultat et regardez-le dans le contexte de la page.
7. Si le rendu ne va pas, repartez de l’original ou de la copie redimensionnée et ré-exportez à qualité plus élevée.
8. Si c’est encore trop lourd, réduisez les dimensions avant de descendre la qualité vers la zone d’artefacts.

Ne recompressez pas en boucle le fichier déjà compressé — cela empile les artefacts. Repartez du master ou de l’intermédiaire redimensionné propre.

Métadonnées et confidentialité

Les fichiers d’appareils photo contiennent souvent des métadonnées EXIF : coordonnées GPS, date de prise de vue, modèle d’appareil, objectif, logiciel d’édition. Ces métadonnées n’aident pas le visiteur à voir l’image. Elles peuvent aussi exposer des informations privées.

PhotoTools compresse en décodant le fichier, en dessinant les pixels sur un canvas navigateur, puis en exportant un nouveau fichier. MDN documente que OffscreenCanvas.convertToBlob() peut préciser le type d’image et la qualité pour les formats qui gèrent la compression avec perte. Comme la sortie est générée à partir des pixels du canvas, les métadonnées d’appareil ne sont en général pas recopiées dans le nouveau fichier.

Pour des photos sensibles, vérifiez le fichier final avec un lecteur de métadonnées avant publication. La confidentialité ne se résume pas au poids du fichier.

Erreurs fréquentes qui rendent les images médiocres

• Compresser avant de redimensionner : vous cherchez à gagner des octets sur des pixels que la mise en page ne montrera jamais.
• Utiliser PNG pour des photos : PNG est en général énorme sur des images d’appareil.
• Utiliser JPEG pour des captures avec du texte : le fichier peut être plus petit, mais le texte devient flou.
• Juger à la mauvaise taille : le zoom en pleine résolution rend spectaculaires des artefacts anodins.
• Exporter un unique hero géant pour tous les appareils : les visiteurs mobiles téléchargent des pixels desktop inutiles.
• Mettre le hero en lazy-load : les images en dessous de la ligne de flottaison peuvent l’être ; l’image LCP, non.
• Pas de width ni de height : la page peut sauter pendant le chargement.
• Recompresser le fichier déjà publié : repartez de la source quand c’est possible.

Une checklist de publication compacte

Avant d’uploader une image de site, passez ceci en revue :

1. Est-ce le bon format pour ce type de contenu ?
2. La largeur source est-elle basée sur la vraie largeur d’affichage et un DPR plausible ?
3. Y a-t-il un candidat mobile plus petit si le cadrage du hero change sur mobile ?
4. La qualité est-elle assez haute pour les visages, les étiquettes, les dégradés et le détail produit ?
5. Le poids est-il raisonnable pour son rôle ?
6. La page contient-elle width, height, un alt utile et des srcset/sizes responsive quand c’est nécessaire ?
7. L’image LCP est-elle chargée en eager et priorisée, tandis que celles sous la ligne de flottaison sont en lazy-load ?
8. Avez-vous vérifié l’image exportée dans la vraie mise en page ?
9. Avez-vous conservé le fichier source ?

Le meilleur workflow de compression est ennuyeux dans le bon sens : choisir les bons pixels, choisir le bon format, exporter à une qualité raisonnable, inspecter dans la vraie page, et s’arrêter avant que l’image ne semble « retravaillée ».

Sources techniques consultées

Cet article a été relu par rapport à l’implémentation actuelle de compression et de redimensionnement de PhotoTools, au guide performance images de web.dev, à l’insight « Improve image delivery » de Chrome, à la fiche « Properly size images » de Chrome, à la documentation MDN sur OffscreenCanvas.convertToBlob(), au guide MDN des types de fichiers image et à la documentation WebP de Google.