Comment compresser les images d'un site web sans perdre de qualité

Si un audit de vitesse de page vous a déjà conseillé de « dimensionner correctement les images » ou « servir les images dans des formats de nouvelle génération », ce guide est la solution. Les images sont généralement les ressources les plus lourdes d'une page web, et les alléger est la modification de vitesse au meilleur rapport retour — bien moins coûteuse que de réécrire le JavaScript ou d'acheter un hébergement plus rapide. Bien faite, vos pages se chargent nettement plus vite, et personne ne remarque que les photos sont plus petites.

Ce guide vous donne le flux reproductible : exportez à la largeur d'affichage, compressez à une qualité douce, et convertissez les photos en WebP. Chaque étape est reliée au seuil Largest Contentful Paint actuel de Google, pour que vous n'ayez pas à deviner. L'ensemble du pipeline s'exécute dans votre navigateur — vos photos d'origine ne sont jamais envoyées vers un serveur.

Pourquoi les images sont votre gain de vitesse le plus rapide (LCP)

Les Core Web Vitals de Google mesurent l'expérience réelle des utilisateurs sur le terrain. La métrique que les images font le plus bouger est le Largest Contentful Paint (LCP) : l'instant où le plus grand élément visible à l'écran finit de se rendre. Sur les articles de blog, les pages de boutique et les pages d'atterrissage, ce plus grand élément est très souvent l'image d'en-tête — et non un paragraphe de texte. Une photo d'en-tête boursouflée de 4 MB retarde directement ce compteur.

Les classes LCP actuelles de Google, vérifiées sur la propre documentation Core Web Vitals de Google le 2026-10-06, sont :

Ces chiffres proviennent de données terrain de vrais utilisateurs au 75e percentile, mesurées séparément sur mobile et sur ordinateur. Le seuil « Bon » reste 2,5 secondes en 2026 — il n'a pas été abaissé à 2,0 secondes, malgré les rumeurs qui circulent sur certains blogs SEO. Les deux autres Core Web Vitals, INP et CLS, sont aussi affectés par les images (une largeur et une hauteur non déclarées provoque un décalage de mise en page), mais la compression fait surtout bouger le LCP.

Deux leviers : les dimensions d'abord, la qualité ensuite

La plupart des gens ouvrent un compresseur et font glisser un curseur de qualité. C'est le plus petit levier. Le plus grand consiste à expédier le bon nombre de pixels.

Levier 1 — servir les bonnes dimensions

Un appareil photo de téléphone produit une photo de 4000-6000 px de large. Si cette image s'affiche dans une colonne de contenu de 800 px de large, vous expédiez cinq fois plus de pixels que quiconque ne peut en voir. Redimensionner le bord long à environ la largeur d'affichage — au plus 2x pour les écrans retina — réduit à lui seul généralement le fichier de 60-80 %, sans aucune perte visible de qualité. C'est l'étape la plus efficace.

Levier 2 — puis réduire la qualité (avec perte)

Une fois les dimensions correctes, une compression avec perte modérée (autour de 75-85 % de qualité) taille un autre morceau sans changement perceptible. Faites-le dans cet ordre : compresser après le redimensionnement. Écraser la qualité d'un original pleine résolution gaspille de l'effort et produit des résultats en blocs.

Pas à pas : compresser les images pour le web

