Le LCP qui dégringole de 4,2 secondes à 1,8 seconde. Voilà le genre de résultat qui change une journée. Et pourtant, quand on me demande par où commencer en SEO technique, je réponds presque toujours : les images. Pas le balisage, pas la structure des URLs, pas le maillage interne. Les images. Parce qu'elles représentent souvent plus de la moitié du poids d'une page, et que personne ne les regarde vraiment. C'est le gisement le plus sous-exploité du référencement, et c'est celui où vous pouvez agir sans dépendre d'un développeur.
Points clés à retenir
- Le format compte moins que la maîtrise de votre chaîne de traitement : comprenez ce qui arrive à votre image avant de la compresser.
- L'attribut alt est un outil de contexte, pas une description servile — et une image décorative doit avoir un alt vide.
- Le lazy loading est un réflexe, mais mal configuré, il peut faire chuter votre LCP au lieu de l'améliorer.
- Les images générées à la volée par votre CDN posent des problèmes d'indexation que la plupart des gens ignorent jusqu'au jour de la pénalité.
- Le poids d'une page se joue en amont, dans le design : chaque image ajoutée est une dette technique potentielle.
- Pensez à l'utilisateur qui ne voit pas vos images : l'accessibilité est un signal de qualité, pas une contrainte légale.
Pourquoi les images sont un enjeu de référencement technique (et pas seulement de poids)
On m'a demandé récemment, lors d'un audit : « Mais le SEO des images, ça se limite à l'attribut alt, non ? » Non. Pas du tout. L'image est un objet technique qui traverse toute la chaîne de chargement de votre page. Elle touche au rendu, au réseau, au serveur, au cache, et à la perception de l'utilisateur. Une image lourde, c'est un LCP (Largest Contentful Paint) qui explose. Et un LCP élevé, c'est un signal utilisateur dégradé. C'est aussi simple que ça.
LCP et images : la liaison directe que tout le monde ignore
Le LCP mesure le temps d'apparition du plus grand élément visible de votre page. Dans la majorité des cas, cet élément est une image. Un constat que j'ai vérifié sur des dizaines de sites : quand le LCP est mauvais, c'est presque toujours l'image d'en-tête ou le visuel principal qui traîne. Pas le CSS, pas le JavaScript. L'image.
La conséquence logique, c'est qu'une bonne stratégie d'optimisation d'images est d'abord une stratégie de priorisation : savoir quelle image est la plus critique, et lui donner toutes les ressources. Chargez-la en premier, en preload si nécessaire. Les autres peuvent attendre, en mode lazy.
L'alt n'est pas un refuge : c'est un espace de contexte
Passons à l'alt. On nous a seriné pendant des années de décrire l'image. Mais décrivez pour qui ? Une image de produit sur une fiche e-commerce et la même image dans un article de blog n'auront pas le même alt, même si le fichier est identique. Le premier dira « Chaussure de randonnée imperméable — modèle X, pointure 42 ». Le second dira « La chaussure X après 200 km de sentier dans les Pyrénées ». C'est le contexte de la page qui définit l'alt, pas l'image elle-même. Mon alt est toujours rédigé en dernier, quand le texte autour est stable.
Et pour les images purement décoratives ? Un séparateur, un motif de fond, une flèche qui ne dit rien ? L'alt doit être vide. alt="". Les lecteurs d'écran liront « image » ou le nom du fichier si vous écrivez autre chose, et ça, c'est du bruit pour un utilisateur malvoyant. Je l'ai appris à mes dépens : un alt rempli par réflexe sur toutes les images, c'est pire que pas d'alt du tout.
Les Core Web Vitals et l'impact des images : mesurer avant d'agir
Spoiler : l'optimisation d'images sans mesure, c'est de la sorcellerie. Avant de toucher à quoi que ce soit, il faut un point de départ chiffré. Sur un projet récent, j'ai passé une semaine à auditer une boutique qui voyait ses pages produits chuter dans les résultats. Le diagnostic était limpide : chaque page contenait 14 images, dont 4 en haute résolution non compressées, chargées toutes en même temps. Le poids total moyen dépassait les 8 Mo. Huit mégaoctets pour une page produit. Le LCP était constamment au-dessus de 4 secondes.
Outils de mesure et seuils chiffrés concrets
Pour mesurer, j'utilise trois choses : la console développeur de Chrome, l'outil PageSpeed Insights de Google, et l'onglet Réseau de mon navigateur. Le premier me donne des chiffres bruts. Le deuxième me dit ce que Google pense de mon LCP. Le troisième me montre l'ordre de chargement réel.
- Un LCP sous 2,5 secondes est considéré comme bon.
- Une image de fond en CSS avec une photo de 500 Ko, c'est un LCP saboté d'avance.
- Un total de page sous 1,5 Mo est un objectif sain pour un article de blog.
Mais le chiffre qui m'importe le plus, c'est l'écart entre le poids théorique et le poids réel de chaque image. Dans le cas de cette boutique, la plupart des images avait été exportées en 3000 pixels de large pour être affichées dans un carré de 300 pixels. Un gâchis colossal.
Le compromis qualité/poids : en pratique, ça donne quoi ?
Le vieux réflexe du JPEG en qualité 80 est dépassé. Avec un bon encodeur (mozjpeg, par exemple), vous pouvez pousser la compression beaucoup plus loin sans dégradation visible. J'ai réduit le poids de ces images de 75% en moyenne, sans réclamation de la direction artistique. Le vrai sujet, c'est la dimension. Servez une image à la taille de son conteneur, pas à la taille de la capture. Le redimensionnement est l'étape la plus rentable de toute l'optimisation d'images. Un fichier de 800 pixels de large pour un affichage de 400 pixels, c'est quatre fois plus de pixels que nécessaire.
Images dynamiques et crawl budget : le piège des CDN modernes
Voici un problème que je vois de plus en plus, et dont personne ne parle. Les services de redimensionnement d'images à la volée, très pratiques pour les développeurs, génèrent souvent des centaines de variations d'une même image. La même photo, déclinée en 15 tailles différentes via des paramètres d'URL. Résultat : les bots de Google explorent toutes ces URLs, gaspillent votre crawl budget, et indexent parfois des versions que vous ne vouliez pas voir apparaître.
Canonicalisation des URLs d'images : la solution oubliée
La parade est simple, mais rarement mise en place : une règle de canonicalisation qui pointe toutes les variantes vers l'image d'origine. Ou l'interdiction pure et simple de l'indexation des URLs dynamiques via le fichier robots.txt. J'ai vu un site avec 40 000 URLs d'images indexées pour seulement 200 images réelles. Un désastre silencieux. Le crawl budget se dilapidait sur des doublons.
Pour aller plus loin, surveillez la section « Images » de la Google Search Console. Elle vous montrera les tendances d'indexation. Si vous voyez des pics bizarres, regardez quelles URLs sont concernées. C'est souvent là que se cache le problème des images dupliquées ou quasi identiques (les near-duplicates). Deux images qui se ressemblent fortement, avec le même contexte, peuvent être considérées comme dupliquées. La solution consiste à n'en garder qu'une, ou à différencier clairement leurs alt et leurs pages de destination.
Structurer les images pour les moteurs : données structurées et sitemaps
Une image n'est pas qu'un fichier binaire. C'est une entité avec des métadonnées. Les ignorer, c'est se priver de signaux supplémentaires. Outre le nom de fichier descriptif et l'alt, il existe une couche plus avancée : les données structurées. L'intégration d'un bloc ImageObject dans votre page, via le format JSON-LD, permet de préciser des informations que les moteurs ne peuvent pas déduire seuls : l'auteur de l'image, sa licence, sa description précise, sa localisation dans la page. Les résultats enrichis ne sont pas garantis, mais les données structurées aident Google Discover à comprendre vos visuels.
Sitemap d'images : quand est-ce vraiment utile ?
Le sitemap d'images est un fichier XML séparé qui liste les URLs de vos visuels. Franchement, son utilité est marginale si vos images sont bien intégrées dans des pages elles-mêmes bien structurées. Il devient pertinent pour les images chargées en JavaScript, que les moteurs ont parfois du mal à découvrir, ou pour des contenus très volumineux. Dans 90% des cas, un bon HTML vaut mieux qu'un sitemap d'images.
Accessibilité avancée : au-delà de l'alt, la question des contrastes
J'ai évoqué les lecteurs d'écran. Mais l'accessibilité des images ne s'arrête pas à l'alt. Un aspect régulièrement négligé : le texte incrusté dans les images. Si votre visuel contient une information cruciale (un prix, une date, un slogan), elle est invisible pour un moteur et pour un lecteur d'écran. La règle d'or que j'essaie d'appliquer : ne jamais mettre d'information unique dans une image. Si vous le faites, répétez-la dans le texte de la page.
Et les contrastes ? Une image de fond avec un texte blanc dessus, c'est un classique. Si l'image est claire, le texte devient illisible. C'est un problème d'accessibilité, mais c'est aussi un problème d'expérience utilisateur qui fait fuir les visiteurs. Un texte illisible, c'est un utilisateur qui s'en va, et un signal négatif qui se cumule. La vérification est simple : chargez votre page et regardez-la. Vraiment. Sur un écran de téléphone, en plein soleil, si vous pouvez. C'est le test ultime.
Gestion du lazy loading : avec mesure, pas par mode
Le lazy loading (chargement différé) est une bonne pratique, à condition de comprendre ce qu'on fait. Le principe est de ne charger l'image que lorsqu'elle s'apprête à entrer dans le viewport. Mais voici le piège : si votre page est un long article et que votre image principale est en haut, elle doit être chargée immédiatement, pas en différé. Sinon, vous retardeztout et vous aggravez le LCP.
Un point que je vérifie systématiquement : la présence de l'attribut fetchpriority="high" sur l'image principale pour forcer son chargement prioritaire. Tout le reste peut être en loading="lazy" et en decoding="async" pour libérer le thread principal.
Conclusion : le vrai coût d'une image mal optimisée
L'optimisation d'images n'est pas une tâche de finition. C'est une décision de conception. Elle intervient au moment où l'on choisit un visuel, où l'on décide de sa taille, de son format, de son rôle dans la page. Le coût d'une image mal optimisée ne se voit pas immédiatement. Il se manifeste des semaines plus tard, dans une lente érosion des positions, un taux de rebond qui grimpe sans raison apparente, et des pages qui semblent lourdes sans qu'on sache pourquoi.
Chaque image ajoutée est un choix. Alors, la prochaine fois que vous insérez une photo, une capture d'écran, une infographie, posez-vous la question simple : cet élément aide-t-il l'utilisateur à comprendre, ou remplit-il juste un espace vide ? La réponse à cette question déterminera la qualité de votre optimisation, bien plus que n'importe quelle compression. Le poids d'une page n'est que la traduction technique de vos priorités éditoriales. Le reste est une affaire de mesure patiente.
