Si votre site vous semble lent, les images sont le premier endroit où regarder. Sur la plupart des sites, elles représentent plus de poids total de page que toutes les autres ressources réunies — HTML, CSS et JavaScript compris. C'est aussi ce qui en fait le point le plus rentable à corriger, puisqu'une poignée d'images bien compressées peut faire gagner des secondes de chargement là où une dizaine de petits ajustements de code n'y parviendraient pas.

Là où les images font vraiment mal

Les Core Web Vitals de Google sont les métriques de vitesse qui entrent dans le classement de recherche. Il y en a trois, et les images en touchent deux directement :

Métrique	Seuil « bon »	Les images jouent-elles ?
Largest Contentful Paint (LCP)	moins de 2,5 s	Directement, et presque toujours de façon décisive
Cumulative Layout Shift (CLS)	moins de 0,1	Oui, mais par le balisage, pas par le poids
Interaction to Next Paint (INP)	moins de 200 ms	Seulement indirectement

Le LCP mesure le temps que met le plus grand élément visible à s'afficher. Sur la plupart des pages, cet élément est une image : une bannière d'en-tête, une photo de produit, l'image à la une d'un article. Une image lourde est la cause isolée la plus fréquente d'un LCP qui échoue.

Le CLS mesure à quel point la mise en page saute pendant le chargement. Cela n'a rien à voir avec le poids du fichier : le phénomène se produit quand une image arrive sans dimensions déclarées, si bien que le navigateur ne découvre la place qu'elle réclame qu'après avoir positionné tout le reste.

L'INP mesure la réactivité aux interactions, et les images ne l'effleurent qu'en marge : une très grande image coûte du temps de thread principal pour être décodée, ce qui peut retarder la réponse à un appui pendant ce temps.

Un détail qui évite bien des confusions : Google évalue tout cela au 75e centile des utilisateurs réels sur une fenêtre glissante de 28 jours, via le Chrome User Experience Report. Vous ne passez que lorsque au moins 75 % des pages vues réelles franchissent le seuil. C'est pourquoi un score Lighthouse parfait et un rapport Search Console au rouge cohabitent très bien — nous y revenons plus bas.

Ce qu'un mégaoctet coûte en secondes

Voilà la partie qui rend l'arbitrage concret. Le profil mobile par défaut de Lighthouse bride la connexion à 1,6 Mbit/s avec 150 ms de latence — une connexion volontairement peu flatteuse, à peu près le quart le plus lent de la 4G. À cette vitesse, il vous arrive environ 195 Ko par seconde.

Reprenez la courbe de qualité JPG que nous avons mesurée dans comment compresser des images sans perdre en qualité et convertissez les poids en temps de transfert :

Qualité	Poids	Temps de transfert à 1,6 Mbit/s
100	1220 Ko	6,25 s
95	402 Ko	2,06 s
90	234 Ko	1,20 s
85	151 Ko	0,77 s
80	118 Ko	0,60 s
70	75 Ko	0,38 s

Mettez maintenant cela en face d'un budget LCP de 2,5 secondes — et rappelez-vous que le budget doit tout couvrir, pas seulement l'image : DNS, établissement de la connexion, réponse du serveur, analyse du HTML, CSS, et seulement ensuite le téléchargement de l'image.

À qualité 100, l'image à elle seule dépasse le budget entier de près de quatre secondes. À 95, elle en consomme plus de 80 %. À 85, elle en prend moins d'un tiers et laisse une vraie place à tout le reste. C'est la même économie en une seule étape, de 100 à 95, que dans l'article sur la compression, reformulée comme la différence entre réussir et échouer.

Deux réserves pour que les chiffres restent honnêtes. Notre image de test porte beaucoup de grain, ses poids absolus sont donc plus élevés que ceux d'une photo de téléphone typique : ce sont les proportions qui se transposent, les Ko sont illustratifs. Et une connexion réelle n'est pas un tuyau constant : l'image ne peut généralement même pas commencer à se télécharger avant que le HTML ne soit analysé, ce qui rend la situation pratique un peu pire que le tableau, pas meilleure.

D'où découle un budget de poids pour la page

Retournez ce calcul et il devient un chiffre avec lequel vous pouvez réellement concevoir. À 195 Ko par seconde, un budget LCP de 2,5 secondes vous achète environ 490 Ko au total — et ce total couvre le HTML, le CSS, tout JavaScript bloquant et les polices, avant de dépenser le moindre octet d'image.

Disons que la structure de la page coûte 150 Ko. Il vous reste environ 340 Ko pour tout ce qui s'affiche au-dessus de la ligne de flottaison. Une image d'en-tête à qualité 85 (151 Ko dans notre tableau) tient sans peine. Trois, non.

C'est aussi la réponse à « combien d'images, c'est trop ». Une page galerie avec dix photos de 118 Ko chacune fait 1,18 Mo — six secondes de transfert sur cette connexion, avant que quoi que ce soit d'autre ne charge. Le remède n'est pas de compresser chacune plus fort, c'est d'en charger deux et de différer les huit autres, pour que seul ce qui est visible se dispute le budget.