1. Exportez à la largeur d'affichage exacte. Sachez où l'image apparaît. Une image d'en-tête peut justifier ~1600-2400 px de large ; une image de contenu ~1200-1600 px ; une vignette ~400-600 px. Utilisez le redimensionneur d'image avec le ratio verrouillé, pour que largeur et hauteur évoluent ensemble. N'expédiez pas plus de 2x la taille d'affichage pour la retina.
2. Compressez avec perte à ~75-85 % de qualité. Déposez l'image redimensionnée dans le compresseur du navigateur et ajustez la qualité jusqu'à ce que le fichier se situe dans la bande cible ci-dessous. À 75-85 %, la plupart des gens ne voient pas la différence avec l'original.
3. Convertissez les photos en WebP. Un WebP à qualité égale est environ 25-35 % plus petit que le JPG équivalent. Lancez JPG en WebP pour les photographies et PNG en WebP pour les graphiques qui gardent la transparence. Servez un repli JPG avec un élément picture pour les navigateurs plus anciens.
4. Vérifiez les cibles de taille approximatives. Images d'en-tête sous ~200 KB, images de contenu sous ~100-150 KB, vignettes sous ~30-50 KB. Ce sont des bandes pratiques 2026, non une règle Google — ajustez selon votre design.

Si une image source est vraiment molle ou floue, corrigez cela avant de compresser : un léger passage d'amélioration récupère le détail proche mais petit, puis vous redimensionnez et compressez le résultat plus net. Si un portail exige aussi un KB exact (et non pas seulement un poids web), voyez le guide sur la compression à une taille de fichier cible pour cette méthode par dichotomie.

« Sans perte de qualité » — ce que cela signifie vraiment

L'expression « sans perte de qualité » sur cette page signifie perceptuellement sans perte à la taille d'affichage normale, et non identique bit pour bit. Les formats avec perte jettent des informations que l'œil remarque à peine (le fin détail des couleurs dans les ciels uniformes), et à 75-85 % de qualité le résultat paraît propre. Deux limites honnêtes s'appliquent :

• Pas de chaînes de réenregistrement. Chaque réenregistrement avec perte du même JPEG cumule les artefacts. Compressez toujours une fois depuis l'original, jamais depuis un export déjà compressé.
• Il n'y a pas de repas gratuit. Une photo de 4000 px écrasée à 50 KB paraîtra molle. La façon de garder la qualité perçue est le flux redimensionner d'abord ci-dessus, non un réglage magique.

Mémo des formats : JPG, PNG, WebP et AVIF

Choisissez le format selon la tâche. Bien choisir bat n'importe quel curseur de qualité.

L'AVIF comprime encore mieux que le WebP, mais PixlReady encode et exporte JPG, PNG et WebP uniquement — il ne produit pas d'AVIF. Si vous voulez de l'AVIF, il vous faut un outil séparé ; pour la plupart des sites, le WebP capture déjà l'essentiel du gain. Encore une règle : définissez toujours les attributs width et height sur vos balises <img> pour que le navigateur réserve l'espace — des dimensions non déclarées provoquent un décalage de mise en page (CLS), le troisième Core Web Vital.

Erreurs courantes qui ralentissent votre site

• Compresser avant de redimensionner. Vous gaspillez de l'effort à écraser une photo de 4000 px alors que la solution est d'expédier 1200 px. Redimensionnez d'abord, puis compressez.
• Expédier un PNG pour une photographie. Les photos en PNG sont 3 à 10 fois plus lourdes que la même photo en JPG ou WebP. N'utilisez le PNG que lorsque vous avez réellement besoin de transparence ou d'un graphique net.
• Recompresser un JPEG déjà compressé. Partez toujours de l'original. Réenregistrer un fichier qui avait déjà été enregistré à la qualité 60 empile les artefacts sur les artefacts.
• Oublier la largeur et la hauteur. Une image sans dimensions déclarées décale toute la page vers le bas lorsqu'elle se charge, ce qui nuit au CLS même après que le LCP est rapide.
• Utiliser un outil basé sur l'envoi pour des images sensibles. La plupart des compresseurs envoient votre fichier vers un serveur. Pour les photos produits, les photos client ou tout élément privé, utilisez un compresseur local, sans envoi — et voyez notre point de vue sur pourquoi un compresseur sans envoi importe.

Une fois vos images dimensionnées et compressées, vous voudrez peut-être le reste de la boîte à outils au même endroit — voyez notre sélection des meilleurs outils image en ligne gratuits de 2026.

Questions fréquentes