L’image parfaite n’existe pas. Je veux dire par là : l’image qui se charge en 0,2 seconde, qui pèse 30 Ko, qui est nette sur un écran Retina 6K, et qui en plus est bien référencée. Il faut choisir.
Mais voici la bonne nouvelle : on peut s’en approcher très sérieusement. J’ai passé des années à bricoler les images de mes propres sites, à comparer les formats, à mesurer les temps de chargement avec des outils un peu trop précis. Et j’ai fini par trouver une méthode qui tient la route, sans jamais sacrifier la qualité perçue par les visiteurs.
Le problème, c’est que la plupart des articles sur le sujet se contentent de répéter les mêmes conseils génériques : « compressez vos images », « utilisez le format WebP », « remplissez vos balises ALT ». Tout ça est vrai, mais ça ne dit pas comment descendre sous la barre des 100 Ko sans que l’image ressemble à un tableau de pixels flous.
Alors voici mon retour d’expérience concret, avec des chiffres, des erreurs, et des méthodes qui fonctionnent.
Points clés à retenir
- Le seuil de compression sans perte perceptible se situe autour de 60-70 % de qualité JPEG pour la plupart des photos ; sous 50 %, les artefacts deviennent visibles.
- Le format AVIF fait gagner en moyenne 30 à 50 % de poids par rapport au WebP, mais son adoption reste partielle sur les vieux navigateurs.
- Le srcset avec attribut sizes est la technique la plus sous-estimée pour servir des images adaptées à chaque écran. La plupart des sites ne l’utilisent pas correctement.
- Un nom de fichier bien pensé (sans espaces, sans caractères spéciaux, avec des mots-clés à faible concurrence) apporte un gain SEO réel mais modeste.
- La version 2x pour les écrans Retina est indispensable, mais elle doit être réservée aux images qui ont de la valeur, pas aux décoratives.
- L’erreur la plus fréquente n’est pas la sur-compression : c’est de ne pas vérifier le rendu réel sur un écran mobile en conditions réelles.
Le choix du format : JPEG, PNG, WebP ou AVIF ? (et pourquoi le PNG est presque toujours une erreur)
Commençons par une évidence qui mérite d’être rappelée : le PNG n’est pas fait pour les photos. Je l’ai appris à mes dépens, il y a quelques années, quand j’ai mis en ligne un site de portfolio avec des captures d’écran en PNG non compressées. Résultat : des pages à 3,5 Mo, des temps de chargement catastrophiques, et un taux de rebond qui s’en ressentait. J’étais fier de mes images « parfaites », mais personne ne les voyait.
Le PNG ne conserve sa pertinence que pour les images avec transparence ou les graphiques avec peu de couleurs. Pour tout le reste, il faut choisir entre le JPEG, le WebP et l’AVIF.
Le JPEG : le seuil magique de 60-70 %
Quand on parle de compression JPEG, tout se joue sur le taux de qualité. À 80 %, la compression est douce et l’image reste quasi identique à l’originale. À 60 %, on commence à voir de très légères différences si on zoom à 200 %, mais à l’œil nu, dans une page web, c’est invisible. À 40 %, là ça se voit. Les contours deviennent flous, les zones de couleur se dégradent en artefacts.
Mon conseil : visez 60 à 70 % de qualité JPEG pour les photos. C’est le point d’équilibre où vous gagnez 70 à 80 % de poids par rapport à l’original, sans que personne ne remarque la différence. J’ai testé sur une photo de paysage qui pesait 2,1 Mo : à 65 % de qualité, elle passait à 180 Ko. Le rendu était identique à l’œil nu, même sur un écran 27 pouces.
WebP et AVIF : les formats modernes qui changent la donne
Le WebP est bien connu, et il fait déjà gagner 25 à 35 % de poids par rapport au JPEG. Mais l’AVIF, lui, va encore plus loin. J’ai comparé une cinquantaine d’images sur mon propre site : l’AVIF pesait en moyenne 40 % de moins que le WebP, avec une qualité équivalente. Pour une image de 200 Ko en WebP, je passais à 120 Ko en AVIF.
Attention, il y a un piège : l’AVIF n’est pas supporté par tous les navigateurs. Les versions récentes de Chrome, Firefox et Safari le supportent, mais certains navigateurs plus anciens ou les WebViews intégrés dans certaines applis peuvent afficher une image cassée. La solution technique, c’est la balise `
Cette méthode fonctionne, mais elle alourdit le code. Pour un site simple, je conseille de commencer par le WebP, qui est supporté partout depuis des années, et de passer à l’AVIF seulement quand vous avez un trafic conséquent et que vous voulez gratter les derniers kilooctets.
Compression avec ou sans perte : le vrai seuil de l’acceptable
Parlons maintenant du cœur du sujet : la compression sans perte perceptible. J’ai vu trop de gens massacrer leurs images avec une compression agressive à 20 % de qualité, pensant bien faire, pour se retrouver avec des images floues et des visiteurs qui fuient. Et j’ai vu l’inverse : des gens qui refusent de compresser par peur de dégrader la qualité, et qui se retrouvent avec des pages à 5 Mo.
Le seuil précis dépend du type d’image. Pour une photo avec beaucoup de détails (paysage, architecture, visage), le seuil de qualité visible se situe autour de 50-55 % en JPEG. En dessous, les artefacts deviennent visibles, surtout dans les zones de contraste (ciel, contours des bâtiments). Pour une image avec moins de détails (un graphique, un logo, une illustration simple), on peut descendre plus bas, à 45 %, sans problème.
Mais il existe une alternative : la compression sans perte avec des outils comme `pngquant` ou `optipng` pour le PNG, ou bien `cjpeg` avec l’option `-lossless` pour le JPEG. L’inconvénient, c’est que le gain est plus faible : 20 à 30 % en moyenne, contre 70 à 80 % avec une compression avec perte. Mon conseil : utilisez la compression avec perte pour les photos, et réservez le sans perte pour les graphiques où chaque pixel compte.
Les outils qui m’ont fait gagner du temps (et du poids)
J’ai testé pas mal d’outils de compression, en ligne et en local. Mon flux de travail actuel, c’est :
- ImageOptim (macOS) pour la compression initiale, avec les réglages par défaut. C’est simple, rapide, et ça fait du bon travail.
- Squoosh (en ligne) quand je veux un contrôle fin sur le taux de compression. L’interface permet de comparer visuellement l’original et la version compressée, ce qui est indispensable pour trouver le seuil de qualité idéal.
- cwebp (ligne de commande) pour convertir en WebP avec les bons réglages : `cwebp -q 75 input.jpg -o output.webp`.
Pour l’AVIF, j’utilise l’outil en ligne d’AVIF.io, ou bien la conversion via Squoosh qui le supporte désormais.
Bref, l’outil importe peu. Ce qui compte, c’est de vérifier visuellement le résultat après compression, sur un écran correct, en zoomant un peu. Si vous voyez la différence entre l’original et la version compressée, c’est que vous êtes allé trop loin.
Le responsive image avec srcset et sizes : la technique que tout le monde ignore
C’est LE sujet qui manque dans 90 % des articles sur l’optimisation d’images. Tout le monde parle de compression et de format, mais presque personne n’aborde le responsive image avec `srcset` et `sizes`.
Le principe est simple : au lieu de charger la même image de 2000 pixels de largeur sur tous les écrans, on fournit plusieurs versions (400 px, 800 px, 1200 px, 2000 px) et on laisse le navigateur choisir la bonne en fonction de la taille de l’écran et de la résolution de l’affichage.
srcset="
image-400.jpg 400w,
image-800.jpg 800w,
image-1200.jpg 1200w,
image-2000.jpg 2000w"
sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 33vw"
alt="Description de l'image">
Ce code dit au navigateur : « si l’écran fait moins de 600 pixels de large, charge la version 400 ou 800 ; sinon, charge la version adaptée à un affichage à 50 % ou 33 % de la largeur de l’écran ». Résultat : sur un smartphone, on charge une image de 40 Ko au lieu d’une image de 300 Ko. Le gain est énorme, et c’est exactement ce que Google récompense avec les Core Web Vitals.
J’ai appliqué cette technique sur un site e-commerce qui vendait des produits avec de belles photos. Le poids moyen des pages a chuté de 2,4 Mo à 850 Ko, et le temps de chargement est passé de 4,2 secondes à 1,8 seconde. Le taux de conversion a augmenté de 9 % dans les deux mois qui ont suivi, même si je ne peux pas attribuer tout cela au seul responsive image.
Nommer ses fichiers pour le SEO : au-delà du principe général
Les noms de fichiers, c’est un peu la partie la plus ennuyeuse de l’optimisation d’images. Pourtant, c’est un signal SEO réel, même s’il est faible. Et il y a des règles précises à respecter pour éviter de nuire à votre classement.
Longueur maximale : 70 caractères, espaces et extensions compris. Au-delà, les moteurs de recherche tronquent le nom et peuvent perdre le sens des mots-clés. Caractères à éviter : les espaces, les accents et les caractères spéciaux (`é`, `&`, `#`, `%`, `?`, `=`, `+`). Remplacez-les par des tirets. Par exemple : `photo-de-votre-produit.jpg` et non `photo de votre produit.jpg`. Structure idéale : deux à trois mots-clés à faible concurrence, séparés par des tirets, dans un ordre logique. Par exemple, pour une image de chaussures de randonnée : `chaussures-randonnee-montagne.jpg`. Évitez les mots-clés génériques trop concurrentiels comme `chaussures.jpg` ou `image1.jpg`. Le piège des mots-clés trop longs : si votre nom de fichier fait 50 caractères avec des mots-clés empilés, ça ressemble à du bourrage de mots-clés. Google ne punit pas directement, mais le signal est dilué. Privilégiez la clarté : `sac-dos-voyage-40l.jpg` est mieux que `sac-a-dos-voyage-randonnee-avion-40-litres-bleu.jpg`.Un détail que j’ai appris à mes dépens : ne renommez pas les fichiers après les avoir mis en ligne. Si vous changez l’URL d’une image, tous les liens internes et externes pointant vers l’ancienne URL deviennent des 404. Si vous devez renommer, mettez en place des redirections 301, mais c’est rarement rentable.
La balise ALT : le minimum vital (et les erreurs à éviter)
La balise ALT est l’attribut le plus important pour le SEO des images, mais elle est souvent mal utilisée. Un bon ALT doit décrire l’image de façon concise, en incluant le mot-clé principal si c’est pertinent, mais surtout pas de bourrage.
Les erreurs que je vois tout le temps :
- Le bourrage de mots-clés : `alt="chaussures de randonnée pas chères, chaussures de randonnée homme, chaussures de randonnée femme"`. Google le détecte et peut pénaliser la page. Un seul mot-clé, inséré naturellement, suffit.
- Le ALT vide sur des images importantes : c’est une occasion manquée. Chaque image qui apporte de l’information doit avoir un ALT descriptif.
- Le ALT sur les images décoratives : pour les images purement décoratives (spacers, icônes décoratives), c’est l’inverse : laissez le ALT vide (`alt=""`) pour que les lecteurs d’écran les ignorent, et pour ne pas gaspiller du texte inutile aux yeux de Google.
Mon exemple personnel : sur mon blog de photographie, j’ai une image d’en-tête décorative. Pendant des années, elle avait un ALT descriptif détaillé. Un jour, j’ai décidé de le vider. Résultat : aucun changement dans le trafic, et un code HTML plus propre. En revanche, les images des articles de fond, avec un ALT précis du type `coucher-de-soleil-sur-le-mont-blanc-depuis-le-refuge-des-cosques`, m’ont apporté des clics depuis les recherches d’images.
Les 4 erreurs qui ruinent vos efforts (et comment les éviter)
J’ai fait toutes ces erreurs, et je les vois refaites partout. Autant les résumer clairement.
Erreur n°1 : la sur-compression
C’est l’erreur la plus fréquente. On veut absolument passer sous la barre des 100 Ko, on monte la compression à 30 %, et le résultat est une image floue avec des artefacts visibles. Le pire, c’est que souvent, on ne le voit pas parce qu’on regarde l’image réduite dans le navigateur, et non pas en pleine taille.
Ma règle : jamais en dessous de 50 % de qualité JPEG, sauf pour des images très simples ou des illustrations. Si l’image dépasse 150 Ko à 50 % de qualité, c’est que le sujet ne se prête pas à une compression agressive, ou qu’il faut choisir un autre format (WebP, AVIF).
Erreur n°2 : l’oubli de la version 2x
Les écrans Retina (et la plupart des smartphones) affichent les images en double densité de pixels. Une image de 400 pixels de large affichée à 200 pixels sur un écran Retina paraîtra floue si elle n’a pas de version 2x. La solution : préparez une version à 800 pixels pour les écrans Retina, et servez-la via `srcset` avec la mention `2x`.
L’erreur inverse existe aussi : fournir une version 2x pour toutes les images, y compris les décoratives. Ça double le poids de la page pour aucun bénéfice visible. Réservez la version 2x aux images qui comptent : photos de produits, images principales d’articles, visuels de marque.
Erreur n°3 : la sur-optimisation des images décoratives
C’est une erreur que j’ai longtemps commise : passer des heures à optimiser des images qui n’apportent aucune valeur SEO. Les images décoratives (fond de page, icônes, illustrations d’ambiance) peuvent être chargées en lazy loading avec une qualité moindre, voire être remplacées par du CSS pur.
Un test que j’ai fait sur un site : j’ai supprimé 3 images décoratives qui pesaient 400 Ko au total, et je les ai remplacées par des dégradés CSS. Le gain en vitesse de chargement était perceptible, et aucun visiteur n’a remarqué la différence. Le SEO n’a pas bougé d’un centimètre.
Erreur n°4 : ne pas vérifier le rendu réel
La dernière erreur, c’est de ne jamais vérifier le résultat final dans un navigateur. On compresse, on convertit, on met en ligne, et on ne revient jamais regarder. Résultat : des images floues, des proportions cassées, des ALT vides sur des images importantes.
Ma méthode : je garde un fichier de test sur mon serveur, avec une page HTML qui affiche toutes mes images optimisées dans différentes tailles. Je la regarde sur mon téléphone, sur une tablette et sur un écran d’ordinateur, avec un zoom à 100 % et à 200 %. C’est le seul moyen de valider que l’optimisation n’a pas dégradé la qualité perçue.
Mon workflow complet, du téléchargement à la mise en ligne
Voici la méthode que j’applique aujourd’hui sur tous mes sites. Elle prend environ 5 minutes par image, et elle donne des résultats constants.
- Redimensionnement : je redimensionne l’image à la taille maximale dont j’ai besoin, en fonction du design du site. Pas besoin d’une image de 4000 pixels pour un affichage à 800 pixels.
- Compression : je lance une compression initiale avec ImageOptim ou Squoosh, avec les réglages par défaut (qualité JPEG 70 %).
- Conversion : je convertis en WebP (qualité 75 %) et en AVIF (qualité 50-60 %) si le site le supporte.
- Création des versions responsive : je génère les versions 400, 800, 1200 et 2000 pixels, et j’ajoute le code `srcset` avec `sizes`.
- Nommage et ALT : je nomme le fichier avec mes mots-clés, je rédige le ALT, et j’encode tout dans le HTML.
- Vérification visuelle : je regarde le rendu dans le navigateur, à différentes tailles, avec un zoom.
Ce workflow m’a permis de réduire le poids moyen de mes pages de 60 à 70 %, sans aucun impact négatif sur le SEO ou le taux de rebond. C’est un investissement en temps, mais il est rentabilisé en quelques semaines grâce à l’amélioration de la vitesse de chargement.
En résumé : ce qu’il faut retenir
| Format | Usage idéal | Qualité conseillée | Gain de poids moyen |
|---|---|---|---|
| JPEG | Photos, images complexes | 60-70 % | 70-80 % |
| PNG | Graphiques, captures d’écran, transparence | Sans perte ou 50 % | 20-30 % |
| WebP | Remplacement du JPEG et du PNG | 75 % | 25-35 % de plus que le JPEG |
| AVIF | Le plus léger, si support navigateur | 50-60 % | 40-50 % de moins que le WebP |
La vraie leçon que j’ai apprise en des années de pratique, c’est que l’optimisation des images n’est pas une science exacte. Il n’y a pas de réglage magique qui fonctionne pour toutes les images. Il faut tester, regarder, comparer, et parfois accepter qu’une image pèse 250 Ko même après optimisation, parce que le sujet ne se prête pas à plus.
Et puis il y a cette question que je me pose encore souvent : est-ce que je privilégie la vitesse à tout prix, ou est-ce que je garde une qualité irréprochable pour les images qui font la réputation du site ? La réponse n’est pas évidente. Mais une chose est sûre : une image floue est pire qu’une image lente. Le compromis, c’est de tout faire pour éviter les deux.