Photos et site lent : ce que compresser ne règle pas.

Vous prenez une photo avec votre téléphone, vous l'envoyez sur votre site, elle s'affiche bien. Chez vous, la page se charge tout de suite. Sur votre écran, l'image est nette.

Et pourtant, elle coûte beaucoup plus cher que vous ne le croyez à la personne qui la regarde.

Le fichier et la mémoire ne sont pas la même chose

Une photo de smartphone fait couramment 4000 pixels de large sur 3000 de haut. En JPEG, disons trois mégaoctets sur le disque. C'est le poids du fichier, celui qui voyage sur le réseau, et c'est le seul chiffre que tout le monde regarde.

Mais un fichier compressé ne s'affiche pas. Pour le peindre à l'écran, le navigateur doit d'abord le décompresser en mémoire, pixel par pixel. Et là, la documentation de Mozilla est catégorique : une fois décodée, chaque pixel occupe quatre octets de mémoire, quel que soit le format d'origine.

Faites le calcul. Quatre mille fois trois mille, cela fait douze millions de pixels. Multipliés par quatre octets, environ quarante-huit mégaoctets de mémoire vive. Pour une seule image. Sur un téléphone de trois ans avec quinze onglets ouverts, ce n'est plus un détail.

La conséquence est celle que personne n'anticipe. Compresser davantage le JPEG réduit le téléchargement, et ne change rien à la mémoire. Le décodage rend les quarante-huit mégaoctets quoi qu'il arrive. Seule la réduction des dimensions agit sur les deux à la fois.

Compresser agit sur le fichier. Redimensionner agit sur le fichier et sur la mémoire. Ce n'est pas le même geste.

La règle tient en un chiffre

Une image doit faire à peu près la taille à laquelle elle s'affiche. La documentation de Google sur les performances d'image recommande un rapport de réduction de 2 au maximum entre les dimensions réelles du fichier et celles auxquelles il est affiché.

Concrètement : si votre photo s'affiche dans une colonne de cinq cents pixels de large, un fichier de mille pixels suffit largement. Le facteur deux couvre les écrans à haute densité, ceux des téléphones récents, qui ont besoin de plus de pixels que la mesure théorique. Au-delà, vous envoyez de la donnée que personne ne verra jamais.

Votre photo de quatre mille pixels dans une colonne de cinq cents est à un rapport de huit. C'est le cas le plus répandu sur les sites de petites entreprises, et de loin.

Les deux attributs que presque personne ne met

Sur une balise image, width et height. Deux nombres.

Les navigateurs actuels ne s'en servent pas comme d'une taille fixe. Ils les divisent l'un par l'autre pour en déduire le rapport de forme de l'image, avant même qu'elle soit téléchargée, et réservent la place correspondante dans la page.

Sans eux, il se passe ce que vous avez vu cent fois sans le nommer : vous commencez à lire, l'image arrive, tout le texte saute vers le bas, vous perdez votre ligne. Ce décalage porte un nom chez Google, le Cumulative Layout Shift, et il fait partie des trois indicateurs que le moteur regarde vraiment.

Deux attributs. C'est de très loin la correction la moins chère de toute cette liste, et c'est celle qu'on oublie le plus.

Le piège du chargement différé

L'attribut loading="lazy" demande au navigateur de ne charger une image que lorsqu'elle approche de l'écran. Sur un site avec quarante photos, le gain est réel.

Appliqué à toutes les images sans exception, il se retourne contre vous, et le mécanisme mérite d'être compris. Une image marquée en chargement différé doit attendre que le navigateur ait calculé la mise en page pour savoir si elle est visible ou non. Elle n'est donc demandée qu'après le téléchargement, l'analyse et l'application de toute la feuille de style. Alors qu'une image ordinaire est repérée dès la lecture du code source, bien avant.

Autrement dit, vous retardez précisément l'image que le visiteur voit en premier, celle qui décide de son impression sur la vitesse du site.

