Sur mobile, une page d'accueil moyenne pèse 2,56 Mo et les images en représentent à elles seules près d'un mégaoctet, soit environ 40 % du poids total transféré selon le Web Almanac 2025 de HTTP Archive. Mal compressées, elles font tomber votre LCP au-dessus du seuil de 2,5 secondes que Google considère comme le minimum acceptable. L'optimisation images site web n'est pas un détail technique, c'est le levier de performance le plus rentable : il gagne des secondes de chargement sans rien casser au design.
Voici ce qu'un site correctement optimisé en 2026 fait sur ses images, et pourquoi la majorité des sites de TPE ne le font pas.
Les images pèsent près de 40 % de votre page, et personne ne le sait
Le chiffre vient du Web Almanac 2025 : sur la page d'accueil médiane, les images représentent 1058 Ko sur 2560 Ko transférés en mobile. C'est plus que le JavaScript, plus que les polices, plus que le CSS. Et contrairement à ces derniers, le poids des images est presque entièrement sous votre contrôle.
Dans un brief client, personne ne parle d'images. On parle de design, de pages, de contenus, parfois de SEO. Personne ne demande "vos photos pèsent combien". Résultat : un photographe envoie ses fichiers en JPEG plein format à 4 Mo pièce, le développeur les pose sur le site sans retoucher, et la page d'accueil dépasse 8 Mo. Vous avez payé un site rapide. Vous avez un site lent.
Si votre site rame déjà, commencez par le diagnostic complet des leviers de vitesse avant de toucher au reste. Les images arrivent souvent en tête de liste.
LCP, mobile, SEO : ce que des images mal optimisées vous coûtent
Le LCP (Largest Contentful Paint) mesure le temps avant que la plus grande zone visible de votre page apparaisse. Google en a fait un signal de classement officiel. Selon la documentation web.dev, 73 % des éléments LCP sur mobile sont des images. Autrement dit : votre score de performance dépend en grande partie d'une seule image.
Toujours selon HTTP Archive, 62 % des pages mobile passent le seuil de 2,5 s en 2025 contre 44 % en 2022. La moyenne progresse, mais 38 % des sites mobile sont encore au-dessus du seuil, dans la zone que Google sanctionne. Pour une TPE qui dépense déjà en SEO, en Google Ads ou en Meta Ads, c'est une fuite invisible. Plus le LCP grimpe, plus le taux de rebond grimpe, plus le coût par lead grimpe.
Côté conversion, la corrélation est documentée depuis longtemps : un site mobile qui charge en 5 secondes au lieu de 2 perd entre 20 et 30 % des sessions selon les benchmarks Google. Les chiffres exacts varient, le sens de la flèche, lui, ne varie pas.
WebP, AVIF, JPEG : le bon format pour l'optimisation images site web en 2026
Trois formats se partagent le web moderne. Le bon choix dépend du type de contenu et du gain visé.
| Format | Gain vs JPEG | Support navigateurs | Quand l'utiliser |
|---|---|---|---|
| AVIF | Environ -50 % | ~95 % | Photos, hero images, fond complexes |
| WebP | -25 à -34 % | ~96 % | Fallback universel pour photos et illustrations |
| JPEG | Référence | 100 % | Filet de sécurité ultime, vieux navigateurs |
| SVG | Variable | 100 % | Logos, icônes, illustrations à plat |
| PNG | Plus lourd | 100 % | Uniquement si transparence et format vectoriel impossibles |
La règle pratique : pour les photos, vous servez de l'AVIF d'abord, du WebP en fallback, et du JPEG en dernier filet. La syntaxe HTML existe pour ça, avec la balise <picture> et plusieurs <source>. Les navigateurs qui supportent l'AVIF prennent l'AVIF, les autres descendent vers WebP, et ainsi de suite. Le support des deux formats a dépassé 93 % en 2025 selon les données Can I Use, ce qui rend cette stratégie viable même sans peur de casser l'expérience d'un visiteur.
Le PNG reste utile uniquement pour les images avec transparence quand le SVG n'est pas adapté, sinon il pèse deux à trois fois plus qu'un WebP équivalent. Voir des logos PNG de 800 Ko sur des sites professionnels en 2026 reste fréquent. C'est de l'argent jeté.
La bonne taille au bon endroit : dimensionnez avant d'uploader
Une image affichée à 600 pixels de large n'a aucune raison d'en faire 4000. C'est l'erreur la plus banale et la plus coûteuse. Le navigateur télécharge les 4000 pixels, puis les redimensionne pour les afficher en 600. Le visiteur paye le téléchargement complet en bande passante et en temps de décodage.
Trois principes :
- Largeur réelle d'affichage : déterminez la taille maximale à laquelle l'image apparaîtra sur votre site. Un hero d'accueil fait rarement plus de 1920 pixels de large. Une photo en pleine largeur dans un article fait souvent 800 à 1200 pixels. Une vignette de blog, 400 à 600.
- Densité d'écran : sur les écrans Retina et équivalents, vous voulez servir une image deux fois plus grande pour éviter le rendu flou. L'attribut
srcsetpermet au navigateur de choisir la bonne version selon l'écran du visiteur. - Art direction : sur mobile, un hero horizontal devient minuscule. Servir une version verticale recadrée via la balise
<picture>améliore à la fois l'esthétique et le poids.
Un développeur qui livre un site sans srcset ni recadrage mobile en 2026 ne fait pas son travail. C'est un des points à vérifier quand vous récupérez un site neuf, au même titre que les redirections SEO dans une refonte qui préserve votre référencement.
Lazy loading et fetchpriority : les balises qui changent tout
Deux attributs HTML font, à eux seuls, une différence mesurable sur le LCP. Ils sont natifs, supportés partout, et ne demandent aucune librairie JavaScript.
loading="lazy" : différer le hors-écran
L'attribut loading="lazy" indique au navigateur de ne télécharger l'image que lorsqu'elle s'approche de la zone visible. Sur une page qui contient 30 images mais où le visiteur ne scrolle jamais en bas, les 25 images du bas ne sont jamais chargées. Économie de bande passante directe, et accélération du premier rendu.
Détails dans la documentation officielle de web.dev sur le lazy loading natif. C'est gratuit, c'est natif, ça se met partout, sauf à un endroit critique.
fetchpriority="high" : prioriser l'image LCP
Sur l'image qui sera votre LCP (le hero, généralement la première grande image visible), vous voulez l'inverse exact : la télécharger en priorité absolue. L'attribut fetchpriority="high" dit au navigateur "celle-ci d'abord, le reste après". Combinée à un format AVIF et un srcset bien calibré, cette seule modification fait souvent passer un LCP de 3,5 s à 1,8 s.
La référence Fetch Priority API de web.dev détaille les bons usages.
L'erreur que 16 % des sites mobile commettent
Selon web.dev, 16 % des sites mobile ajoutent loading="lazy" à leur image LCP. Effet inverse : le navigateur retarde activement l'image principale, le LCP explose, et le site est sanctionné par Google. C'est souvent le résultat d'un plugin WordPress qui applique lazy à toutes les images sans exception, hero compris.
Règle simple à mémoriser : lazy partout, sauf sur les images visibles dans le premier écran. Et sur l'image LCP, en plus, fetchpriority="high".
CDN, automatisation et compression : ce qu'on délègue
Tout faire à la main pour 200 images, c'est intenable. Trois niveaux d'automatisation, par ordre de complexité.
Compression manuelle ponctuelle
Pour une dizaine d'images sur une landing page, Squoosh de Google fait le travail en quelques minutes. Vous chargez une image, vous comparez côte à côte JPEG, WebP et AVIF, vous téléchargez la version la plus légère qui reste visuellement correcte. Gratuit, sans inscription, dans le navigateur.
Plugin ou pipeline de build
Sur WordPress, des plugins comme Imagify, ShortPixel ou EWWW génèrent les versions WebP et AVIF automatiquement à l'upload, et les servent via <picture> sans toucher au thème. Compter 5 à 20 € par mois selon le volume.
Sur un site sur mesure en Next.js, Astro ou équivalent, le composant Image intégré au framework gère la conversion, le srcset, le lazy loading et la priorité en une seule balise. C'est l'un des arguments concrets en faveur d'un framework moderne dans le comparatif Next.js vs WordPress.
CDN d'images
Cloudinary, ImageKit, Imgix ou les options intégrées à Vercel et Netlify transforment vos images à la volée selon la résolution, le navigateur et la connexion du visiteur. Sur un site international ou à fort trafic, le gain sur le LCP atteint plusieurs centaines de millisecondes selon la zone géographique. Pour un site vitrine français sous 50 000 visites par mois avec un bon hébergement, ce niveau d'optimisation est rarement rentable.
Les 4 erreurs que je vois encore en 2026 sur l'optimisation images site web
- Logos en PNG à 800 Ko. Le SVG fait souvent la même chose en 5 à 20 Ko et reste net à toutes les résolutions. Si votre logo n'est pas en SVG sur votre site, demandez à votre prestataire de le convertir.
- Hero en JPEG 2 Mo. Une photo de 1920 px de large en JPEG qualité 90 fait 2 Mo. La même en AVIF qualité 70 fait 180 Ko, visuellement indiscernable. Différence : 1,8 Mo de moins à charger en premier.
- LCP en lazy. Symptôme : votre score Lighthouse mobile reste bloqué à 50 ou 60 alors que toutes les autres optimisations sont faites. Vérifier la première image visible et retirer le
loading="lazy". - Pas de srcset. Une même image servie à 4000 px à un iPhone qui n'en affiche que 400. Trois lignes de HTML suffisent à corriger ça. Aucun plugin requis sur un site bien construit.
Comment savoir où vous en êtes en 5 minutes
Le test rapide : tapez votre URL dans PageSpeed Insights, regardez deux choses uniquement.
- La valeur du LCP en mobile (cible : sous 2,5 s).
- Les recommandations "Diffuser des images aux formats nouvelle génération" et "Dimensionner correctement les images" dans la section diagnostics.
Si le LCP dépasse 2,5 s et que ces deux recommandations apparaissent en rouge ou orange, vous avez votre liste de courses. Le gain est presque toujours concentré sur trois ou quatre images principales, jamais sur 200. C'est un chantier de quelques heures pour un développeur compétent, pas un mois de travail.
Pour un site déjà optimisé dès la livraison ou pour un audit de performance sur l'existant, regardez les services D3C Agency ou passez par le formulaire de contact pour discuter du périmètre.