Images et performance : pourquoi c'est le premier chantier à traiter sur un site lent

Quand un audit de performance démarre, la première question n'est presque jamais « faut-il changer d'hébergeur ? » ou « faut-il réécrire le JavaScript ? ». C'est : « que charge-t-on, et pourquoi si lourd ? ». Dans l'immense majorité des cas, la réponse tient en un mot : les images. C'est un chantier technique, mais aussi le plus rentable — parce qu'il ne demande ni refonte, ni changement de plateforme, juste une méthode appliquée dans le bon ordre.

Un poids qui a de quoi surprendre

Selon le Web Almanac 2025 de HTTP Archive — l'étude de référence sur l'état du web, construite à partir de l'analyse de plusieurs millions de pages — la page d'accueil mobile médiane pèse 2,56 Mo au total, dont 911 Ko rien que pour les images ; côté desktop, c'est 2,86 Mo au total dont 1,058 Mo d'images (HTTP Archive). Dans les deux cas, cela représente plus d'un tiers du poids total de la page, pour une seule catégorie de ressource. Aucune autre famille de fichiers (JavaScript, CSS, polices) n'arrive seule à ce niveau sur un site médian.

Ce chiffre explique pourquoi les images sont presque toujours le premier facteur regardé dans l'analyse du LCP (Largest Contentful Paint), la métrique Google qui mesure le temps d'affichage du plus grand élément visible à l'écran — très souvent une image d'en-tête ou une photo de présentation. Alléger une image qui dépasse 1 Mo a généralement un effet plus visible sur le temps de chargement que n'importe quelle autre optimisation isolée.

Le format : le premier réglage, avant même la compression

Beaucoup de sites utilisent encore uniquement du JPEG ou du PNG, des formats conçus dans les années 1990. Deux formats plus récents, WebP et AVIF, offrent une compression nettement supérieure à qualité visuelle équivalente.

Une comparaison indépendante menée sur 600 photos, à qualité visuelle strictement équivalente (mesurée par dissimilarité structurelle, la méthode DSSIM), donne des réductions médianes de 31,5 % pour WebP et de 50,3 % pour AVIF, par rapport à une image JPEG de référence (ctrl.blog). Concrètement : une photo de 200 Ko en JPEG peut descendre autour de 135 Ko en WebP ou 100 Ko en AVIF, sans perte visible à l'œil nu.

Et si le navigateur du visiteur ne supporte pas ces formats ?

C'est une question légitime, et la réponse technique existe depuis longtemps : la balise HTML <picture> permet de proposer plusieurs formats et de laisser le navigateur choisir automatiquement le meilleur qu'il sait afficher, avec un repli (fallback) en JPEG ou PNG si besoin. Bien implémentée, cette bascule est invisible pour l'utilisateur — il n'y a donc aucune raison de se priver du gain de poids pour les navigateurs compatibles, qui représentent aujourd'hui la quasi-totalité du trafic.

Le dimensionnement : ne pas servir une image plus grande que nécessaire

Le deuxième réglage, souvent négligé, est indépendant du format : la taille en pixels de l'image envoyée. Il arrive fréquemment qu'une photo de 3000 pixels de large, pensée pour un usage impression, soit uploadée telle quelle sur un site où elle ne s'affichera jamais à plus de 800 pixels sur desktop et 400 sur mobile. Le navigateur redimensionne alors l'affichage, mais télécharge intégralement le fichier d'origine — un gaspillage de bande passante qui n'apporte aucun bénéfice visuel.

La bonne pratique consiste à générer plusieurs tailles de la même image et à laisser le navigateur choisir la plus adaptée à l'écran du visiteur, via l'attribut srcset. C'est une optimisation invisible pour l'utilisateur final, mais qui peut diviser par plusieurs le poids téléchargé sur mobile par rapport à une image unique pensée pour le plus grand écran possible.

Le chargement différé, mais pas pour tout

Le chargement différé (lazy loading) consiste à ne télécharger une image que lorsqu'elle est sur le point d'apparaître à l'écran, plutôt que de tout charger dès l'ouverture de la page. Les navigateurs modernes le supportent nativement via l'attribut HTML loading="lazy", sans bibliothèque JavaScript tierce.

