Alléger les images de son site sans perdre en qualité

Pourquoi vos images ralentissent votre site

Les images sont le premier poste de poids d’une page web. D’après les relevés HTTP Archive cités par web.dev, une page médiane transfère environ 2 Mo, dont près de la moitié pour les seules images ; sur les pages du 90e centile, les images pèsent à elles seules 5 Mo. Aucun script, aucune police, aucune feuille de style n’approche ces volumes.

Ce poids se paie à l’endroit le plus visible. Sur plus de 70 % des pages web, le plus grand élément affiché à l’arrivée est une image : c’est donc une image que mesure le LCP (Largest Contentful Paint), l’indicateur de vitesse des Core Web Vitals de Google. Le seuil d’un bon LCP est fixé à 2,5 secondes, à tenir pour au moins 75 % des visites. Une photo mise en ligne telle qu’elle sort de l’appareil peut consommer ce budget à elle seule sur une connexion mobile.

Le diagnostic est gratuit et prend deux minutes : un audit Lighthouse — intégré aux outils de développement de Chrome et au service PageSpeed Insights — mesure le LCP de la page et signale une à une les images servies trop grandes ou dans un format dépassé. C’est le bon point de départ avant de toucher au moindre fichier.

C’est aussi le problème de performance le plus simple à corriger. Pas besoin de refondre le site ni de toucher au serveur. Le gros du gain tient en trois gestes, dans cet ordre : choisir le bon format, servir les bonnes dimensions, régler le taux de compression.

Quel format choisir : WebP par défaut, AVIF quand c’est possible

Pour une photo ou une capture d’écran, la réponse courte est WebP. À qualité visuelle égale, un fichier WebP pèse généralement 25 à 35 % de moins que son équivalent JPEG, selon les mesures publiées par web.dev. Sur du PNG photographique, l’écart est bien plus grand : Facebook a relevé 80 % d’économie en convertissant ses PNG en WebP, et 25 à 35 % sur ses JPEG. YouTube, de son côté, a gagné 10 % de temps de chargement en passant ses vignettes en WebP.

AVIF fait encore mieux sur la plupart des images : Netflix documente des réductions de poids importantes face au JPEG comme au WebP, sans avancer de pourcentage unique — le gain dépend du contenu. Le format est lu par Chrome et Opera depuis 2020, Firefox depuis 2021 et Safari depuis 2022 : le parc de navigateurs qui l’ignore se réduit chaque année, mais il existe encore.

Deux cas particuliers. Les logos, icônes et schémas relèvent du vectoriel : un SVG reste net à toutes les tailles et à toutes les densités d’écran, là où un PNG agrandi devient flou. Les animations, elles, ne devraient plus passer par le GIF : le format est limité à 256 couleurs et produit des fichiers nettement plus lourds qu’une courte vidéo — web.dev recommande l’élément <video> à la place.

Reste le cas du détail fin qui ne tolère aucun artefact — une capture d’interface destinée à une documentation, un visuel avec du texte petit. web.dev y réserve le PNG ou le WebP sans perte : on renonce à une partie du gain de poids pour garantir un rendu identique au pixel près.

Pour couvrir les anciens navigateurs, l’élément <picture> déclare la source WebP en premier et le JPEG en repli : chaque navigateur prend le premier format qu’il sait lire, et les plus anciens retombent sur la balise <img> finale.

Redimensionner d’abord : les dimensions pèsent plus que le taux

La plus grosse économie ne vient pas du curseur de qualité, elle vient des dimensions. Servir à un mobile une image taillée pour un écran de bureau transfère 2 à 4 fois plus de données que nécessaire, d’après web.dev. Une photo sortie d’un appareil récent mesure plusieurs milliers de pixels de large ; affichée dans une colonne de 800 pixels, l’essentiel de ces pixels est jeté après téléchargement.

Les écrans haute densité compliquent le calcul : un écran « 2x » ne double pas le nombre de pixels à fournir, il le quadruple. web.dev chiffre l’exemple d’une image affichée en 100 × 100 pixels CSS : 40 000 octets de données de pixels en densité simple, 160 000 en 2x, 360 000 en 3x. D’où une règle pratique : ne jamais mettre en ligne une image plus large que le double de sa largeur d’affichage maximale — le double suffit à servir les écrans 2x.

Concrètement, pour un site vitrine dont la colonne de contenu fait 800 pixels : exportez vos visuels à 1 600 pixels de large, pas au-delà. Une photo de 4 000 pixels mise en ligne telle quelle fait télécharger plus de six fois trop de données de pixels à la plupart des visiteurs, pour un rendu identique à l’écran.

Pour aller plus loin, les attributs srcset et sizes laissent le navigateur choisir la version adaptée à chaque appareil. Il est courant de produire 3 à 5 tailles du même visuel ; l’exemple de web.dev n’en déclare que deux, à 480 et 1 080 pixels de large, et couvre déjà l’essentiel des écrans. Un second passage de Lighthouse signale ensuite les images encore servies trop grandes.

Jusqu’où pousser la compression sans perte visible

Plus loin que vous ne l’imaginez. La compression avec perte supprime de l’information que l’œil ne distingue pas à taille d’affichage normale. web.dev en donne une démonstration directe : deux versions de la même photo, 20 Ko contre 12 Ko — 40 % de poids en moins, sans différence perceptible entre les deux.

Il n’existe pas de taux universel. Pour le JPEG, web.dev s’en tient à un conseil : essayer plusieurs niveaux de qualité et retenir le meilleur compromis entre rendu et poids. Le bon juge est votre écran, à la taille réelle d’affichage — pas un zoom à 400 % qu’aucun visiteur n’utilisera. L’outil ci-dessus applique cette méthode : vous déposez le fichier, vous comparez, vous téléchargez.

Le PNG obéit à une autre logique : c’est un format sans perte, dont le poids se joue sur la taille de la palette de couleurs, pas sur un curseur de qualité. Pour un logo en aplats, il reste correct ; pour une photo, il est presque toujours le mauvais choix — c’est précisément le cas où Facebook mesurait 80 % d’économie en basculant vers WebP.

Charger moins : lazy loading, priorité et espace réservé

Une image que le visiteur ne voit pas encore n’a pas besoin d’être chargée. L’attribut loading="lazy", posé sur la balise <img>, diffère le chargement des images situées hors écran ; le navigateur les récupère quand elles approchent de la zone visible — Chrome déclenche le chargement à 1 250 pixels de distance sur connexion rapide, 2 500 pixels sur connexion lente. Le coût est imperceptible : d’après les mesures de Chrome citées par web.dev, 97,5 % des images différées étaient complètement affichées dans les 10 millisecondes suivant leur entrée à l’écran, sur Android en 4G.

Une exception absolue : l’image principale en haut de page — le plus souvent l’élément LCP — ne doit jamais être différée. web.dev le formule sans nuance : différer l’image LCP ajoute un délai de chargement à l’élément que Google chronomètre. C’est l’inverse qu’il faut faire : lui donner la priorité avec l’attribut fetchpriority="high".

Dernier réglage, gratuit : déclarer width et height sur chaque image. Le navigateur réserve l’espace avant même le premier octet reçu, et la page ne saute plus pendant le chargement — c’est ce que mesure le CLS (Cumulative Layout Shift), dont le bon seuil est fixé à 0,1.

Questions fréquentes

Outils liés