L’optimisation des images pour le SEO regroupe l’ensemble des interventions techniques et éditoriales appliquées aux fichiers visuels d’une page web pour en réduire le poids, en améliorer l’indexation et en accélérer le rendu à l’écran. Chaque image non traitée alourdit le temps de chargement, dégrade les Core Web Vitals et fait perdre des positions dans les résultats de recherche. Comprendre les mécanismes en jeu permet d’agir sur les bons leviers, dans le bon ordre.
Largest Contentful Paint et images : le lien direct avec le classement
Le Largest Contentful Paint (LCP) mesure le temps nécessaire à l’affichage du plus grand élément visible dans la fenêtre du navigateur. Sur la plupart des pages, cet élément est une image, souvent le visuel principal (hero).
Quand cette image met trop de temps à apparaitre, le score LCP chute. Google intègre cette métrique dans les Core Web Vitals, qui influencent le positionnement depuis 2021. Depuis mars 2024, la métrique INP (Interaction to Next Paint) a remplacé FID dans ce même ensemble de signaux, mais le LCP reste le point de friction le plus fréquent lié aux images.
Un piège courant : appliquer le lazy loading à l’image hero. Google déconseille explicitement cette pratique parce qu’elle retarde le chargement de l’élément LCP. Le lazy loading reste pertinent pour les images situées sous la ligne de flottaison, pas pour le premier visuel visible.
Vérifier le LCP en conditions réelles
Les données de terrain (field data) comptent davantage que les tests en laboratoire. PageSpeed Insights affiche les deux, mais seul le rapport d’expérience utilisateur Chrome (CrUX) reflète la performance réelle sur les appareils des visiteurs. Un LCP correct en lab et mauvais en field signale souvent une image hero trop lourde servie à des connexions mobiles lentes.
Format AVIF, WebP et JPEG : choisir selon le contexte d’affichage
Le choix du format d’image conditionne à la fois le poids du fichier et la qualité perçue. Trois formats dominent le web actuel, chacun avec un cas d’usage précis.
- AVIF : format le plus récent, pris en charge officiellement dans Google Images depuis le 1er aout 2024. Il offre une compression supérieure à WebP pour un rendu équivalent, mais l’encodage est plus lent et le support navigateur n’est pas encore universel sur les anciennes versions.
- WebP : bon compromis entre compatibilité navigateur et ratio poids/qualité. Il gère la transparence et l’animation, ce qui en fait un remplaçant fiable du PNG et du GIF.
- JPEG : reste pertinent pour les photographies destinées à des contextes où la compatibilité maximale prime, notamment les newsletters et certains clients mail.
La balise HTML <picture> permet de proposer AVIF en priorité, WebP en repli et JPEG en dernier recours. Le navigateur charge automatiquement le format le plus performant qu’il sait décoder. Cette approche progressive évite de sacrifier la compatibilité au profit de la légèreté.
Balise alt et nommage de fichier : ce que Google lit vraiment
Les moteurs de recherche ne voient pas les pixels. Ils s’appuient sur des signaux textuels pour comprendre le contenu d’une image et décider de l’afficher dans Google Images.
Le premier signal est le nom du fichier. Un fichier nommé « robe-lin-bleu-marine.jpg » transmet une information sémantique claire. Un fichier nommé « IMG_4872.jpg » n’en transmet aucune. Ce renommage se fait avant l’upload, pas après.
Le second signal est la balise alt (attribut alt de la balise img). Elle décrit le contenu de l’image en une phrase courte, destinée aux lecteurs d’écran et aux robots d’indexation. Une balise alt efficace contient le sujet principal de l’image et, quand c’est naturel, un mot-clé lié à la page. Remplir le alt avec une liste de mots-clés séparés par des virgules est contre-productif : Google interprète cela comme du keyword stuffing.
Attribut title et données structurées
L’attribut title (l’infobulle au survol) n’a pas d’impact direct sur le classement. Il peut améliorer l’accessibilité dans certains cas, mais consacrer du temps au remplir systématiquement n’est pas prioritaire.
Les données structurées (schema.org) associées aux images, en revanche, permettent d’afficher des résultats enrichis. Google a resserré ses règles sur les images dans les données structurées : l’image déclarée dans le balisage structuré doit exister et être accessible, sous peine de perdre l’éligibilité aux rich results.
Compression des images sans perte visible : les seuils utiles
Compresser une image revient à réduire la taille du fichier en supprimant des données redondantes ou imperceptibles. Deux types de compression coexistent.
La compression sans perte (lossless) réduit le poids sans altérer un seul pixel. Le gain reste modeste, souvent insuffisant pour des photographies. La compression avec perte (lossy) supprime des détails que l’œil humain ne distingue pas à taille d’affichage web. Le gain de poids est nettement plus marqué.
Pour le JPEG et le WebP, un réglage qualité entre 75 et 85 sur une échelle de 100 produit en général un bon équilibre entre poids et rendu. Pour l’AVIF, les réglages par défaut des encodeurs modernes donnent déjà des résultats compétitifs.
Redimensionner avant de compresser
Servir une image aux dimensions exactes d’affichage est le geste le plus rentable. Charger une photo de 4000 pixels de large pour l’afficher à 800 pixels gaspille de la bande passante et du temps de décodage. Le redimensionnement se fait côté serveur ou via un CDN d’images, jamais uniquement via CSS.
L’attribut srcset permet de déclarer plusieurs tailles de la même image. Le navigateur choisit la version adaptée à la largeur de l’écran et à la densité de pixels. Ce mécanisme réduit le poids transféré sur mobile sans dégrader l’affichage sur écran Retina.
L’optimisation des images pour les moteurs de recherche ne se limite pas à compresser un fichier. Elle articule format, dimensions, balisage et stratégie de chargement autour d’un objectif mesurable : le LCP. Chaque image correctement traitée libère du poids, accélère la page et offre un point d’entrée supplémentaire via Google Images.