Google a publié une analyse comparant les pages qui utilisent le chargement différé et celles qui ne l'utilisent pas : les premières affichent de moins bons délais d'affichage du plus grand élément. Je précise la nature de ce chiffre, parce qu'elle compte : c'est une comparaison entre des pages différentes, pas une expérience contrôlée, et les sites qui utilisent cette technique ne sont pas identiques aux autres. Le mécanisme, lui, est documenté et la correction connue. Ne différez jamais ce qui est visible à l'arrivée.

Trente minutes, sur votre téléphone

• Ouvrez votre site sur un téléphone et repérez les images visibles sans faire défiler.
• Sur un ordinateur, clic droit sur l'une d'elles, ouvrir l'image dans un nouvel onglet : les dimensions réelles s'affichent dans le titre de l'onglet ou dans la barre d'adresse.
• Comparez à la largeur d'affichage. Au-delà d'un rapport de deux, l'image est à refaire.
• Redimensionnez avant l'envoi, pas après. N'importe quel logiciel de photo sait exporter en mille six cents pixels de large, et c'est suffisant pour la quasi-totalité des usages d'un site vitrine.
• Demandez à votre prestataire si les balises portent width et height, et si le chargement différé épargne les images du haut de page.

Ce que cela ne règle pas

Un site lent pour d'autres raisons restera lent. Si la page traîne une accumulation de scripts, alléger les photos ne rattrapera pas ça.

Le gain est aussi invisible pour vous. Vous êtes en fibre, sur un ordinateur récent, et votre navigateur a déjà tout en cache : c'est le mécanisme décrit dans le cache du navigateur et les modifications qu'on ne voit pas. La personne qui découvre votre site en 4G au fond d'un village, elle, le sent passer.

Et il y a une chose que je veux dire franchement, parce qu'elle va à rebours de ce qu'on vend le plus.

Convertir ses images en WebP ou en AVIF, ces formats modernes qui compressent mieux, est utile. C'est aussi la prestation la plus proposée sur ce sujet, souvent la seule. Or elle agit sur le poids du fichier, et pas du tout sur la mémoire après décodage : les quatre octets par pixel sont les mêmes quel que soit le format. Une photo de quatre mille pixels convertie en AVIF reste une photo de quatre mille pixels dans la mémoire du téléphone.

Le format, c'est le deuxième geste. Le premier, c'est la dimension. Dans cet ordre, et jamais l'inverse.

Si vous voulez un état des lieux fait sur vos pages plutôt que sur des suppositions, c'est ce que fait le scanner SEO, et le reste est décrit sur la page offres.

Questions fréquentes

Pourquoi compresser une photo ne suffit-il pas à alléger un site ?

Parce que la compression agit sur le fichier transmis, pas sur la mémoire nécessaire à l'affichage. Pour peindre une image à l'écran, le navigateur la décode, et une fois décodée chaque pixel occupe quatre octets de mémoire quel que soit le format d'origine. Une photo de 4000 par 3000 pixels représente douze millions de pixels, soit environ quarante-huit mégaoctets de mémoire vive, que le fichier pèse trois mégaoctets ou un seul. Seule la réduction des dimensions agit à la fois sur le téléchargement et sur la mémoire.

Quelle taille d'image faut-il mettre sur un site ?

À peu près celle à laquelle l'image s'affiche, avec un rapport de réduction de 2 au maximum entre les dimensions du fichier et les dimensions d'affichage. Une photo présentée dans une colonne de 500 pixels de large n'a pas besoin de dépasser 1000 pixels. Ce facteur deux couvre les écrans à haute densité des téléphones récents. Au-delà, la donnée envoyée n'est jamais vue.

Convertir ses images en WebP ou AVIF résout-il le problème ?

Seulement à moitié. Ces formats compressent mieux et réduisent réellement le poids téléchargé, ce qui est utile. En revanche ils ne changent rien à la mémoire après décodage, puisque les quatre octets par pixel s'appliquent quel que soit le format. Une image de 4000 pixels convertie en AVIF reste une image de 4000 pixels en mémoire. Le redimensionnement vient donc en premier, la conversion de format ensuite.

Sur le même sujet : le cache du navigateur et les modifications qu'on ne voit pas, et l'INP, la réactivité mesurée par Google.