Images sur un site EmDash : formats, tailles et poids
Redimensionner avant de compresser, choisir entre WebP et AVIF, servir plusieurs largeurs, réserver la place pour éviter le saut de mise en page. La méthode, et l'ordre des opérations.
Un site qui se charge lentement est presque toujours un site chargé d’images trop lourdes. Le code du thème, les polices, les scripts pèsent quelques dizaines de kilo-octets ; une photographie sortie d’un appareil ou d’une banque d’images en pèse plusieurs milliers. Le rapport de force est tellement déséquilibré que l’optimisation des images règle, à elle seule, l’essentiel du problème de performance d’un site éditorial.
La bonne nouvelle, c’est que la méthode tient en cinq gestes, toujours dans le même ordre. La mauvaise, c’est que l’ordre compte : appliqués dans le désordre, ces gestes se neutralisent.
Redimensionner d’abord, compresser ensuite
C’est l’erreur la plus coûteuse, et la plus répandue : passer une photo de plusieurs milliers de pixels de large dans un outil de compression, obtenir un fichier plus léger, et le publier tel quel.
Le fichier a maigri, mais il transporte toujours une image bien plus grande que ce que la page affiche. Le navigateur télécharge tout, puis réduit à l’écran. Vous payez le poids d’une image que personne ne verra jamais en entier.
Commencez donc par la largeur d’affichage réelle. Ouvrez votre site, mesurez la largeur en pixels de l’emplacement où l’image apparaît — une image d’article dans une colonne de lecture fait rarement plus de 700 à 900 pixels de large. Multipliez par deux pour couvrir les écrans à haute densité, et vous obtenez la plus grande largeur utile. Tout ce qui dépasse est du poids mort.
Ce n’est qu’ensuite que la compression intervient, et son gain devient considérable parce qu’elle s’applique à une image déjà correctement dimensionnée.
Deux réflexes complémentaires. Supprimez les métadonnées que les appareils photo embarquent — profil, réglages, et parfois coordonnées GPS du lieu de prise de vue, ce qui est un vrai sujet quand on publie des photos personnelles. Et acceptez une compression avec perte : sur une photographie, une qualité légèrement réduite est invisible à l’œil et divise le poids par plusieurs.
Choisir le format
Le paysage s’est simplifié, et il tient en quatre lignes.
JPEG reste le format universel pour la photographie. Il est lu partout, sans exception, et sert de filet de sécurité.
PNG ne se justifie que pour les images à aplats nets ou à transparence — captures d’écran, schémas, illustrations à peu de couleurs. Sur une photographie, il produit des fichiers énormes sans bénéfice visible.
WebP est aujourd’hui le choix par défaut raisonnable : nettement plus léger que le JPEG à qualité comparable, il gère la transparence, et sa prise en charge par les navigateurs est aujourd’hui quasi universelle.
AVIF compresse encore mieux, souvent de façon spectaculaire sur les photographies. Sa prise en charge est très large mais un cran en dessous de celle du WebP, et son encodage est plus lent. C’est le format à servir en premier choix, avec un repli.
SVG, enfin, est un cas à part : pour un logo, un pictogramme ou un schéma vectoriel, il reste net à toutes les tailles et pèse presque rien. Une précaution s’impose toutefois — un fichier SVG peut contenir du script, il ne faut donc jamais accepter d’envoi SVG venant d’un tiers sans nettoyage.
La stratégie robuste consiste à proposer plusieurs formats et à laisser le navigateur prendre le meilleur qu’il sait lire, en plaçant l’AVIF en tête, le WebP ensuite, le JPEG en dernier recours. C’est exactement ce que fait l’élément <picture> en HTML, et la plupart des composants d’image des thèmes modernes le génèrent pour vous.
Servir plusieurs largeurs, pas une seule
Un téléphone et un écran de bureau n’ont pas besoin de la même image. Envoyer la version large à tout le monde revient à faire payer la connexion mobile pour des pixels invisibles.
Le mécanisme standard s’appelle srcset : vous déclarez plusieurs versions du même fichier à des largeurs différentes, et l’attribut sizes indique au navigateur quelle place l’image occupera dans la page. Le navigateur choisit alors la version la plus adaptée à l’écran et à la densité, avant même de commencer le téléchargement.
Trois ou quatre largeurs suffisent dans la plupart des cas : une pour le mobile, une pour la tablette, une pour le bureau, et éventuellement une version double pour les écrans à haute densité. Multiplier les variantes au-delà complique la génération sans gain mesurable.
L’attribut sizes est celui qu’on bâcle le plus souvent, et c’est dommage : mal renseigné, il annule tout le bénéfice, le navigateur retombant sur la version la plus large par précaution.
Réserver la place et différer ce qui n’est pas vu
Deux réglages, deux effets très visibles à la lecture.
Indiquez toujours width et height sur vos balises d’image, même quand la mise en page les redimensionne ensuite en CSS. Ces deux attributs donnent au navigateur le rapport de proportions, ce qui lui permet de réserver l’espace avant que le fichier n’arrive. Sans eux, le texte remonte puis redescend brutalement quand chaque image se charge — ce saut de mise en page est l’un des défauts les plus détestés des lecteurs, et il est comptabilisé comme tel par les mesures de qualité de navigation évoquées dans notre guide SEO pour EmDash.
Différez le chargement des images hors écran avec loading="lazy". Une page d’article contient souvent plusieurs images dont le lecteur ne verra jamais la moitié ; les charger toutes d’emblée ralentit l’affichage du haut de page.
Avec une exception qui compte : la première image visible ne doit jamais être différée. C’est très souvent elle qui constitue le plus gros élément affiché à l’ouverture, donc la mesure même du temps de chargement perçu. Sur celle-là, faites l’inverse : chargement immédiat, et si possible une indication de priorité haute.
Le texte alternatif n’est pas une case à cocher
Chaque image porteuse d’information a besoin d’un attribut alt qui décrit ce qu’elle montre. C’est ce que lisent les personnes utilisant un lecteur d’écran, et ce qui s’affiche quand le fichier ne se charge pas.
Trois règles pratiques. Décrivez ce qui est représenté, pas le fichier : « façade en briques d’un immeuble ancien » plutôt que « photo-2 ». N’ouvrez pas par « image de » — le lecteur d’écran annonce déjà qu’il s’agit d’une image. Et laissez l’attribut vide (alt="") pour une image purement décorative : c’est la façon correcte de dire à l’outil d’assistance de la passer sous silence, alors qu’un alt absent le force à lire le nom de fichier.
Une légende visible, quand elle existe, joue un autre rôle : elle s’adresse à tout le monde. Les deux se complètent et ne se remplacent pas.
Où les fichiers vivent, et sous quel nom
Deux organisations coexistent, et le choix se fait tôt parce qu’il est pénible à défaire.
Les fichiers dans le projet. Les images vivent à côté du contenu, versionnées avec lui, déployées avec lui. C’est simple, reproductible, et cela garantit qu’une restauration du site ramène aussi ses images — un point à vérifier dans votre procédure de sauvegarde. L’inconvénient apparaît avec le volume : un dépôt qui accumule des centaines de photographies devient lourd à cloner et long à déployer.
Le stockage d’objets séparé. Les fichiers sont déposés sur un service dédié et servis depuis une adresse distincte. Le dépôt reste léger, le déploiement rapide, et l’on peut faire redimensionner les images à la volée. En contrepartie, vous ajoutez un service à gérer, à payer et à sauvegarder — un arbitrage de même nature que ceux passés en revue dans notre dossier sur l’exploitation d’EmDash en production.
Dans les deux cas, deux conventions valent la peine d’être fixées dès le début. Nommez les fichiers en minuscules, sans accent ni espace, avec des tirets : c’est le seul nommage qui traverse sans incident tous les systèmes de fichiers et toutes les configurations de serveur. Et ne réutilisez jamais un nom de fichier pour une image différente : les caches intermédiaires servent longtemps l’ancienne version, et vous passerez une heure à chercher pourquoi la nouvelle photo ne s’affiche pas.
Automatiser plutôt que discipliner
Tout ce qui précède peut se faire à la main. Cela fonctionne pendant trois articles, puis quelqu’un publie une photographie de huit méga-octets un vendredi soir.
La seule solution durable consiste à placer le traitement dans la chaîne de construction du site, pas dans les habitudes des rédacteurs : l’image est déposée telle quelle, et le site génère lui-même les variantes, les formats et les attributs. C’est le rôle des composants d’image fournis par les thèmes, dont l’emplacement est décrit dans le tutoriel sur la création d’un thème, et c’est aussi un cas d’usage naturel pour une extension, dans les limites d’exécution rappelées par notre article sur le bac à sable des plugins.
Une vérification finale, qui prend deux minutes et se fait sans outil supplémentaire. Ouvrez une page d’article, puis l’onglet réseau des outils de développement du navigateur, et triez par taille décroissante. Si les premières lignes sont des images et qu’elles se comptent en méga-octets, vous savez exactement quoi corriger — et par quel bout commencer.