Le point auquel on fait le plus souvent l'erreur : appliquer ce chargement différé à toutes les images, y compris celle qui apparaît en haut de page et qui sert justement de référence au LCP. Retarder le chargement de cette image précise a l'effet inverse de celui recherché — elle doit au contraire être priorisée, via l'attribut fetchpriority="high". La règle simple : différer tout ce qui est sous la ligne de flottaison, prioriser ce qui est visible immédiatement.

Comment savoir si c'est vraiment votre cas

Avant de se lancer dans ces chantiers, autant vérifier qu'ils sont pertinents pour votre site. Deux outils gratuits suffisent pour un premier diagnostic : Lighthouse (intégré aux outils de développement de Chrome) et PageSpeed Insights, la version en ligne du même moteur, publiée par Google. Les deux proposent une section « Opportunités » qui liste explicitement les images à convertir dans un format moderne, celles servies plus grandes que leur taille d'affichage, et celles qui retardent le LCP faute de priorisation — avec, pour chacune, le gain de poids estimé en kilo-octets. C'est le point de départ le plus fiable : il évite de deviner où se trouve le problème, et donne une base de comparaison avant/après une fois les corrections faites.

Un signal simple à surveiller en amont, sans outil : le poids d'export d'une photo directement issue d'un smartphone ou d'un appareil photo récent dépasse très souvent 3 à 5 Mo. Une telle image, mise en ligne sans retouche, pèsera presque toujours plus lourd à elle seule que l'ensemble des autres ressources de la page réunies.

Un détail qui compte aussi : le texte alternatif

Optimiser le poids d'une image ne doit pas faire oublier sa description textuelle (l'attribut alt), qui sert à la fois à l'accessibilité — un lecteur d'écran la restitue à un utilisateur malvoyant, dans le cadre des obligations RGAA déjà en vigueur pour une partie des entreprises — et au référencement, puisque Google l'utilise pour comprendre le contenu d'une image qu'il ne « voit » pas directement. Une image bien compressée mais sans texte alternatif reste une occasion manquée des deux côtés.

Le rôle d'un CDN d'images

Au-delà de ces réglages, une partie du marché s'est équipée de CDN spécialisés dans la livraison d'images (optimisation du format selon le navigateur visiteur, redimensionnement à la volée, compression automatique). C'est une brique utile sur un site avec un volume important de visuels — mais elle ne dispense pas de produire des images sources de qualité et de taille raisonnable en amont : un CDN compense des défauts, il ne remplace pas une bonne discipline éditoriale (export au bon format, pas de fichier brut d'appareil photo mis en ligne tel quel).

Ce qu'on recommande concrètement

Dans l'ordre, sans attendre une refonte complète :

1. Convertir les visuels les plus lourds en WebP (a minima), avec repli JPEG via <picture>. C'est le changement au meilleur rapport effort/résultat.
2. Vérifier qu'aucune image n'est servie plus grande que sa taille d'affichage réelle, en générant plusieurs résolutions avec srcset.
3. Activer le chargement différé sur tout ce qui n'est pas visible au premier écran, et prioriser explicitement l'image qui sert de référence au LCP.
4. Mesurer avant/après avec un outil comme Lighthouse ou PageSpeed Insights, pour vérifier l'effet réel sur le LCP plutôt que de se fier à une impression.

Sur un site sur mesure, ces quatre points sont généralement traités dès la construction du site, sans réglage manuel a posteriori — l'un des arguments concrets en faveur d'un développement maîtrisé de bout en bout plutôt que d'un empilement d'extensions tierces à surveiller dans la durée. Mais la méthode reste valable quelle que soit la plateforme derrière votre site : c'est une question de discipline technique, pas de choix d'outil.

Si vous voulez savoir où se situe votre site sur ces points précis — ou repartir sur des bases qui n'auront pas besoin de ce rattrapage — contactez Origin pour un audit de performance gratuit, sans jargon ni engagement.