Comment optimiser vos images pour ne pas ralentir le site

Un jour, une cliente m'appelle, paniquée : son site mettait 6,4 secondes à s'afficher sur mobile. Elle venait de payer une refonte, le design était impeccable, le code propre. Le coupable ? Une bannière de 4,2 Mo en PNG. La même image, une fois passée en WebP puis redimensionnée à la taille réelle d'affichage, pesait 78 Ko. Six secondes de chargement effacées par un fichier qu'elle aurait pu corriger en dix minutes. On parle souvent d'optimiser son site en ajoutant des plugins, en minifiant le CSS, en changeant d'hébergeur. On oublie que la première cause de lenteur, dans la grande majorité des sites que j'ai audités, ce sont les images.

Pourquoi les images ralentissent votre site plus que le reste

Le HTML d'une page fait quelques dizaines de kilo-octets. Le CSS et le JavaScript, souvent moins de 500 Ko. Une seule photo mal exportée dépasse à elle seule tout le reste réuni. J'ai vu des sites où trois images représentaient 80 % du poids total de la page. Le navigateur doit télécharger chaque fichier avant de pouvoir afficher quoi que ce soit : plus une image est lourde, plus l'utilisateur fixe un écran blanc.

Et là, ce n'est pas juste une question de patience. Google mesure ce délai, notamment via le LCP (Largest Contentful Paint), qui correspond au moment où l'élément principal de la page — très souvent une image — devient visible. Le seuil à viser est de 2,5 secondes. Au-delà, l'expérience est jugée médiocre. Une image hero qui met trois secondes à se charger à elle seule plombe tout le score.

Quel est le lien entre images et Core Web Vitals ?

Deux indicateurs sont directement concernés. Le LCP, d'abord : si votre image principale est lourde ou mal priorisée, le LCP explose. Le CLS (Cumulative Layout Shift), ensuite : quand les dimensions d'une image ne sont pas déclarées dans le HTML, le navigateur ignore l'espace qu'elle va occuper. Résultat, la page « saute » au moment où l'image arrive, et ce décalage est pénalisé. La solution est simple et je le répète à chaque audit : indiquez toujours width et height, ou utilisez un ratio via CSS sur le conteneur.

Une image bien optimisée ne fait pas que gagner du temps. Elle stabilise la mise en page, améliore le ressenti, et évite ce petit sursaut agaçant quand on est en train de lire.

Choisir le bon format : le premier levier, souvent négligé

Avant même de compresser, il faut se poser une question basique : ce fichier est-il dans le bon format ? Beaucoup de gens exportent tout en JPEG par habitude, ou gardent des PNG partout parce qu'ils ont « toujours fait comme ça ». C'est une erreur qui coûte cher.

JPEG, PNG, WebP ou AVIF : lequel pour quoi ?

La règle de base tient en une ligne : photo sans transparence = format avec perte ; logo, icône ou texte avec transparence = format sans perte. Mais depuis quelques années, deux formats changent la donne : WebP et surtout AVIF.

Format	Idéal pour	Transparence	Poids relatif
JPEG	Photos	Non	Référence
PNG	Logos, captures	Oui	Lourd
WebP	La plupart des cas	Oui	Bien plus léger que JPEG à qualité égale
AVIF	Photos haut de gamme	Oui	Le plus compact, mais encodage plus lent

Dans mes tests, une même photo de paysage exportée en JPEG de qualité 85, puis en WebP de qualité 80, perdait en général entre 25 et 35 % de son poids sans différence visible à l'œil nu. En AVIF, le gain monte parfois à 50 %, mais le support navigateur est plus récent, donc prévoyez un fallback.

Comment gérer un format récent sans casser l'affichage ?

La balise <picture> est faite pour ça. Vous servez l'AVIF en priorité, puis le WebP, puis le JPEG en secours. Le navigateur choisit le premier qu'il comprend, et les vieux navigateurs tombent sur le JPEG. Personne ne voit la différence, tout le monde y gagne.

<picture>
  <source srcset="photo.avif" type="image/avif">
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" alt="Description" width="1200" height="800">
</picture>

Avouons-le : la première fois que j'ai installé ça, j'ai oublié le <img> de secours. Résultat, plus rien ne s'affichait sur un vieux navigateur. Une heure perdue pour un oubli de deux lignes.

Redimensionner et compresser : les deux gestes qui changent tout

Une image de 4000 pixels de large affichée dans un cadre de 800 pixels, c'est quatre fois trop de données pour rien. Le navigateur les télécharge toutes, puis les réduit lui-même. Autant lui donner directement la bonne taille. C'est le geste que je vois le plus souvent oublié, et pourtant c'est celui qui rapporte le plus vite.

Concrètement : déterminez la largeur d'affichage réelle, multipliez par deux maximum pour les écrans haute densité, et exportez à cette dimension. Une bannière pleine largeur plafonne souvent autour de 1920 px. Une image dans un article, 1200 px suffisent largement.

Quels outils utiliser pour compresser ?

