Images web : réduire le poids ne suffit pas toujours

Votre photo de produit tient dans l’écran du téléphone, mais la page reste lente à afficher. La réduire visuellement ne dit rien du fichier téléchargé : une grande image peut simplement être affichée en petit. Pour comprendre le problème, il faut distinguer la taille à l’écran, la quantité de données reçues et le moment où l’image arrive.

Un site peut proposer plusieurs versions d’une même photo. Dans le code de la page, srcset décrit les fichiers disponibles et sizes renseigne la largeur d’affichage prévue ; le navigateur s’appuie sur ces informations pour choisir une ressource adaptée. Le guide web.dev sur les images adaptatives explique ce mécanisme. Demander seulement « une image moins grande sur mobile » laisse donc une ambiguïté : parle-t-on de son apparence ou du fichier envoyé ?

Prenons un exemple fictif : un artisan présente un pichet dans une zone large de 400 pixels à l’écran. Cela n’impose pas un fichier de 400 pixels de large. Sur un écran dont la densité est double, une source de 800 pixels peut préserver la netteté. La documentation sur la densité des images détaille cette différence. Ces valeurs illustrent un cas, pas une taille universelle à appliquer à toutes les photos.

Une photo peut être légère et arriver trop tard

Le poids du fichier n’explique qu’une partie de l’attente. Le navigateur doit aussi découvrir l’image, commencer à la télécharger, puis l’afficher. Le LCP, pour Largest Contentful Paint, mesure le délai avant l’affichage du plus grand bloc de texte ou de la plus grande image visible. L’analyse de web.dev sur le LCP montre qu’une compression peut raccourcir le transfert sans avancer l’affichage si un autre mécanisme retarde celui-ci. Convertir les photos en WebP ne suffit donc pas à établir que le problème est résolu.

Le chargement différé, souvent nommé lazy loading, reporte le chargement des images éloignées de la zone visible. Il convient aux photos que le visiteur découvrira plus bas. L’appliquer à l’image principale qui détermine le LCP peut au contraire la retarder : web.dev déconseille ce réglage pour l’image principale. Dans l’exemple du pichet, la première photo et les vues de détail en bas de page n’ont donc pas nécessairement besoin du même traitement.

Un autre symptôme appelle une autre réponse : le texte descend brusquement lorsque la photo apparaît. Les dimensions déclarées de l’image, ou un espace réservé avec le bon rapport largeur/hauteur, permettent au navigateur d’anticiper sa place. La documentation sur la stabilité visuelle décrit cette prévention des décalages. Alléger le fichier ne remplace pas cette réservation ; une image rapide peut encore faire bouger la page.

Pour décrire le défaut au prestataire, le symptôme est plus utile qu’une solution présumée. « La photo reste absente alors que le titre est déjà visible » oriente vers l’ordre de chargement. « Le texte bouge quand elle arrive » oriente vers la place réservée. « La photo est floue » invite à examiner la ressource choisie et la qualité conservée. Ces observations donnent des pistes ; elles ne constituent pas un diagnostic à elles seules.

Demander une amélioration sur une page précise

La vérification doit porter sur le résultat : une image suffisamment nette, visible au bon moment, dans une page stable. web.dev distingue aussi les mesures de test des données de visites réelles : un essai isolé ne représente pas toutes les connexions. Pour comparer avant et après, demandez que la page, l’appareil et les conditions du test soient précisés. Gardez également un regard sur les détails utiles à l’achat, comme la texture ou la forme du produit.

Les offres de création de sites Gaia prévoient un design adapté au mobile, à la tablette et à l’ordinateur. Dans un projet de création ou de refonte, apportez une page représentative et les photos qui doivent y rester lisibles. Vous pourrez ainsi faire préciser le traitement des images et les vérifications attendues, au-delà de la seule mention « site responsive ».