Un site lent, on l'attribue en général à l'hébergement ou au code. Dans la plupart des cas, la vraie réponse est plus banale : ce sont les photos. Elles sont trop grandes, trop lourdes, et personne ne s'en aperçoit, puisqu'à l'écran elles s'affichent parfaitement. Le frein est invisible pour celui qui publie, pas pour celui qui attend.
C'est la bonne nouvelle de ce sujet. Contrairement à la plupart des problèmes de performance, celui-là ne demande ni développeur ni budget : un gérant qui ajoute lui-même ses photos de réalisations peut régler la question en une après-midi, et ne plus jamais la reposer ensuite.
Ce que pèse une page, et ce que les images y prennent
Le Web Almanac est l'étude annuelle de HTTP Archive, qui mesure plusieurs millions de pages réelles. Son édition 2025 donne un ordre de grandeur utile : la page d'accueil médiane pèse 2 559 Ko sur mobile et 2 862 Ko sur ordinateur, dont respectivement 911 Ko et 1 058 Ko d'images. C'est, de loin, le premier poste de poids, devant le code JavaScript et les polices de caractères.
La médiane cache le pire. Une page mobile sur dix dépasse 8 337 Ko, dont 6 288 Ko d'images à elles seules. C'est ce profil que nous retrouvons systématiquement sur les sites de TPE dont la galerie de chantiers ou de plats a été alimentée au fil des mois, photo après photo, sans traitement.
Pourquoi c'est un problème, concrètement : sur mobile, 76 % des pages ont une image comme plus grand élément affiché. Autrement dit, l'instant où votre visiteur considère que la page est chargée est presque toujours l'instant où votre photo principale apparaît. Tant qu'elle n'est pas là, il regarde un rectangle vide. Google mesure précisément ce moment sous le nom de LCP et considère qu'au-delà de 2,5 secondes le résultat n'est pas bon : nous détaillions cet indicateur et les deux autres dans notre article sur les Core Web Vitals.
Ces octets sont aussi ceux du forfait mobile de votre visiteur : une page à 6 Mo lui en coûte 6, et autant à chaque nouvelle page qu'il ouvre. Sur une connexion moyenne en déplacement, l'attente se compte en secondes, pas en dixièmes.
Les trois raisons pour lesquelles vos photos sont trop lourdes
Elles se cumulent presque toujours, et aucune ne relève de la technique avancée.
La photo est dix fois trop grande. Un téléphone récent produit des images de 4 000 pixels de large ou plus. Une grande image en haut de page s'affiche au maximum sur 1 600 à 2 000 pixels, une photo insérée dans un texte sur 800. Le navigateur télécharge les 4 000 pixels, puis les réduit pour l'affichage : tout ce qui a été téléchargé en trop est du temps d'attente pur, sans aucun gain de qualité.
Le format n'est pas le bon. Le JPEG reste la référence historique, mais il est dépassé. Le WebP produit des fichiers 25 à 34 % plus petits à qualité perçue identique, d'après l'étude de compression publiée par Google. L'AVIF descend encore plus bas. Et le PNG, que beaucoup emploient par habitude pour des photographies, peut peser plusieurs fois le poids du JPEG équivalent : il est fait pour les logos et les captures d'écran, pas pour une façade de magasin.
La qualité d'export est réglée au maximum. Entre une qualité 100 et une qualité 80, le fichier perd souvent la moitié de son poids, et l'œil ne voit rien sur un écran. Le surcroît de finesse que vous croyez conserver ne sert qu'à l'impression, où votre site ne va jamais.
Le résultat cumulé se constate sur n'importe quelle photo : prenez une image de plusieurs mégaoctets sortie d'un téléphone, ramenez-la à 1 600 pixels, exportez-la en WebP à qualité 80, et il en reste quelques centaines de kilo-octets au plus. Un rapport de l'ordre de vingt à un, pour une image que personne ne distinguera de l'originale à l'écran.
La méthode, en deux minutes par photo
Voici l'ordre des opérations. Il compte : redimensionner d'abord, comprimer ensuite, jamais l'inverse.
1. Réduire les dimensions. Fixez une largeur cible selon l'emplacement. C'est l'étape qui fait l'essentiel du gain.
| Emplacement sur le site | Largeur à l'export | Poids à viser |
|---|---|---|
| Grande image de haut de page | 1 600 à 2 000 px | moins de 250 Ko |
| Photo insérée dans un texte | 800 à 1 200 px | moins de 120 Ko |
| Vignette de galerie ou de liste | 400 à 600 px | moins de 50 Ko |
| Logo, pictogramme, schéma | format SVG | moins de 10 Ko |
2. Choisir le format. Le tableau ci-dessous résume ce qui se pratique aujourd'hui. Les taux de prise en charge par les navigateurs viennent de Can I use, qui agrège les parts de marché réelles.
| Format | Poids face à un JPEG | Navigateurs qui le lisent | Pour quoi |
|---|---|---|---|
| WebP | environ un tiers de moins | plus de 96 % | le choix par défaut, photos et illustrations |
| AVIF | souvent moitié moins lourd | environ 95 % | grandes photos de fond, quand le CMS le permet |
| JPEG | référence | tous | secours, si rien d'autre n'est possible |
| PNG | plusieurs fois plus lourd | tous | uniquement transparence et captures d'écran |
| SVG | quelques kilo-octets | tous | logos, icônes, schémas au trait |
3. Comprimer. Un outil gratuit suffit, et il vaut mieux qu'il travaille dans le navigateur : vos photos ne partent alors sur aucun serveur. Squoosh, publié par l'équipe Chrome, fait les trois opérations sur une même page, avec un comparateur avant-après qui permet de descendre la qualité jusqu'au point où l'image commence à se dégrader, puis de remonter d'un cran. Pour traiter un lot entier, un logiciel de retouche ou l'export par lot de votre système d'exploitation fera aussi bien.
4. Nommer le fichier et écrire son texte alternatif. plombier-lille-salle-de-bain-douche-italienne.webp vaut mieux que IMG_4821.webp, et l'attribut alt décrit la scène en une phrase. Ce sont deux lignes de travail en plus, elles servent à la fois l'accessibilité et le référencement des images.
Une précision pour les sites sous WordPress : le téléversement fabrique tout seul plusieurs versions réduites de chaque photo et, depuis la version 5.3, il ramène à 2 560 pixels les images plus grandes que cela. Cela limite la casse, mais ne règle pas la question : 2 560 pixels, c'est encore bien au-delà de ce qu'affiche la plus grande image d'une page, et aucune conversion en WebP n'a lieu par défaut. Le travail d'export reste donc à faire avant le dépôt, ou à confier à une extension.
Ce que votre site devrait faire tout seul
Traiter ses photos à la main a une limite : cela dépend de la rigueur de la personne qui publie, un jour de coup de feu. Un site correctement construit prend une partie du travail à sa charge.
Il sert plusieurs tailles selon l'écran. La même photo existe en plusieurs largeurs, et le navigateur choisit celle qui convient à l'appareil. Un téléphone ne télécharge pas la version prévue pour un écran de bureau. C'est le mécanisme des images dites responsives, standard depuis dix ans, que les bons outils de création génèrent automatiquement.
Il convertit au bon format sans vous le demander. Sur une installation WordPress, une extension d'optimisation d'images s'en charge à chaque téléversement, y compris rétroactivement sur la médiathèque existante. Sur un site développé sur mesure, la conversion fait partie de la fabrication : c'est ce que nous mettons en place par défaut en création de site.
Il diffère le chargement de ce qui n'est pas visible. Les images situées en bas de page n'ont aucune raison d'être téléchargées avant que le visiteur y arrive. L'attribut loading="lazy" sert exactement à cela.
Attention au piège, car il est fréquent : environ une page sur six, d'après le même relevé, applique ce report à sa grande image de haut de page, celle qui est visible immédiatement. Le navigateur attend alors pour charger l'élément le plus important de l'écran, et la vitesse mesurée se dégrade nettement. La règle tient en une phrase : tout ce qui est visible sans faire défiler se charge sans délai, tout le reste se charge en différé.
Il réserve la place de l'image avant qu'elle n'arrive. Quand la largeur et la hauteur sont déclarées, le texte ne saute plus au moment où la photo s'affiche. Quand elles ne le sont pas, c'est ce saut qui fait cliquer les visiteurs à côté du bouton qu'ils visaient.
Comment vérifier où vous en êtes, en cinq minutes
Trois vérifications suffisent à savoir si le sujet vous concerne.
Ouvrez PageSpeed Insights, collez l'adresse de votre page la plus consultée, et lisez les recommandations. Celles qui portent sur la diffusion des images listent chaque fichier en cause avec les kilo-octets que vous économiseriez en le traitant. Si la liste est longue, la réponse est oui.
Regardez ensuite le poids total des fichiers chargés, que le même rapport détaille. En dessous de 1,5 Mo, vous faites mieux que la plupart des sites. Au-delà de 4 Mo, il y a un travail immédiat à faire, et il porte presque sûrement sur les images.
Faites enfin le test de l'utilisateur réel : sortez de votre bureau, coupez le wifi de votre téléphone, et ouvrez votre site en 4G depuis la rue. C'est la situation de la plupart des visiteurs d'un site de TPE, et c'est la seule mesure qui compte vraiment.
Questions fréquentes sur le poids des images
Une image allégée perd-elle en qualité ? À l'écran, non, tant que vous restez au-dessus d'une qualité d'export de 75 à 80. La perte devient visible sur les aplats de couleur et les dégradés, rarement sur une photographie. Comparez toujours les deux versions côte à côte avant de valider, à la taille où l'image sera réellement affichée.
Faut-il convertir toutes les photos déjà en ligne ? Commencez par les pages qui reçoivent du trafic : l'accueil, les deux ou trois pages de prestations les plus consultées, la page contact. Les archives peuvent attendre. Si votre site tourne sous WordPress, une conversion en masse de la médiathèque est l'affaire d'une extension et d'une heure, à faire après une sauvegarde complète.
Le poids des images influence-t-il le référencement ? Indirectement, et par deux chemins. La vitesse de chargement fait partie des signaux pris en compte par Google, sans qu'il soit possible de savoir avec quel poids. Et surtout, une page lente est une page quittée avant d'être lue, ce qui coûte des clients bien avant de coûter des positions. Aucun prestataire ne peut vous promettre un rang dans les résultats, mais tout le monde peut mesurer une durée d'affichage.
Combien de temps cela prend-il sur un site existant ? Pour une vingtaine de pages et une centaine d'images, comptez une demi-journée à une journée de travail, mise en place d'un traitement automatique comprise. C'est l'une des interventions les moins chères et les plus rentables sur un site déjà en ligne, et elle entre dans un contrat de maintenance courant.
