Diagnostic & performance

Pourquoi vos images ralentissent votre site (et comment y remédier)

Vous avez compressé vos images. Votre site est toujours lent. Ce guide identifie les 4 causes distinctes, pas toujours celles qu'on croit, et donne un ordre de traitement précis pour corriger le problème sans tout recommencer.

10 min de lecture Pourquoi vos images ralentissent votre site

En résumé

Les images ralentissent un site pour quatre raisons principales : poids excessif (JPEG >200 Ko pour une image décorative), mauvais format (PNG là où WebP économise 25-34 %), dimensions supérieures à l'affichage réel, et absence de chargement différé. Une seule image héroïque mal optimisée peut faire chuter le LCP au-delà de 2,5 secondes.

Ce qu'il faut retenir

✓ Il y a 4 causes distinctes : compresser seul ne résout pas les problèmes de résolution ou de lazy loading.
✓ Le format compte autant que la compression : PNG sur une photo JPEG en couleurs peut tripler le poids inutilement.
✓ Le LCP est l'image la plus lente visible sans scroll : c'est elle qui détermine votre score PageSpeed.
✓ L'ordre correct : redimensionner d'abord, compresser ensuite, convertir si nécessaire.

Les 4 causes réelles d’une image qui ralentit un site

Quand PageSpeed Insights signale un problème d’images, il identifie une ou plusieurs de ces quatre causes. Elles peuvent coexister, et souvent, c’est le cas.

1. Poids excessif. Une image JPEG de 1,5 Mo sur une fiche produit, c’est 8 à 10 fois ce que nécessite la page. Le navigateur la télécharge entière avant de pouvoir l’afficher.

2. Mauvais format. PNG sur une photo en couleurs, c’est le format le moins adapté. PNG est conçu pour les illustrations avec aplats et transparence, pas pour les photographies. Un JPEG bien compressé ou un WebP donnera le même rendu visuel pour 60 à 80 % de poids en moins, selon le contenu.

3. Dimensions trop grandes. Une image de 3 000 × 2 000 px affichée dans une colonne de 600 px de large. Le navigateur télécharge les 6 mégapixels, puis réduit l’affichage à 600 px. Le surplus de résolution ne sert à rien, et il pèse.

4. Absence de lazy loading. Toutes les images de la page se chargent en même temps au premier accès, y compris celles situées à 3 scrolls vers le bas. L’attribut loading="lazy" corrige ça : les images hors écran ne chargent qu’au moment où elles vont devenir visibles.

Poids ou résolution : quelle erreur fait le plus de dégâts ?

Les guides habituels insistent sur la compression. En pratique, une résolution excessive génère souvent plus de poids qu’un mauvais niveau de compression.

Exemple concret : une photo de produit à 4 096 × 2 731 px (typique sortie d’iPhone 15 Pro) pèse 4 à 6 Mo en JPEG qualité originale. Redimensionnée à 800 × 534 px (taille réelle d’affichage sur la majorité des colonnes de contenu), elle descend à 60-90 Ko avant même toute compression agressive. Compresser le fichier original à qualité 40 % vous amène peut-être à 800 Ko. Redimensionner d’abord vous en donne 80 Ko avec une qualité identique à l’écran.

Le rapport est de 1 à 10. La résolution gagne.

L’impact direct sur le LCP

Le LCP (Largest Contentful Paint) mesure le temps nécessaire pour afficher l’élément le plus grand visible sans scroll. Dans la grande majorité des pages, cet élément est une image : le hero, la photo de couverture, la première image d’article.

Google considère un LCP inférieur à 2,5 secondes comme satisfaisant. Entre 2,5 et 4 secondes, il y a matière à améliorer. Au-delà de 4 secondes, c’est une pénalité dans les signaux de classement.

L'erreur la plus fréquente sur le LCP

Utiliser loading="lazy" sur l’image hero. C’est l’inverse de ce qu’il faut faire : l’image hero est l’image LCP par définition, elle doit se charger en priorité, pas être différée. Réservez loading="lazy" aux images situées sous le premier écran.

