Images web : formats, tailles, lazy loading, le guide pratique

Servez vos images en WebP, dans des dimensions qui correspondent à leur affichage réel, avec les attributs de largeur et de hauteur déclarés et un jeu de tailles pour les écrans différents. Différez le chargement de tout ce qui est sous la ligne de flottaison, jamais de l'image principale du premier écran. Ces quatre réglages traitent l'essentiel du poids d'une page et deux des trois Core Web Vitals. Le reste relève du réglage fin.

Quel format choisir

WebP est le choix par défaut en 2026. Il est supporté par tous les navigateurs actuels, il gère la transparence et l'animation, et il produit des fichiers nettement plus légers que le JPEG à qualité comparable.

AVIF compresse encore mieux, en particulier sur les photographies, au prix d'un encodage plus lent. Il est supporté par les navigateurs récents. En pratique, on le sert en premier choix avec un repli en WebP, ce que la balise picture permet nativement.

PNG reste utile pour ce qui doit être exact : captures d'écran de texte, logos avec aplats francs. Sur une photo, c'est un gâchis.

SVG pour tout ce qui est vectoriel : logos, pictogrammes, illustrations géométriques. Poids minuscule, netteté à toutes les tailles. Attention : un SVG peut contenir du script, il faut donc nettoyer ceux qui viennent de l'extérieur.

JPEG n'a plus de raison d'être servi en premier choix, sauf comme repli pour des navigateurs très anciens.

GIF est à proscrire pour l'animation. Un GIF de plusieurs mégaoctets se remplace par une vidéo muette en boucle qui pèse dix à trente fois moins pour les mêmes images.

Quelles dimensions servir

C'est le point qui pèse le plus lourd, et le plus souvent négligé.

Ne servez jamais une image plus large que son affichage maximal. Une photo de 4000 pixels affichée dans une colonne de 600 pixels transporte quarante fois plus de données que nécessaire.

Servez plusieurs tailles. L'attribut srcset permet de proposer plusieurs versions, et sizes indique au navigateur la largeur d'affichage prévue selon la taille de l'écran. Le navigateur choisit. C'est le mécanisme standard, il est bien supporté, et il est sous-utilisé.

Tenez compte des écrans à haute densité, sans exagérer. Servir le double de la largeur d'affichage suffit ; le triple n'apporte rien de visible et pèse le double.

Déclarez toujours la largeur et la hauteur. Sans elles, le navigateur ne connaît pas la place à réserver et la page saute au chargement. C'est la première cause de mauvais CLS, et elle se corrige avec deux attributs.

Quand différer le chargement

L'attribut loading="lazy" indique au navigateur de ne charger l'image qu'à son approche.

À utiliser : sur toutes les images sous la ligne de flottaison. Sur une page longue avec vingt visuels, le gain est majeur.

À ne surtout pas utiliser : sur l'image principale du premier écran. Elle est le plus souvent votre élément LCP, et la différer revient à dégrader volontairement la mesure qu'on cherche à améliorer. C'est l'erreur la plus fréquente sur les sites récents, parce que le comportement par défaut de beaucoup de cadres et de thèmes est de tout différer.

Un piège rarement documenté : le chargement différé ne se déclenche pas sur une image rognée par un ancêtre en dépassement masqué. Dans un carrousel, par exemple, les images des vues suivantes ne sont jamais considérées comme approchant de l'écran, et le cadre reste vide au défilement. La parade consiste à retirer l'attribut quand le composant approche de l'écran, ce qui charge tout d'un coup au bon moment.

L'attribut `decoding="async"` complète utilement : il autorise le navigateur à décoder l'image sans bloquer le rendu.

Le texte alternatif

Il sert deux publics et il est presque toujours mal rempli.

Il décrit l'image pour qui ne la voit pas. C'est une obligation d'accessibilité, et c'est aussi ce qui permet à un moteur de comprendre l'image.

Il doit décrire, pas répéter le mot-clé. « Photo de canapé velours bleu design scandinave salon » est du remplissage. « Canapé trois places en velours bleu, dans un salon clair » est une description.

Une image purement décorative prend un texte alternatif vide, pas un texte inventé. L'attribut doit être présent et vide, ce qui indique aux lecteurs d'écran de l'ignorer.

Le pipeline qui fonctionne

Ce que nous mettons en place sur les projets, et qui évite d'avoir à y penser ensuite.

1. L'original est conservé dans sa meilleure définition, hors du dossier public.
2. Les déclinaisons sont produites à l'import, aux largeurs correspondant aux points de rupture du site.
3. Le format est choisi automatiquement selon ce que le navigateur accepte.
4. Les dimensions sont transmises au composant d'affichage, qui réserve la place.
5. La priorité est explicite sur l'image du premier écran.

L'important est que ce soit systématique. Une chaîne qui dépend de la vigilance de la personne qui téléverse finit par laisser passer une image de huit mégaoctets.

Ce qui ne sert pas

Compresser à l'extrême. En dessous d'un certain seuil de qualité, les artefacts se voient sur les aplats et les dégradés. Sur une boutique, une photo produit dégradée coûte plus qu'elle ne fait gagner.

Servir toutes les images en AVIF sans repli. Le gain sur les navigateurs qui le supportent ne compense pas l'absence d'affichage sur les autres.

Les extensions d'optimisation qui recompressent à la volée. Elles ajoutent une couche pour compenser une chaîne mal réglée. Réglez la chaîne.

Le format WebP sans limite de dimension. Le format a une limite dure de 16383 pixels par côté. Sur une capture de page entière, on l'atteint plus vite qu'on ne le croit, et le fichier échoue sans message clair.

Questions fréquentes

WebP ou AVIF en 2026 ?

WebP comme choix par défaut, AVIF en premier choix avec repli WebP quand la chaîne de production le permet. L'écart de poids est réel sur les photographies, plus faible sur les visuels graphiques, et l'encodage AVIF est plus lent. Sur un site à fort volume d'images, le calcul mérite d'être fait ; sur un site vitrine, WebP suffit.

Faut-il différer toutes les images ?

Non. Différer l'image principale du premier écran dégrade directement le LCP, qui est la métrique la plus visible dans les Core Web Vitals. La règle : tout ce qui est visible sans défiler se charge normalement, tout le reste est différé.

Quelle taille de fichier viser ?

Il n'y a pas de seuil universel. Un repère utile : une image de contenu au-dessus de 200 kilooctets mérite d'être examinée, et une page entière au-dessus de 1,5 mégaoctet aussi. Ce qui compte est le total transféré sur la page, pas le poids d'un fichier isolé.

Les images influencent-elles le référencement ?

Indirectement mais nettement, par la performance de la page. Directement, par la recherche d'images, qui apporte un trafic réel sur les secteurs visuels. Le texte alternatif, le nom de fichier et le contexte de la page sont ce qui permet à ce trafic d'exister.

Pour aller plus loin

Les images sont l'un des quinze points de notre audit SEO technique, et l'une des deux causes principales de lenteur sur une boutique, comme le détaille notre article sur la vitesse d'un Shopify. Le rapport entre ces réglages et les métriques est traité dans l'article sur les Core Web Vitals.