Un client nous appelle un mardi matin : ses images produits ont disparu de Google Images. On ouvre la Search Console, aucune baisse d’indexation visible, les ALT sont propres. On lance Lighthouse : LCP à 4.5 secondes sur mobile, le plus grand élément est une image de héros chargée en full résolution, sans fetchpriority. On a passé une heure à corriger les métadonnées, alors que le problème n’était pas là. L’image ne rankait plus parce que Googlebot ne la voyait plus comme un élément prioritaire de la page, noyé dans un LCP dégradé.
L’attribut ALT n’a jamais été un facteur de classement direct
L’ALT text décrit l’image au moteur, il ne la positionne pas. Son absence rend l’image incompréhensible, son remplissage excessif la rend suspecte. Mais une fois l’image correctement décrite, le bénéfice SEO marginal est proche de zéro. Ce qui déplace vraiment les lignes, c’est la capacité de Googlebot à accéder rapidement au fichier et la qualité de la page qui l’héberge. Si le LCP explose à cause de cette même image, la page perd du terrain sur toutes ses requêtes, et l’image avec elle.
Le LCP et les images, le vrai levier de visibilité
Le Largest Contentful Paint mesure le temps que met l’élément visuellement le plus important à apparaître. Dans une majorité de cas, cet élément est une image de héros, un visuel produit ou une bannière. Quand on travaille sur l’optimisation des Core Web Vitals, on se rend vite compte que les images sont le premier levier. Un LCP maintenu sous 2.5 secondes envoie un signal fort aux algorithmes : la ressource est disponible immédiatement, elle mérite d’être servie en priorité.
Tu veux mesurer l’impact ? Déploie une version corrigée avec fetchpriority="high" sur l’image principale et un préchargement via <link rel="preload"> pour le fichier clé. Observe dans la Search Console le nombre d’impressions Google Images sous 48 heures. La corrélation n’est pas garantie, mais sur les projets où le LCP passe de plus de 4 secondes à moins de 2 secondes, on constate généralement un rebond de l’indexation des images associées. Googlebot consacre un crawl budget limité à chaque site : s’il passe moins de temps à attendre des ressources lourdes, il explore plus d’images.
⚠️ Attention : Le
preloadpeut concurrencer d’autres ressources critiques. Teste toujours avec un throttling réseau réaliste dans Chrome DevTools (Fast 3G) pour vérifier que tu ne retardes pas le chargement des polices ou du CSS critique.
Certains sites chargent encore des images en 3000px de large pour un conteneur de 400px. Le redimensionnement côté navigateur n’est pas gratuit. Il consomme du CPU et peut impacter l’INP sur les pages interactives. Servir l’image à la bonne résolution, via srcset et sizes, réduit le poids téléchargé et accélère le décodage. Le LCP n’est qu’une facette : une galerie d’images avec des aperçus non optimisés peut dégrader l’expérience utilisateur et, par ricochet, les signaux comportementaux qui influencent le classement.
AVIF, WebP, JPEG : le bon format n’est pas toujours le plus récent
On pourrait croire qu’AVIF écrase tout. Sa compression est effectivement supérieure, mais le décodage est plus lourd. Sur un parc mobile hétérogène, un fichier AVIF trop agressif peut faire grimper le time to decode et dégrader l’INP sur une page où l’utilisateur interagit avec une galerie. Le WebP offre un bon compromis, mais un JPEG progressif bien configuré avec un taux de compression maîtrisé reste plus rapide à décoder sur les CPU bas de gamme. La règle n’est pas de tout convertir en AVIF, mais de tester le temps de décodage réel via les onglets Performance de Chrome pour les images critiques. Si une image met plus de 50 ms à se décoder sur un Moto G4 simulé, elle risque de peser sur l’interactivité.
Le choix du format doit aussi tenir compte de la compatibilité avec les crawlers. Googlebot supporte AVIF depuis 2024, mais si votre audience utilise des navigateurs anciens (notamment des WebViews intégrées dans des apps), une version JPEG de secours reste nécessaire. La balise <picture> permet de proposer plusieurs sources et de laisser le navigateur choisir.
Le lazy-loading natif qui peut cacher vos images à Googlebot
L’attribut loading="lazy" a simplifié la vie de millions de sites, mais son application systématique à toutes les images, y compris celle affichée immédiatement dans le viewport, est une erreur. Le navigateur retarde le téléchargement de l’image, Googlebot aussi. Résultat : l’image la plus importante de la page est dépriorisée, le LCP s’envole et l’image perd en visibilité.
Supprime loading="lazy" sur l’image située dans la partie visible sans scroll, en particulier le visuel de produit ou le logo de marque. Réserve le lazy-loading aux images situées en dessous de la ligne de flottaison. Associe-le à une balise img avec des dimensions explicites width et height pour éviter les réorganisations de layout (CLS). Une image qui apparaît brutalement après coup pénalise l’UX et envoie un signal négatif.
Responsive images : srcset sans sizes ne sert à rien
L’attribut srcset propose plusieurs résolutions de la même image. Sans sizes, le navigateur se comporte comme si la largeur du viewport était celle de l’image, et charge souvent la version la plus grande par défaut. Le piège est classique : un srcset avec trois variantes et l’absence de sizes conduit à servir une image de 2000px de large sur un mobile de 375px de large.
La solution : définir sizes en fonction des points de rupture réels de ton layout. Sur une fiche produit, la taille du conteneur est souvent fixe : (max-width: 600px) 100vw, 600px. Le navigateur choisit alors la source la plus proche. Teste avec un console.table des entrées performance.getEntriesByType('resource') filtrées sur les images pour vérifier quel fichier est réellement chargé sur chaque appareil.
Le sitemap image, un signal low-cost
Le sitemap image fournit à Google une liste des fichiers avec des métadonnées (légende, titre, emplacement géographique). Il ne remplace pas une bonne accessibilité technique. Si tes images sont chargées via JavaScript et ne sont pas découvertes dans le DOM initial, le sitemap peut accélérer leur indexation. Il reste utile pour les images hébergées sur un CDN avec des URLs complexes.
Mais si ton serveur répond en 503 ou si l’image est bloquée dans le robots.txt, le sitemap ne changera rien. Commence par un curl -I sur l’URL de l’image pour vérifier le code HTTP et les headers de cache. Un Cache-Control trop court oblige Googlebot à refetch l’image fréquemment, ce qui grève le crawl budget.
Images générées en SSR et rendu côté client : le piège du double chargement
Les frameworks React et Next.js simplifient le rendu côté serveur, mais l’hydratation peut provoquer un double chargement des images si le DOM diffère entre le serveur et le client. L’image est d’abord téléchargée dans le HTML statique, puis réévaluée lors de l’hydratation, ce qui peut déclencher une seconde requête. Le symptôme : une entrée dupliquée dans l’onglet Network, un LCP dégradé.
Pour les galeries ou les images dont l’état dépend de l’interaction, un state manager léger aide à éviter les re-rendus inutiles. On utilise Zustand pour stabiliser les références des objets d’image entre les rendus, ce qui empêche le navigateur de relancer des téléchargements déjà terminés. La clé est de ne pas recréer les URLs signées ou les chemins dynamiques à chaque changement d’état.
Quand tu migres vers App Router, vérifie que tes composants image renvoient exactement le même markup côté serveur et côté client. Une différence infime (un slash final dans l’URL de l’image, une absence d’extension) peut suffire à déclencher un refetch.
Questions fréquentes
Faut-il encore utiliser l’attribut TITLE sur les images ?
L’attribut title n’a plus d’impact SEO mesurable. Il peut servir à afficher une info-bulle pour l’utilisateur, mais son absence ne pénalise pas l’indexation. Mieux vaut investir le temps de rédaction dans une légende pertinente, qui enrichit le contexte sémantique de la page.
Les images en base64 intégrées en inline, bonne ou mauvaise idée ? Pour les très petites icônes, l’inline peut économiser une requête. Pour tout le reste, cela alourdit le HTML, empêche la mise en cache séparée et gonfle le temps de parsing du DOM. Googlebot doit télécharger un document plus lourd, ce qui ralentit le crawl. Le SVG inline pour des icônes reste acceptable.
Comment vérifier que Googlebot voit bien mes images ?
Ouvre la Search Console, partie “Images”, et filtre par URL. Tu peux aussi utiliser l’outil d’inspection d’URL avec un rendu “Googlebot smartphone” pour visualiser le chargement. Enfin, un simple curl -A "Googlebot" sur l’URL de l’image te confirme que le fichier est accessible sans redirection inattendue.