Une image LCP mal optimisée cumule souvent les 4 problèmes à la fois : trop grande, mauvais format, trop lourde, et parfois lazy-loadée par erreur. Corriger l’un sans les autres améliore le score, mais pas suffisamment.

Compresser vs redimensionner : dans quel ordre et pourquoi

L’ordre n’est pas anodin. Compresser une image de 4 000 px de large, c’est travailler sur beaucoup plus de données que nécessaire. Le résultat sera moins bon pour un même niveau de qualité visuelle.

Ordre d'optimisation recommandé

1

Redimensionner aux dimensions réelles d'affichage

Identifiez la largeur maximale à laquelle l'image sera affichée (via les outils de développement du navigateur ou la maquette). Redimensionnez à cette valeur + 2x pour les écrans Retina si nécessaire.

Pour une colonne de 800 px de large, une image de 1 600 px suffit même sur les écrans haute densité.
2

Compresser l'image redimensionnée

Appliquez la compression sur le fichier aux bonnes dimensions. Le résultat sera meilleur : moins de données à encoder, taux de compression plus efficace pour la même qualité visuelle.

Qualité 80-85 % en JPEG ou WebP donne un résultat visuellement identique à 100 % pour 60 à 70 % du poids en moins.
3

Convertir au format adapté si nécessaire

Si votre image est en PNG et qu'elle ne contient pas de transparence, convertissez-la en WebP ou JPEG. WebP est supporté par 97 % des navigateurs modernes et économise 25-34 % de poids vs JPEG à qualité équivalente.

PNG reste pertinent pour les logos, icônes et captures d'écran avec texte, pas pour les photographies.

Quel format choisir selon votre cas

Le choix du format est la deuxième levier d’optimisation après la résolution. En pratique, trois formats couvrent 95 % des besoins web.

Formats d'image web : quel format pour quel usage

Format	Compression	Transparence	Support navigateur	Usage recommandé
JPEG	Avec perte, excellent pour les photos	Non	100 %	Photos, images complexes en couleurs si WebP non disponible
WebP	Avec perte ou sans perte, 25-34 % moins lourd que JPEG	Oui	~97 %	Recommandé par défaut pour toutes les images web
AVIF	Avec perte ou sans perte, 20-50 % moins lourd que WebP	Oui	~94 %	Images haute qualité, encoder plus lent, à tester selon workflow
PNG	Sans perte uniquement	Oui (canal alpha)	100 %	Logos, icônes, captures d'écran avec texte, images avec transparence

Taux de compression WebP vs JPEG : Google Web.dev. Support navigateur : caniuse.com (mai 2026). AVIF : encodage CPU intensif sans accélération matérielle, à évaluer selon le volume.

WebP est le bon choix par défaut. 97 % de support navigateur, compression efficace, transparence supportée. AVIF est techniquement supérieur, mais l’encodage est plus lent et le gain réel dépend du contenu. Selon le contexte, le surcoût d’encodage peut dépasser le bénéfice.

Lazy loading et images responsives : ce que beaucoup oublient

Deux attributs HTML changent radicalement le comportement de chargement des images. Ils ne nécessitent aucun outil externe, juste un ajout dans le code.

loading="lazy" : indique au navigateur de ne charger l’image qu’au moment où elle entre dans le viewport. À utiliser sur toutes les images situées sous le premier écran. À ne jamais utiliser sur l’image hero ou l’image LCP.

srcset et sizes : permettent de servir plusieurs versions de l’image selon la résolution de l’écran. Un visiteur sur mobile reçoit une image de 480 px. Un visiteur sur desktop reçoit 1 200 px. La bande passante est utilisée efficacement dans les deux cas.

<img
  src="image-800.webp"
  srcset="image-480.webp 480w, image-800.webp 800w, image-1200.webp 1200w"
  sizes="(max-width: 600px) 480px, (max-width: 1024px) 800px, 1200px"
  loading="lazy"
  width="800"
  height="534"
  alt="Description de l'image"
/>

Les attributs width et height méritent aussi d’être mentionnés. Leur absence cause du CLS (Cumulative Layout Shift), visible à l’œil nu comme un “saut” de page pendant le chargement. Indiquer les dimensions à l’avance réserve l’espace et élimine ce problème.