Deux choses vous redonnent de la marge en dehors du budget. Le cache signifie que les visiteurs de retour ne paient rien pour les images qu'ils possèdent déjà : mettez donc de longues durées de Cache-Control sur les fichiers dont l'URL change quand le contenu change. Et un CDN raccourcit l'aller-retour, pas la charge utile : ces 150 ms de latence sont par requête, et se paient à chacune d'elles.

L'ordre qui compte

Trois leviers, et ils n'ont pas la même force. Tirez-les dans cet ordre :

Redimensionnez à la taille d'affichage réelle. Une photo de 4000 pixels de large dans une colonne de 600 télécharge les données des 4000 pixels pour que le navigateur en jette presque tout. Aucun réglage de qualité ne récupère cela. C'est le plus gros gain isolé et celui que l'on saute le plus souvent.
Changez de format. Le WebP se situe typiquement 25 à 35 % sous un JPG équivalent à qualité visuelle égale, et l'AVIF encore en dessous. Les deux s'affichent sans risque dans tout navigateur encore mis à jour. (WebP vs JPG vs PNG vs AVIF traite des compromis.)
Et ensuite réglez la qualité. À ce stade, vous optimisez un fichier déjà raisonnable, ce qui est précisément le bon moment pour le faire.

Quatre erreurs de livraison qui ruinent une bonne compression

Vous pouvez compresser impeccablement et échouer quand même au LCP. Voici comment.

Charger l'image d'en-tête en différé. Le but contre son camp le plus fréquent de toute cette liste. loading="lazy" indique au navigateur que cette image n'est pas urgente — l'appliquer à votre image LCP retarde donc activement ce qui est justement mesuré. Différez ce qui est sous la ligne de flottaison ; jamais ce qui est au-dessus.

Ne pas déclarer les dimensions. Renseignez toujours width et height (ou un aspect-ratio en CSS). Le navigateur réserve alors la bonne place avant l'arrivée du fichier, et le CLS cesse de se produire. Cela ne coûte rien et règle une métrique entière.

Servir la même taille à tous les appareils. Un téléphone reçoit le même fichier de 2000 pixels qu'un ordinateur de bureau. srcset avec sizes laisse le navigateur choisir :

<img
  src="hero-800.jpg"
  srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw, 800px"
  width="800" height="500"
  alt="…"
  fetchpriority="high"
/>

Ce fetchpriority="high" est le pendant de l'erreur de chargement différé : il dit au navigateur de récupérer celle-ci en premier, avant les autres images découvertes au même moment.

Ne pas proposer de formats modernes avec un repli. <picture> permet de servir de l'AVIF à ce qui le comprend et de retomber proprement :

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

Le navigateur prend le premier type qu'il connaît. Rien ne casse nulle part.

Chiffres de laboratoire contre utilisateurs réels

À comprendre avant de courir après un score. Lighthouse et PageSpeed Insights exécutent un test de laboratoire : un chargement, un appareil simulé, une connexion bridée. Déterministe et utile pour trouver les problèmes.

Le rapport Core Web Vitals de la Search Console montre des données de terrain : de vrais visiteurs, de vrais appareils, de vrais réseaux, agrégés au 75e centile sur 28 jours. Autre question, autre réponse.

Deux conséquences pratiques. Un score de laboratoire s'améliore dès que vous déployez le correctif ; le rapport de terrain met des semaines à rattraper, parce qu'il continue de moyenner l'ancienne expérience. Et un test de laboratoire sur la fibre de votre portable ne dit presque rien d'un visiteur en mauvaise connexion mobile — c'est-à-dire exactement celui que le 75e centile mesure.

Servez-vous du test de laboratoire pour trouver ce qui ne va pas. Servez-vous des données de terrain pour décider si c'est réellement réglé.

Comment savoir où vous en êtes

Passez la page dans PageSpeed Insights. Il rapporte les données de laboratoire et de terrain côte à côte pour n'importe quelle URL publique, et nomme l'élément précis qu'il a retenu comme votre LCP — souvent le moyen le plus rapide de découvrir que l'image que vous croyiez fautive n'est pas celle qui est mesurée.

Bien faire la partie compression

L'erreur la plus fréquente ici n'est pas de sauter la compression, c'est de se tourner vers un outil qui envoie vos images sur le serveur de quelqu'un d'autre pour faire le travail. C'est plus lent, et cela laisse une copie de votre contenu — peut-être encore non publié — quelque part hors de votre contrôle pendant le traitement.

img-compress prend en charge les étapes 2 et 3 de la liste ci-dessus : compresser et convertir entre JPG, PNG, WebP et AVIF, entièrement sur votre propre appareil, photos HEIC d'iPhone comprises, une seule image d'en-tête se terminant aussi aisément qu'un lot complet de photos produit avant un lancement.

L'étape 1, le redimensionnement, il ne la fait délibérément pas : il réencode sans changer les dimensions, car les bonnes dimensions dépendent de la destination de l'image. Cela relève de votre éditeur d'images ou de votre CMS. Et les attributs de livraison ci-dessus relèvent de vos gabarits — aucun compresseur ne peut les ajouter à votre place.

Comment le poids des images affecte la vitesse de votre site