Une page qui met huit secondes à s'afficher sur un mobile en 4G, vous l'avez tous vue. Et dans neuf cas sur dix, le coupable n'est pas le serveur, ni le JavaScript, ni le thème WordPress acheté à 40 euros. Ce sont les images. Elles pèsent entre la moitié et les deux tiers du poids total d'une page web, et c'est le premier levier sur lequel j'agis quand je reprends un site.
Optimiser les images pour réduire le poids et améliorer le référencement, ce n'est pas une case à cocher dans un plugin. C'est une chaîne de décisions : le bon format, la bonne dimension, le bon niveau de compression, le bon chargement. Faites-les dans le désordre et vous n'obtiendrez rien de mesurable.
Points clés à retenir
- Le poids des images est le premier facteur de lenteur d'une page, donc l'un des premiers leviers du LCP (Largest Contentful Paint).
- Servir une image en WebP ou en AVIF au lieu d'un JPEG coûte 25 à 35 % de poids en moins, à qualité visuelle identique.
- Le format ne sauve rien si vous envoyez une image de 4000 pixels de large dans un conteneur de 800 pixels.
- Le nom de fichier et l'attribut alt restent les deux signaux sémantiques que Google Images lit directement.
- Le lazy loading doit être réservé aux images sous la ligne de flottaison. Appliqué à tout, il dégrade le LCP.
Pourquoi le poids des images plombe votre référencement
Google ne classe pas un site sur sa vitesse au sens vague. Il mesure des métriques précises, et deux d'entre elles concernent directement vos images : le LCP, qui mesure le moment où le plus gros élément visible s'affiche, et le CLS, qui pénalise les décalages de mise en page. Sur la grande majorité des pages, l'élément LCP est une image : la bannière du haut, le visuel d'article, la photo produit.
Le LCP, expliqué simplement
Imaginez un visiteur. Il tape votre adresse, la connexion s'établit, le HTML arrive, le CSS arrive. Tout est prêt. Sauf que le navigateur attend encore les 2,4 Mo de la photo d'en-tête pour afficher quoi que ce soit de lisible. Pendant ce temps, le chrono tourne.
Le LCP est donc le temps qu'attend l'internaute avant de voir enfin quelque chose. Réduire ce délai ne se joue pas au niveau du serveur applicatif : ça se joue sur le poids du fichier image envoyé. Sur un ancien projet e-commerce, j'ai fait passer la bannière d'accueil de 780 Ko en JPEG à 96 Ko en WebP et 800 pixels de large. Le LCP mobile est passé de 4,8 s à 2,1 s. Le reste n'avait pas bougé d'un pixel.
Le trafic de Google Images existe vraiment
Sur un blog de recettes que je suis depuis longtemps, entre 8 et 12 % des sessions arrivent depuis la recherche d'images, selon la saison. Ce sont des visiteurs qui ne vous auraient jamais trouvé autrement. Encore faut-il que vos fichiers portent un nom compréhensible autre que IMG_20260412_184521.jpg.
Choisir le bon format pour réduire le poids
Aucun format n'est meilleur dans l'absolu. Le bon choix dépend de ce que l'image représente : une photo, un logo, une capture d'écran, une illustration.
| Format | Idéal pour | Poids relatif | Transparence |
|---|---|---|---|
| JPEG | Photos, arrière-plans complexes | Référence | Non |
| WebP | Presque tout, photos et graphiques | −25 à −35 % | Oui |
| AVIF | Photos de grande taille | −40 à −50 % | Oui |
| PNG | Captures d'écran, aplats de couleur | Lourd sur photo | Oui |
| SVG | Logos, icônes, illustrations vectorielles | Quelques Ko | Oui |
WebP ou AVIF : lequel prendre en 2026 ?
Le débat est tranché pour moi. L'AVIF compresse mieux, mais il coûte plus cher à encoder et reste plus lent à décoder sur les téléphones d'entrée de gamme. Le WebP, lui, est pris en charge partout depuis des années. Mon choix par défaut : WebP, et AVIF uniquement sur les visuels de très grande taille où le gain de poids dépasse 30 %.
Pour les logos et les pictos, oubliez le PNG. Un SVG de 3 Ko remplace sans perte un PNG de 40 Ko, et il reste net sur tous les écrans.
Le piège du PNG sur les photos
J'ai longtemps vu des boutiques envoyer des photos produits en PNG « pour la qualité ». Une photo en PNG pèse trois à cinq fois le JPEG équivalent. Le PNG est un format de compression sans perte : il n'a aucun intérêt sur une image photographique, où l'œil ne distingue pas les micro-détails perdus en JPEG.
Redimensionner avant de compresser
Voilà l'erreur que je vois le plus souvent, et de loin. Une image de 4032 pixels de large issue d'un smartphone, affichée dans une colonne de 760 pixels. Inutile de parler de compression tant que ça n'est pas réglé : vous compressez dix fois plus de pixels que nécessaire.
La règle de base, en 2026 : doublez la largeur d'affichage pour couvrir les écrans haute densité, et pas un pixel de plus. Une image qui s'affiche sur 800 pixels de large se sert en 1600 pixels maximum.
- Bannière pleine largeur : 1920 px, pas 4000.
- Image d'article dans une colonne : 1200 px.
- Vignette de liste : 400 px.
- Logo : SVG, ou 200 px carrés en secours.
L'attribut srcset fait le reste côté navigateur : il choisit le fichier adapté à la largeur de l'écran. Vous fournissez trois tailles, il n'en télécharge qu'une.
Trouver le bon compromis entre qualité et poids
Question qu'on me pose souvent : « à combien je règle la qualité ? ». Réponse courte : 80 en WebP, 75 à 80 en JPEG. En dessous, les dégradés et les visages commencent à baver. Au-dessus de 85, vous ajoutez du poids pour un gain invisible.
Vérifier à l'œil plutôt qu'au pourcentage
Un chiffre de qualité ne dit rien de la perception. Ma méthode, que j'applique systématiquement : j'exporte la même image à 70, 80 et 90, je les ouvre côte à côte en zoom 100 % sur les zones à fort contraste (contours, texte incrusté, dégradés de ciel), et je prends la qualité la plus basse qui reste indiscernable. Sur une photo de paysage bien éclairée, 70 suffit souvent. Sur une capture d'écran avec du texte fin, il faut monter à 90, ou passer en PNG.
Une chaîne d'outils concrète
Un principe sans outil ne sert à rien. Voici ce que j'utilise réellement, du cas ponctuel à l'automatisation.
Pour une image de temps en temps
Squoosh dans le navigateur : vous déposez le fichier, vous comparez deux rendus côte à côte avec un curseur, vous exportez. C'est gratuit et ça ne nécessite aucune installation. Pour un lot de vingt photos, ImageOptim sur Mac fait le travail en glisser-déposer.
Pour un site qui publie tous les jours
À ce stade, la conversion manuelle devient une corvée qu'on finit par sauter. Deux options :
- Un plugin côté CMS qui convertit à l'upload et sert du WebP avec repli automatique.
- Un CDN d'images (Cloudinary, Imgix, ou le service d'un hébergeur) qui redimensionne, convertit et sert selon le navigateur, à la volée.
J'ai fait les deux. Le CDN coûte de l'argent mais m'a fait gagner un temps considérable sur un catalogue de 4 000 références. Sur un blog de 200 articles, le plugin suffit largement.
Pour un site qui se construit automatiquement
Si votre site est généré par un build (Next.js, Astro, Hugo), branchez Sharp ou ImageMagick dans la chaîne : chaque image est redimensionnée et convertie au moment de la compilation. Plus aucune image non optimisée ne peut partir en production. C'est la seule méthode qui tienne dans le temps, parce qu'elle ne dépend de la discipline de personne.
Ce qui fait vraiment la différence côté référencement
Le poids règle la vitesse. Il ne règle pas la compréhension de l'image par les moteurs. Deux attributs s'en chargent.
Le nom de fichier
chaise-bureau-ergonomique-noire.webp dit quelque chose. IMG_4821.webp ne dit rien. Renommez avant l'upload : c'est gratuit et ça prend trois secondes.
L'attribut alt
L'alt décrit l'image pour qui ne la voit pas, et sert de signal sémantique aux moteurs. Décrivez ce que montre l'image, sans empiler les mots-clés. « Chaise de bureau ergonomique noire, dossier réglable » est un bon alt. « chaise bureau pas cher achat chaise ergonomique » est du bourrage, et ça se voit.
Et le lazy loading, alors ?
À appliquer avec parcimonie. loading="lazy" sur toutes les images sous la ligne de flottaison : oui. Sur l'image d'en-tête : non, jamais. Vous retarderiez le chargement de l'élément LCP et vous dégraderiez exactement la métrique que vous cherchez à améliorer. Réservez le lazy au contenu que l'on découvre en défilant.
Un dernier point, souvent oublié : réservez les dimensions de vos images dans le HTML (attributs width et height, ou ratio d'aspect en CSS). Sans cela, le navigateur ne sait pas quelle place laisser, la page saute au chargement, et le CLS en prend un coup.
Rien de tout cela n'est spectaculaire. Pas de raccourci magique, pas de plugin miracle qui règle tout d'un clic. Juste une chaîne de gestes simples, appliqués dans le bon ordre, du redimensionnement à l'alt en passant par le format. Et si vous ne devez retenir qu'une chose : commencez par regarder la taille réelle de vos fichiers dans l'inspecteur réseau. La surprise est souvent là, dans le premier onglet ouvert.
