Sur la quasi-totalité des sites que nous auditons, les images constituent le premier poste de poids téléchargé, loin devant le JavaScript et les feuilles de style. Le Web Almanac de HTTP Archive, qui analyse chaque année des millions de pages réelles, confirme ce constat à l’échelle du web : les images restent la ressource la plus lourde d’une page médiane. Et ce n’est pas qu’une question de poids : dans la majorité des cas, l’élément le plus grand affiché à l’écran, celui que mesure le LCP, est précisément une image.
La bonne nouvelle, c’est que l’optimisation des images est l’un des chantiers les plus rentables de la web performance : les gains sont massifs, mesurables, et les techniques sont aujourd’hui standardisées dans les navigateurs, sans dépendance à des bibliothèques tierces. La moins bonne nouvelle, c’est que chaque levier comporte ses pièges, et qu’une optimisation mal appliquée peut dégrader ce qu’elle prétend améliorer. Un exemple classique : un lazy loading posé sur la mauvaise image peut coûter plusieurs centaines de millisecondes de LCP.
Dans cet article, nous passons en revue l’ensemble de la chaîne : le choix du format, le dimensionnement responsive, la priorisation du chargement, le lazy loading, la stabilité de la mise en page, le cas particulier des SVG, l’hébergement et l’automatisation. Comme pour les polices d’écriture, l’objectif est de vous donner une vision complète et hiérarchisée des leviers d’optimisation, celle que nous appliquons dans nos audits de web performance.
Pourquoi les images sont le premier levier de performance
Avant de dérouler les techniques, situons précisément l’impact. Les images pèsent, directement ou indirectement, sur les trois métriques des Core Web Vitals que Google utilise pour évaluer l’expérience de chargement, et dont notre article qu’est-ce que la web performance et comment la mesure-t-on pose les fondations.
LCP : quand l’image dicte la vitesse perçue
Le LCP (Largest Contentful Paint) mesure le temps d’affichage du plus grand élément visible dans le viewport initial, avec un seuil de 2,5 secondes à respecter selon web.dev. Or ce plus grand élément est, dans la majorité des cas mesurés à l’échelle du web, une image : bannière d’accueil, photo de produit, visuel d’article.
Chaque maillon de la chaîne compte alors : la découverte de l’image dans le HTML, sa priorité réseau, son poids, puis son décodage. Une image LCP trop lourde, découverte tardivement ou chargée à basse priorité peut, à elle seule, faire basculer la page au-dessus du seuil des 2,5 secondes. Les leviers de format, de taille et de priorisation détaillés plus bas s’attaquent chacun à un maillon précis de cette chaîne.
CLS : quand l’image fait sauter la mise en page
Le CLS (Cumulative Layout Shift) quantifie les déplacements inattendus de mise en page pendant le chargement, avec un seuil de 0,1 défini par web.dev. Une image livrée sans proportions connues force le navigateur à réorganiser la page à son arrivée : le paragraphe que le visiteur commençait à lire descend d’un écran, le doigt appuie à côté du bouton visé. À l’échelle du web, les images sans dimensions sont la première cause de CLS, et c’est un problème intégralement évitable, comme nous le verrons avec les attributs de dimensions explicites.
INP : quand le décodage bloque l’interactivité
L’INP (Interaction to Next Paint) évalue la réactivité de la page aux clics, saisies et appuis, avec un seuil de 200 millisecondes documenté sur web.dev. Le lien avec les images est plus indirect, mais bien réel : décoder une image de plusieurs mégapixels consomme du temps processeur, et sur un mobile d’entrée de gamme, ce décodage peut retarder la réponse à une interaction s’il survient au mauvais moment. Des images correctement dimensionnées et différées libèrent le fil d’exécution principal au moment où il est le plus sollicité.
Au-delà des Core Web Vitals
Il y a aussi un enjeu de bande passante pure. Une page produit e-commerce embarque couramment 1,5 à 3 Mo d’images. Sur une connexion mobile moyenne, c’est plusieurs secondes de téléchargement, de la donnée facturée à l’utilisateur, et de l’énergie consommée inutilement quand les trois quarts de ces images ne seront jamais vues. L’optimisation des images est ainsi le point de convergence rare entre performance, SEO, expérience utilisateur et sobriété.
La suite de cet article suit l’ordre logique d’une optimisation bien menée : d’abord réduire ce qui transite (format, taille), ensuite ordonner ce qui se charge (priorisation, lazy loading), enfin stabiliser ce qui s’affiche (dimensions, mise en page).
Choisir le bon format : AVIF, WebP, JPEG
Le format conditionne à la fois le poids transféré, le coût de décodage côté processeur et la qualité perçue. Pour les images matricielles (photos, visuels complexes), trois formats se partagent aujourd’hui l’essentiel des usages pertinents.
AVIF, le meilleur ratio qualité-poids
Issu du codec vidéo AV1, l’AVIF offre le meilleur compromis actuel : à qualité visuelle équivalente, on observe couramment un gain de l’ordre de 50 % par rapport au JPEG et de 20 % par rapport au WebP. Son support est désormais universel sur les navigateurs modernes, comme le confirme caniuse.com : Chrome depuis la version 85, Firefox depuis la 93, Safari depuis la 16.4. L’AVIF gère la transparence et les larges gammes de couleurs (HDR), ce qui en fait aussi un remplaçant du PNG dans la plupart des cas. Sa seule contrepartie est un décodage un peu plus coûteux en CPU, à surveiller sur les très longues galeries mobiles.
WebP, le repli moderne
Le WebP est supporté partout depuis 2020 (Safari 14 inclus) et reste un excellent format de repli. Attention toutefois à une idée reçue : le WebP n’est pas systématiquement plus léger que le JPEG. Sur une image déjà bien compressée, ou pauvre en complexité visuelle, la conversion peut produire un fichier plus lourd. Une chaîne de conversion sérieuse compare toujours le résultat au fichier d’origine et conserve le plus léger des deux, comme le recommande web.dev.
JPEG et PNG, toujours utiles en dernier recours
Le JPEG garde deux rôles : servir de solution de repli universelle dans un élément <picture>, et rester le format de référence pour certaines images où il fait jeu égal avec le WebP. Le PNG, lui, ne se justifie plus que pour des cas très précis de transparence sans perte quand la compatibilité avec d’anciens environnements est requise. Quant aux TIFF et BMP, ils n’ont aucune raison d’apparaître en production.
En pratique, la cascade de formats se déclare avec l’élément <picture> : le navigateur parcourt les sources dans l’ordre et retient la première dont il supporte le type MIME, comme documenté sur MDN.
<picture>
<source srcset="visuel.avif" type="image/avif">
<source srcset="visuel.webp" type="image/webp">
<img src="visuel.jpg" width="1200" height="800" alt="Description du visuel">
</picture>Le cas des GIF animés
Le GIF animé est probablement le format le plus coûteux encore en circulation : une palette limitée à 256 couleurs, aucune compression inter-images efficace, et des fichiers qui atteignent facilement plusieurs mégaoctets pour quelques secondes d’animation. La conversion en vidéo MP4 ou WebM muette, lue en boucle, réduit typiquement le poids de plus de 90 % selon web.dev, pour un rendu strictement identique à l’écran.
Servir la bonne taille : srcset et sizes
Changer de format fait gagner 30 à 50 %. Servir une image taillée pour l’écran du visiteur peut faire gagner bien davantage : envoyer une image de 1600 pixels de large dans un emplacement affiché en 400 pixels sur mobile, c’est transférer jusqu’à 7 fois trop de données. C’est le levier le plus puissant de toute la chaîne, et paradoxalement l’un des plus négligés.
Le mécanisme standard repose sur deux attributs complémentaires de la balise <img>, décrits en détail dans le guide responsive images de web.dev. L’attribut srcset déclare les variantes disponibles avec leur largeur réelle en pixels. L’attribut sizes indique au navigateur la largeur d’affichage prévue selon le viewport. Avec ces deux informations et la densité de pixels de l’écran, le navigateur choisit seul la variante la plus économique.
<img
src="hero-1200.avif"
srcset="hero-600.avif 600w,
hero-1200.avif 1200w,
hero-2000.avif 2000w"
sizes="(min-width: 1024px) 50vw, 100vw"
width="1200" height="800"
alt="Description du visuel">Deux erreurs reviennent constamment dans nos audits. La première : un srcset avec une seule variante, ce qui revient à ne pas en avoir. Il faut au minimum deux à trois variantes par image, hors logos et icônes. La seconde : un srcset en descripteurs de largeur sans attribut sizes. Dans ce cas, le navigateur suppose que l’image occupe 100 % du viewport et télécharge souvent une variante trop grande. Il faut aussi penser à maintenir les valeurs de sizes à jour : après une refonte graphique, un sizes qui ne reflète plus la mise en page réelle fait silencieusement télécharger de mauvaises variantes.
L’élément <picture> complète ce dispositif quand la sélection dépend d’autre chose que de la largeur : la cascade de formats vue plus haut, la direction artistique (servir un cadrage différent sur mobile), ou encore le mode sombre via une media query prefers-color-scheme. Les dimensions width et height se posent alors toujours sur la balise <img> finale, jamais sur les <source>.
Prioriser l’image qui compte : fetchpriority et preload
Toutes les images d’une page ne se valent pas. Il y en a une qui mérite un traitement de faveur : celle qui constitue l’élément LCP, généralement le grand visuel en haut de page. Or, par défaut, les navigateurs chargent les images à priorité basse tant qu’ils n’ont pas calculé la mise en page et compris lesquelles sont visibles. Ce délai de plusieurs centaines de millisecondes pèse directement sur le LCP.
fetchpriority high sur l’image LCP
L’attribut fetchpriority="high" corrige ce comportement en promouvant l’image à une priorité réseau élevée dès sa découverte dans le HTML, comme l’explique web.dev. Les mesures publiées par Addy Osmani (équipe Chrome) font état de gains de 5 à 30 % sur le LCP selon les stacks, avec une moyenne autour de 15 %. Pour un attribut qui tient en un mot, le rapport effort-bénéfice est imbattable.
<img src="hero.avif"
srcset="hero-800.avif 800w, hero-1600.avif 1600w"
sizes="100vw"
width="1600" height="900"
fetchpriority="high"
alt="Visuel principal de la page">La règle d’or : une seule image par page porte fetchpriority="high". Si cinq images la revendiquent, la priorité perd tout son sens et le comportement redevient celui par défaut. Les images de pied de page peuvent au contraire recevoir fetchpriority="low" pour libérer la bande passante au profit des ressources critiques.
Le piège de l’image de fond CSS
Un piège récurrent mérite d’être signalé : quand le visuel principal est servi en background-image CSS, il échappe au préchargeur du navigateur, qui ne le découvre qu’après avoir téléchargé et analysé la feuille de style. C’est l’une des causes de LCP dégradé les plus fréquentes que nous rencontrons. La solution propre consiste à convertir l’élément en vraie balise <img> ou <picture>. À défaut, un <link rel="preload" as="image"> dans le <head> permet de déclencher le téléchargement tôt, une technique détaillée dans le guide d’optimisation du LCP de web.dev et dans notre article dédié au LCP.
<link rel="preload" as="image"
href="hero.avif"
imagesrcset="hero-800.avif 800w, hero-1600.avif 1600w"
imagesizes="100vw"
fetchpriority="high">Votre site est-il aussi rapide que vos visiteurs l’espèrent ?
Différer ce qui peut attendre : le lazy loading natif
Symétrique exact de la priorisation, le lazy loading consiste à ne pas télécharger les images situées sous la ligne de flottaison tant que l’utilisateur ne s’en approche pas. Depuis 2020, cette fonctionnalité est native dans tous les navigateurs via l’attribut loading="lazy", documenté sur MDN : aucun JavaScript, aucune bibliothèque, aucun observeur à écrire.
<img src="illustration-section-basse.avif"
loading="lazy"
width="800" height="533"
alt="Illustration de la section">
<iframe src="https://www.youtube.com/embed/xyz"
loading="lazy"
width="560" height="315"
title="Titre de la vidéo"></iframe>Le navigateur déclenche le téléchargement quand l’image approche du viewport, avec une marge d’anticipation qui dépend de la vitesse de connexion, comme le décrit web.dev. L’attribut s’applique aussi aux iframes, ce qui est précieux pour les cartes embarquées et les lecteurs vidéo. Sur ce dernier point, nous allons plus loin en recommandant des façades cliquables, un sujet voisin de celui des scripts tiers.
Les erreurs qui coûtent cher
La première erreur, de loin la plus grave : poser loading="lazy" sur l’image LCP. Le navigateur attend alors la confirmation que l’image est visible avant de la télécharger, ce qui retarde le rendu de 200 à 800 millisecondes dans les cas que nous mesurons. Cette erreur est d’autant plus sournoise qu’elle est souvent produite par un plugin ou un thème qui applique l’attribut en masse. Et la combinaison loading="lazy" avec fetchpriority="high" ne répare rien : le lazy loading l’emporte toujours.
Deuxième erreur : les systèmes de lazy loading JavaScript à base de data-src, hérités d’avant 2020. Ils cassent le préchargeur du navigateur et rendent les images invisibles si le script échoue, sans plus rien apporter face à la solution native. Troisième erreur, plus subtile : appliquer le lazy loading à de petites images répétées (avatars, pictogrammes), pour lesquelles la latence du mécanisme dépasse le bénéfice du report de téléchargement.
Et decoding async ?
On croise souvent l’attribut decoding="async" présenté comme une optimisation indispensable. La réalité est plus nuancée : les navigateurs modernes décodent déjà la plupart des images hors du fil d’exécution principal, et la documentation MDN décrit un attribut au périmètre limité. Il est inoffensif et peut être posé par défaut, mais son effet n’est réellement observable que sur de très grandes images sous forte pression CPU. Autrement dit : à ajouter, mais certainement pas un axe prioritaire d’audit.
Stabiliser la mise en page : width, height et aspect-ratio
Une image sans attributs width et height est une image dont le navigateur ignore les proportions avant de l’avoir téléchargée. Conséquence : il lui réserve une hauteur nulle, affiche le texte, puis redessine toute la mise en page à l’arrivée de l’image. Ce saut visuel est comptabilisé par le CLS, et les images sans dimensions en sont historiquement la première cause à l’échelle du web, comme le rappelle le guide d’optimisation du CLS de web.dev.
Depuis fin 2019, tous les navigateurs calculent le ratio d’aspect à partir de ces deux attributs et réservent l’espace exact avant même le premier octet de l’image. Le point clé, souvent mal compris : les valeurs HTML n’imposent pas la taille d’affichage. Le CSS garde la main, et le couple classique max-width: 100% avec height: auto conserve un rendu parfaitement responsive tout en préservant le ratio réservé.
<img src="photo.avif" width="1600" height="900" alt="Description">
/* côté CSS : responsive sans casser le ratio réservé */
img {
max-width: 100%;
height: auto;
}
Pour les images de fond CSS, qui n’ont pas d’équivalent à ces attributs, la propriété aspect-ratio permet de réserver l’espace directement dans la feuille de style. Et dans un élément <picture>, rappelons-le, les dimensions se déclarent sur la balise <img> finale. C’est un réflexe à systématiser : sur la plupart des sites que nous optimisons, la simple généralisation des dimensions explicites suffit à faire passer le CLS sous le seuil de 0,1 visé par Google. Notre guide sur les Core Web Vitals sous WordPress détaille ce chantier côté CMS.
Le cas particulier des SVG
Pour les logos, icônes, pictogrammes et schémas, le format vectoriel SVG est sans rival : il s’affiche net à toutes les résolutions, pèse souvent moins d’un kilooctet une fois optimisé, et se compresse remarquablement bien en Brotli ou gzip puisqu’il s’agit de XML. Un logo en PNG ou, pire, en JPEG, est un signal d’alerte immédiat dans un audit.
Trois pratiques font la différence. D’abord, nettoyer systématiquement les fichiers exportés des outils de création : les métadonnées d’Illustrator, Sketch ou Inkscape gonflent inutilement le poids, et un passage par SVGO en ligne de commande, ou son interface web SVGOMG signée Jake Archibald, les supprime sans toucher au rendu. Ensuite, intégrer en ligne (inline) les petits SVG critiques comme le logo du header : cela économise une requête réseau. Enfin, pour les jeux d’icônes, préférer un sprite déclaré une fois via <defs> et réutilisé partout via <use>, plutôt que trente SVG identiques répétés dans le DOM.
Dernier point, souvent oublié : un SVG sans viewBox ni dimensions explicites provoque les mêmes décalages de mise en page qu’une image matricielle sans width ni height. Les règles de stabilité vues plus haut s’appliquent à l’identique.
Héberger et livrer efficacement ses images
Le meilleur format du monde ne compense pas une livraison mal pensée. Premier principe : héberger les images sur son propre domaine. Chaque domaine tiers impose une résolution DNS et une négociation TLS supplémentaires, soit typiquement 100 à 300 millisecondes de surcoût sur mobile. Depuis que Chrome a partitionné son cache HTTP, l’argument du cache partagé entre sites a d’ailleurs totalement disparu : une ressource tierce est re-téléchargée pour chaque site qui l’utilise.
Si un CDN d’images se justifie (redimensionnement à la volée, conversion automatique de format selon le navigateur), la bonne pratique consiste à le servir derrière un alias CNAME du domaine principal plutôt que depuis le domaine du prestataire. Nous avons consacré un article complet aux avantages et inconvénients des CDN pour arbitrer ce choix. Deuxième principe : une politique de cache navigateur agressive. Les images versionnées dans leur nom de fichier peuvent porter un Cache-Control d’un an avec la directive immutable, ce qui élimine toute revalidation pour les visites suivantes.
Enfin, la qualité de l’infrastructure d’origine reste déterminante : compression Brotli activée, HTTP/2 ou HTTP/3 pour paralléliser les téléchargements, temps de réponse serveur maîtrisé. C’est précisément ce que nous garantissons sur notre hébergement WordPress optimisé pour la performance.
Automatiser : la chaîne d’optimisation en production
Tout ce qui précède ne vaut que si c’est appliqué sur 100 % des images, y compris celles que les contributeurs téléverseront l’année prochaine. L’optimisation manuelle ne passe pas à l’échelle : il faut une chaîne automatisée.
Sur WordPress, une partie du travail est nativement prise en charge : le CMS génère automatiquement plusieurs tailles à l’upload et construit le srcset correspondant, applique loading="lazy" aux images hors viewport initial et sait poser fetchpriority="high" sur l’image principale, un travail continu de l’équipe performance du cœur documenté sur make.wordpress.org. Le support du format AVIF dans la médiathèque est natif depuis WordPress 6.5. La conversion automatique des uploads vers l’AVIF peut se piloter avec un filtre :
<?php
// Générer les tailles intermédiaires en AVIF à l'upload
add_filter( 'image_editor_output_format', function ( $formats ) {
$formats['image/jpeg'] = 'image/avif';
$formats['image/png'] = 'image/avif';
return $formats;
} );Ce socle natif a toutefois ses limites : pas de comparaison du poids avant et après conversion, des réglages de qualité globaux, et aucune reprise de l’existant sans traitement dédié. C’est là qu’interviennent les plugins spécialisés ou une chaîne de build sur mesure, à choisir selon le contexte. Ce paramétrage fin, qui inclut aussi l’exclusion de l’image LCP du lazy loading, fait partie des interventions standard de notre prestation d’optimisation WordPress. Hors CMS, sur les stacks JavaScript modernes, les frameworks fournissent des composants image qui industrialisent les mêmes principes ; nos audits de SPA vérifient qu’ils sont correctement configurés.
Mesurer avant, mesurer après
Comme toujours en performance, on ne pilote que ce que l’on mesure. Les outils d’audit synthétiques repèrent la plupart des problèmes évoqués ici : Lighthouse et PageSpeed Insights signalent les images surdimensionnées, les formats obsolètes, les images sans dimensions et les candidates au lazy loading, avec une estimation du gain en octets pour chacune. Nous avons comparé ces deux outils dans un article dédié.
Le panneau réseau des DevTools complète l’analyse : filtrer sur les images, trier par poids, et vérifier pour l’image LCP la priorité effective de la requête. Attention toutefois à ne pas conclure sur la seule base de tests en laboratoire : seules les données de terrain, celles du rapport CrUX ou d’un outil RUM, reflètent ce que vivent réellement vos visiteurs, sur leurs appareils et leurs connexions. C’est tout l’objet de notre offre de monitoring de la web performance : suivre ces métriques en continu et détecter les régressions avant qu’elles ne coûtent des positions ou des conversions.
L’essentiel à retenir
Si vous ne deviez retenir qu’une méthode, ce serait celle-ci, dans l’ordre. Servez des formats modernes, AVIF en premier choix avec repli WebP puis JPEG, en vérifiant que chaque conversion allège réellement le fichier. Déclinez chaque image en plusieurs tailles avec srcset et sizes. Donnez la priorité réseau à l’image LCP avec fetchpriority="high", et à elle seule. Différez toutes les images sous la ligne de flottaison avec loading="lazy", en veillant à ne jamais l’appliquer à l’image LCP. Déclarez width et height sur chaque image pour un CLS stable. Passez les SVG par SVGO, hébergez vos images sur votre domaine avec une politique de cache longue, et automatisez l’ensemble pour que la discipline survive aux prochains uploads.
Chaque site a néanmoins ses spécificités : thème, plugins, CDN, habitudes éditoriales. Pour savoir précisément où se situent vos marges de progression et les chiffrer, un audit de web performance fournit un plan d’action hiérarchisé et chiffré ; et si vous préférez déléguer l’ensemble du chantier, notre équipe le prend en charge de bout en bout dans le cadre d’une prestation d’optimisation.