Diagnostic : mesurer l’impact de vos images avec PageSpeed

Avant de corriger quoi que ce soit, mesurez. Google PageSpeed Insights est gratuit et accessible depuis n’importe quel navigateur. Il identifie précisément les images qui posent problème, leur poids actuel, et le gain estimé après optimisation.

Trois sections à regarder en priorité dans le rapport :

“Properly size images” : liste les images dont les dimensions dépassent les dimensions d’affichage réelles. Redimensionner règle ce problème.

“Serve images in next-gen formats” : liste les images non converties en WebP ou AVIF. Le gain estimé en Ko est affiché directement.

“Defer offscreen images” : liste les images sans loading="lazy" situées hors du premier écran.

Chrome DevTools permet d’aller plus loin : l’onglet Network avec filtrage “Img” montre le poids réel de chaque image et son temps de chargement. L’onglet Performance identifie l’image LCP et son temps de rendu précis.

Compresser et convertir vos images directement dans le navigateur : utiliser Impmage : traitement 100% local, aucune donnée envoyée

Questions fréquentes

Quelle taille en Ko est recommandée pour une image sur un site web ? ▾

Il n'existe pas de règle universelle, mais des repères utiles : une image décorative ou de fond sous 100 Ko, une image d'article entre 80 et 150 Ko, une image hero entre 150 et 300 Ko. Ces valeurs dépendent du format, de la résolution et du contenu. En pratique, mesurer le LCP après optimisation est plus fiable que viser un chiffre absolu.

Pourquoi mon site est-il encore lent après avoir compressé mes images ? ▾

La compression ne règle qu'une des quatre causes. Si vos images ont des dimensions trop grandes (ex : 4 000 px pour une colonne de 800 px), compresser ne suffit pas : le navigateur télécharge quand même les mégapixels inutiles. Si vous n'utilisez pas `loading='lazy'` sur les images hors écran, toutes se chargent simultanément au premier accès. Vérifiez les quatre causes séparément via PageSpeed Insights.

Quelle différence entre poids d'image et résolution ? ▾

La résolution est le nombre de pixels (ex : 1 920 × 1 080 px). Le poids est la taille du fichier en Ko ou Mo, qui dépend de la résolution, du format et du niveau de compression. Une image haute résolution peut être légère si elle est bien compressée en WebP. Une image basse résolution peut être lourde si elle est en PNG non optimisé.

Est-ce que le format WebP est vraiment supporté partout ? ▾

WebP atteint ~97 % de support navigateur en 2026 (source : caniuse.com). Les seuls navigateurs qui ne le supportent pas sont des versions très anciennes d'Internet Explorer et Opera Mini. En pratique, le cas non-WebP concerne moins de 3 % du trafic web global. L'utilisation de `<picture>` avec fallback JPEG reste possible pour les cas critiques.

Est-ce qu'il faut compresser ou redimensionner en premier ? ▾

Redimensionner d'abord. Compresser une image de 4 000 px pour une colonne de 800 px, c'est travailler sur 25 fois plus de pixels que nécessaire. Réduire d'abord les dimensions aux valeurs réelles d'affichage, puis compresser : le résultat est meilleur pour un poids final identique ou inférieur.

Qu'est-ce que le LCP et pourquoi est-ce important pour les images ? ▾

Le LCP (Largest Contentful Paint) mesure le temps d'affichage de l'élément le plus grand visible sans scroll : dans la majorité des cas, une image. Google considère un LCP sous 2,5 secondes comme satisfaisant. C'est l'un des trois Core Web Vitals qui influencent le classement dans les résultats de recherche. L'image LCP doit être chargée en priorité, jamais en lazy loading.

Loading lazy sur toutes les images, c'est une bonne pratique ? ▾

Non. `loading='lazy'` est pertinent sur les images situées sous le premier écran : celles que l'utilisateur ne voit qu'après avoir scrollé. Sur l'image hero ou la première image visible, lazy loading retarde le LCP et pénalise directement le score PageSpeed. La règle : lazy loading sur tout sauf l'image LCP.