Un site web dont les pages mettent plusieurs secondes à s’afficher perd des visiteurs et recule dans les résultats de recherche. L’optimisation des images joue un rôle direct dans cette équation : les visuels représentent souvent la part la plus lourde d’une page. Réduire leur poids, choisir le bon format, renseigner les attributs HTML adéquats – chaque décision technique modifie la vitesse de chargement et la façon dont les moteurs de recherche indexent le contenu.
AVIF, WebP et stratégie de fallback : le format d’image change la donne
Les guides SEO recommandent de « choisir le bon format d’image ». Dans la pratique, la question ne se résume plus à arbitrer entre JPEG et PNG. AVIF est devenu le format premier choix dans les recommandations techniques récentes, avec WebP comme repli pour les navigateurs qui ne le prennent pas encore en charge.
La différence se joue sur le taux de compression. À qualité perçue équivalente, un fichier AVIF pèse sensiblement moins qu’un WebP, qui lui-même pèse moins qu’un JPEG classique. Pour un site e-commerce affichant des dizaines de visuels produits par page, le gain cumulé sur le poids total est significatif.
La bonne pratique consiste à utiliser la balise HTML <picture> avec plusieurs sources. Le navigateur sélectionne automatiquement le format le plus performant qu’il sait décoder. Sans cette logique de fallback, un visiteur sur un navigateur ancien reçoit soit une image cassée, soit un format non optimisé.
Lazy loading, fetchpriority et LCP : servir la bonne image au bon moment
Le lazy loading (chargement différé) est devenu un réflexe. Il consiste à ne charger les images que lorsqu’elles arrivent dans la zone visible de l’écran. Appliqué correctement, il réduit le temps de chargement initial.
Appliqué sans discernement, il produit l’effet inverse. L’image au-dessus de la ligne de flottaison ne doit pas être en lazy loading. Si le visuel principal de la page – celui que Google mesure via le Largest Contentful Paint (LCP) – est différé, le navigateur attend un signal de défilement qui ne vient jamais à temps. Le LCP se dégrade, et le score Core Web Vitals avec lui.
Plusieurs sources techniques préconisent de marquer cette image prioritaire avec l’attribut fetchpriority="high" ou loading="eager". Le navigateur sait alors qu’il doit la télécharger en priorité, avant les scripts et les autres ressources.
Ce que le LCP mesure concrètement
Le Largest Contentful Paint identifie le plus grand élément visible dans la fenêtre d’affichage. Sur une fiche produit, c’est presque toujours la photo principale. Sur un article de blog, c’est souvent l’image à la une. Optimiser cette image précise a plus d’impact sur le score de performance que compresser toutes les autres réunies.
Dimensions explicites et stabilité du layout : le CLS oublié
Les attributs width et height dans la balise image semblent relever d’un autre âge du web. Ils sont redevenus nécessaires. Sans dimensions explicites, le navigateur ne connaît pas la taille de l’image avant son téléchargement. Il réserve un espace nul, puis décale tout le contenu lorsque l’image apparaît.
Ce décalage porte un nom dans les Core Web Vitals : le Cumulative Layout Shift (CLS). Des dimensions width et height explicites sur chaque image réduisent le CLS parce que le navigateur réserve l’espace correct dès le rendu initial du HTML.
L’attribut srcset complète ce dispositif. Il permet de servir des variantes de taille adaptées à chaque appareil : une image de 400 pixels de large pour un smartphone, une de 1200 pixels pour un écran de bureau. Le poids transféré diminue sur mobile sans sacrifier la netteté sur grand écran.
- Déclarer
widthetheightsur chaque balise<img>pour éviter les décalages de mise en page - Utiliser
srcsetavec plusieurs tailles pour adapter le poids au terminal - Réserver le lazy loading aux images situées sous la ligne de flottaison
- Marquer l’image LCP avec
fetchpriority="high"
Référencement des images dans Google : au-delà du nom de fichier et de l’attribut alt
Nommer un fichier robe-rouge-ete.jpg plutôt que IMG_4532.jpg reste un prérequis. Rédiger un attribut alt descriptif aussi. Ces deux pratiques figurent dans tous les guides SEO depuis des années, et elles restent valides.
Ce qui a évolué, c’est le poids du contexte de page. Google évalue la cohérence entre l’image, le texte qui l’entoure et la thématique globale de la page. Une photo de produit insérée dans un article sans rapport thématique a peu de chances d’apparaître dans les résultats de Google Images, même avec un alt parfait.
Légendes, figcaption et données structurées
La balise <figcaption> offre un signal supplémentaire aux moteurs de recherche. Elle décrit l’image dans un contexte lisible par l’utilisateur, ce qui renforce la pertinence perçue. Pour les sites e-commerce, les données structurées de type ImageObject ou Product permettent d’associer explicitement un visuel à un produit, un prix ou une disponibilité.
L’intégration des images dans un sitemap XML dédié facilite leur découverte par les robots d’indexation. Pour les sites qui publient régulièrement du contenu visuel, ce sitemap accélère la prise en compte de nouvelles images.
- Rédiger un attribut alt qui décrit le contenu réel de l’image, pas un empilement de mots-clés
- Entourer chaque image d’un texte thématiquement cohérent
- Utiliser
<figcaption>pour les visuels qui méritent une légende - Déclarer les images dans un sitemap XML pour faciliter l’indexation
Google Discover et rich results : des exigences de taille d’image spécifiques
Google Discover impose des contraintes que le référencement classique n’exige pas. Pour qu’un article apparaisse dans ce flux de recommandations, les images doivent atteindre une largeur minimale suffisante – les visuels trop petits sont simplement ignorés par l’algorithme de sélection.
Les résultats enrichis (rich results) fonctionnent selon une logique comparable. Un schéma Product sans image conforme ne génère pas de vignette dans les SERP. L’image devient alors un critère d’éligibilité technique, pas seulement un élément visuel.
L’optimisation des images pour le web ne se limite donc pas à la compression. Elle couvre le format, le chargement, la stabilité de la mise en page, le balisage sémantique et les contraintes spécifiques de chaque canal de découverte. Chaque levier pris isolément apporte un gain modeste. C’est leur combinaison qui modifie réellement la vitesse de chargement et le positionnement dans les résultats de recherche.