Vous n'avez pas besoin de logiciels payants. Les outils en ligne font le travail correctement : TinyPNG, Squoosh, ou les extensions de compression intégrées à votre CMS. Sur WordPress, plusieurs plugins automatisent la conversion WebP et la compression à l'upload. Mais attention : un plugin mal configuré peut recompresser vos images à chaque page vue.

• Compression avec perte : réduit fortement le poids, à réserver aux photos.
• Compression sans perte : gain plus modeste (souvent 10-20 %), mais zéro risque visuel — parfait pour les logos.
• Un réglage de qualité entre 75 et 85 donne presque toujours un résultat invisible à l'œil.

Franchement, si vous ne devez retenir qu'une chose de cette section : ne dépassez jamais 200 Ko par image de contenu courant, et visez moins de 100 Ko quand c'est possible. C'est un repère, pas une loi, mais il évite les dérapages.

srcset, lazy loading et priorité : le HTML qui fait le boulot

Optimiser le fichier ne suffit pas. Il faut aussi dire au navigateur comment se comporter. Trois attributs font l'essentiel, et ils sont rarement bien utilisés.

Comment fonctionnent srcset et sizes ?

srcset permet de fournir plusieurs versions d'une même image à des tailles différentes, et sizes indique au navigateur la largeur d'affichage attendue selon la taille de l'écran. Le navigateur choisit alors la version la plus adaptée : un mobile ne téléchargera pas la version 1920 px destinée au desktop. C'est ce qui rend le responsive réellement efficace.

Faut-il mettre toutes les images en lazy loading ?

Non, et c'est une erreur fréquente. Le lazy loading (loading="lazy") retarde le chargement des images qui ne sont pas encore visibles. Excellent pour une galerie en bas de page. Catastrophique pour l'image principale en haut de page : elle se chargerait trop tard et ferait grimper le LCP. Pour celle-là, faites l'inverse — ajoutez fetchpriority="high" et surtout pas de lazy.

• Image au-dessus de la ligne de flottaison : jamais en lazy, priorité haute.
• Images du contenu visible au scroll : lazy loading recommandé.
• Logo du header : légèrement compressé, jamais en lazy, et préchargé si possible.

Le problème ? Personne ne teste vraiment. On ajoute l'attribut partout « pour la performance » et on se retrouve avec une image hero qui arrive en dernier. J'ai fait cette bêtise sur mon propre blog pendant des mois avant de comprendre d'où venait le décalage.

Mesurer avant et après : la seule preuve qui compte

Sans chiffres, vous optimisez à l'aveugle et vous ne saurez jamais ce qui a marché. Avant de toucher quoi que ce soit, passez votre page dans PageSpeed Insights ou WebPageTest, et notez le poids total des images. Regardez le waterfall : la liste des fichiers téléchargés dans l'ordre, avec leur taille et leur durée. La coupable saute aux yeux presque à chaque fois.

Sur un site que j'ai repris, le poids des images de la page d'accueil est passé de 5,8 Mo à 620 Ko en changeant de format, en redimensionnant et en activant le lazy loading correctement. Score mobile : de 41 à 92. Temps de chargement perçu : divisé par trois. Aucune ligne de code nouvelle, juste de bons fichiers et trois attributs bien placés.

Les questions qu'on me pose le plus souvent

Combien doit peser une image idéale ?

Il n'y a pas de chiffre unique, tout dépend de sa taille d'affichage. Un repère utile : une image de contenu courant devrait rester sous les 150 à 200 Ko. Un logo ou une icône, quelques kilo-octets suffisent. Une grande bannière peut monter un peu, mais rarement au-delà de 300 Ko une fois bien optimisée. Si un fichier dépasse 1 Mo, il y a presque toujours quelque chose à corriger.

Faut-il passer par un CDN d'images ?

Pour un petit site, non : la conversion WebP et le redimensionnement suffisent. Pour un site avec des centaines d'images, un catalogue produit ou beaucoup de trafic international, un service d'images dédié (Cloudinary, Imgix et leurs équivalents) devient rentable. Il gère automatiquement le format selon le navigateur, redimensionne à la volée et distribue depuis des serveurs proches de vos visiteurs. C'est du confort, mais parfois le confort qui sauve une page.

Est-ce que compresser dégrade vraiment la qualité visible ?

Non, tant que vous restez dans des réglages raisonnables. Une photo compressée à qualité 80 reste indiscernable de l'originale dans l'immense majorité des cas. La dégradation devient visible quand on descend trop bas ou qu'on recompresse plusieurs fois le même fichier. Partez toujours de l'original, jamais d'une version déjà compressée.

Au fond, optimiser ses images ne demande pas de compétence technique particulière. Juste un peu de rigueur, un format adapté, la bonne taille, et trois attributs HTML bien posés. Ce qui m'étonne après tout ce temps, c'est qu'on continue à chercher des solutions compliquées — changer d'hébergeur, empiler les plugins — alors que la réponse tient souvent dans un dossier d'images qu'on n'a jamais rouvert depuis la mise en ligne.