Optimiser les images web : le coupable numéro un du poids de ta page

Quand une page est lente, le premier réflexe est d'accuser le JavaScript. Souvent à tort. Sur la page médiane du web, les images pèsent plus que tout le reste réuni, CSS, polices et scripts compris, d'après le Web Almanac 2025 de HTTP Archive, où la page d'accueil médiane pèse 2,86 Mo sur desktop. C'est le poste de poids numéro un, et c'est aussi le plus facile à corriger, parce qu'une image trop lourde ne demande pas de refondre ton code. Elle demande juste de la traiter correctement.

Les couvertures de ce blog pèsent toutes moins de 70 Ko, en WebP, avec leurs dimensions déclarées et un chargement différé sous la ligne de flottaison. Voici les quatre leviers qui font la différence, et pourquoi ils touchent directement ta conversion.

Le mécanisme : ton image de hero EST souvent ton LCP

Sur la majorité des pages, le plus gros élément affiché au premier rendu, celui que mesure le LCP, est une image. Ton hero, ta capture produit, ta photo de couverture. Donc le temps que met cette image à se charger, c'est le temps que ton visiteur passe à fixer une page à moitié vide.

Une image de hero en PNG de 1,8 Mo non dimensionnée fait deux dégâts d'un coup. D'abord elle retarde le LCP de plusieurs secondes, parce que le navigateur doit la télécharger entièrement avant de l'afficher. Ensuite, si tu n'as pas déclaré ses dimensions, elle provoque un saut de page au moment où elle apparaît, ce qui dégrade ton CLS. Une seule image négligée, et tu touches deux des trois Core Web Vitals.

La bonne nouvelle, c'est que cette même image, servie en WebP ou en AVIF, correctement dimensionnée, peut tomber à 60 ou 80 Ko sans perte visible. Le même visuel, vingt fois plus léger. Aucune autre optimisation ne t'offre ce rapport effort sur gain.

Et le problème empire sur mobile, là où se joue l'essentiel de ton trafic. Servir la même image de 2000 pixels de large à un téléphone qui n'en affiche que 380, c'est lui faire télécharger cinq fois le poids nécessaire, sur une connexion souvent plus lente que la tienne. Une image responsive, déclinée en plusieurs tailles, laisse le navigateur choisir la version adaptée à l'écran. Le visiteur sur grand écran reçoit la grande, celui sur téléphone reçoit la petite, et personne ne paie pour des pixels qu'il ne verra jamais. C'est ton trafic le plus fragile, le mobile, qui profite le plus de ce seul réglage.

Et sur une page de produit SaaS, le problème se multiplie. Tu n'as pas une image mais une galerie de captures d'écran, chacune lourde, chacune qui s'additionne au poids total. Optimiser un seul fichier change peu de chose, optimiser le poste entier change la page. C'est pour ça qu'on traite les images comme un système avec des règles fixes, pas comme des fichiers qu'on corrige un par un quand on y pense.

La prise de position : c'est le plus gros gain, et le moins fait

L'optimisation des images est le levier le plus rentable du web, et c'est paradoxalement celui qu'on saute le plus souvent. Parce qu'il n'est pas glorieux. Réécrire son architecture, isoler ses composants, traquer un chunk JavaScript, ça fait sérieux. Compresser une image, ça fait petit. Alors on s'attaque au difficile et on laisse traîner le facile.

C'est une erreur de priorité. Quand un poste représente la moitié du poids de ta page et qu'il se règle en une passe d'outillage, c'est par lui qu'on commence, pas par lui qu'on finit. Le travail ingrat sur le JavaScript vient après, une fois que tu as cueilli le fruit le plus bas.

Et le gain n'est pas qu'une question de score. Une page qui s'affiche en une seconde au lieu de quatre, c'est un visiteur qui reste au lieu de rebondir, qui lit ton offre au lieu de fermer l'onglet. L'image lente ne te coûte pas des millisecondes abstraites, elle te coûte des gens qui n'ont jamais vu ce que tu vends. C'est d'ailleurs pour ça qu'un beau site peut quand même être lent, quand le soin visuel se paie en poids.

Teardown : le pipeline visuel de ce blog

Voilà comment je traite chaque visuel de ce blog, et ce que ça donne face à une version négligée.

• Format. Tout est en WebP. Un PNG de couverture qui pèserait 1,5 Mo tombe sous 70 Ko en WebP à qualité équivalente à l'oeil. L'AVIF descend encore plus bas quand le navigateur le supporte.
• Dimensions. Chaque image est rendue à la taille réelle d'affichage, pas à 4000 pixels de large redimensionnés par le navigateur. Une couverture est en 1200 par 630, une figure en 1600 par 900, point.
• Chargement. La couverture en haut de page est préchargée pour ne pas retarder le LCP. Les figures plus bas sont en chargement différé, elles ne se téléchargent qu'à l'approche du visiteur.
• Dimensions déclarées. La largeur et la hauteur sont posées dans le HTML, donc le navigateur réserve la place avant même de charger l'image. Zéro saut de page, zéro pénalité de CLS.
• Déclinaisons responsive. Chaque visuel existe en plusieurs largeurs, et le navigateur télécharge celle qui correspond à l'écran. Un téléphone ne tire jamais la version pensée pour un grand moniteur.

Une couverture négligée à l'inverse : un PNG de 1,5 Mo, servi en pleine résolution, sans preload et sans dimensions. Elle retarde le LCP, fait sauter la mise en page, et pèse à elle seule plus que tout le reste de la page. Le même emplacement, deux mondes.

L'artefact : les 4 leviers, dans l'ordre

Pour chaque image que tu sers, passe les quatre points. Dans cet ordre, parce qu'ils se renforcent.

1. Format. Sers en WebP par défaut, en AVIF si tu peux gérer le repli. Garde le PNG uniquement pour les visuels qui exigent la transparence nette, et le JPEG pour rien.
2. Dimensions réelles. Génère l'image à la taille où elle s'affiche, et fournis plusieurs tailles pour le responsive. Ne laisse jamais le navigateur redimensionner un fichier trop grand, il télécharge le poids complet pour rien.
3. Chargement. Précharge la seule image qui porte ton LCP, celle du haut de page. Mets tout le reste en chargement différé pour ne pas concurrencer le premier rendu.
4. Dimensions déclarées et budget. Pose width et height dans le HTML pour bloquer le CLS, et fixe toi un plafond de poids par image. Une couverture sous 100 Ko, une illustration sous 150 Ko. Si tu dépasses, tu recompresses.

Où tu mesures : l'onglet réseau de Chrome te donne le poids réel téléchargé par image, trié par taille. PageSpeed Insights te dira si ton LCP est une image et combien elle te coûte en secondes. Fais l'exercice sur ta page d'accueil et sur ta page de prix, ce sont les deux que tes prospects voient le plus, et ce sont presque toujours les plus chargées en visuels.

Ce qu'il faut retenir

L'image est le coupable numéro un du poids de ta page, et c'est une excellente nouvelle, parce que c'est le coupable le plus docile. Quatre leviers, format, dimensions, chargement, poids déclaré, et tu reprends souvent la moitié de ton poids de page sans toucher à une ligne de logique. C'est le seul chantier de performance qui ne demande ni refonte ni arbitrage technique douloureux, juste de la rigueur sur ce que tu sers. Commence par là. Ouvre l'onglet réseau, trie par taille, et regarde laquelle de tes images pèse plus que ton code. Tu sauras tout de suite par où commencer.