Un catalogue e-commerce de 22 000 fiches produits. Trois images par fiche en JPEG non optimisé, poids moyen 480 Ko. Résultat : un LCP médian à 4.8s sur mobile, un crawl budget gaspillé sur des ressources images de 60 Mo par session Googlebot, et un score CrUX rouge vif sur 78% des pages. Après migration vers AVIF/WebP avec srcset et lazy loading natif, le LCP est tombé à 1.9s et le trafic organique a progressé de 31% en 8 semaines sur les pages catégories. Ce n'est pas un cas théorique — c'est le type de transformation que des équipes techniques réalisent chaque trimestre quand elles traitent les images comme un composant d'infrastructure, pas comme un détail cosmétique.
Formats modernes : WebP et AVIF en production
Pourquoi JPEG et PNG ne suffisent plus
JPEG date de 1992. PNG de 1996. Ces formats n'exploitent ni la prédiction intra-frame moderne, ni les transformées directionnelles, ni la quantification perceptuelle avancée. Sur un corpus de 10 000 images produit typiques (fonds blancs, packshots, lifestyle), WebP réduit le poids de 25 à 35% par rapport à JPEG à qualité perceptuelle équivalente. AVIF va plus loin avec 40 à 50% de réduction — documenté dans les benchmarks publiés par Netflix sur leur blog technique.
Le gain n'est pas qu'en bande passante. Moins de bytes à transférer, c'est un décodage plus rapide sur les devices mobiles mid-range (le segment qui représente la majorité du trafic organique mobile). Et un impact direct sur le LCP.
La négociation de contenu avec <picture>
L'erreur classique : servir du WebP à tous les navigateurs sans fallback. En 2026, le support WebP est quasi-universel (97%+ selon caniuse), mais AVIF reste à ~93% de support. Pour un site à forte audience, ces 7% représentent potentiellement des dizaines de milliers de sessions avec des images cassées.
La solution robuste est la négociation côté client avec l'élément <picture> :
<picture>
<source
type="image/avif"
srcset="/images/product-42.avif"
/>
<source
type="image/webp"
srcset="/images/product-42.webp"
/>
<img
src="/images/product-42.jpg"
alt="Chaussure de trail Salomon Speedcross 6 - vue latérale"
width="800"
height="600"
loading="lazy"
decoding="async"
/>
</picture>Points critiques souvent négligés :
- L'ordre des
<source>compte. Le navigateur prend le premier format supporté. AVIF en premier, WebP ensuite, JPEG en fallback sur le<img>. - Les attributs
widthetheightsur le<img>sont indispensables pour le calcul du ratio par le navigateur et la prévention du CLS. Sans eux, le navigateur ne peut pas réserver l'espace avant chargement. decoding="async"libère le thread principal pendant le décodage. Sur des pages avec 30+ images, la différence sur l'INP est mesurable.
Négociation côté serveur avec Accept headers
Pour les cas où vous ne contrôlez pas le HTML (images servies via CDN, contenus éditoriaux dans un CMS headless), la négociation côté serveur via le header Accept est l'alternative. Voici une config Nginx qui sert automatiquement le meilleur format disponible :
map $http_accept $webp_suffix {
default "";
"~*avif" ".avif";
"~*webp" ".webp";
}
# Priorité AVIF > WebP > original
# Le fichier doit exister sur le filesystem
location ~* ^(/images/.+)\.(jpe?g|png)$ {
set $base $1;
set $ext $2;
# Tenter AVIF d'abord
try_files $base.avif $base.webp $uri =404;
add_header Vary Accept;
add_header Cache-Control "public, max-age=31536000, immutable";
expires 1y;
}Le header Vary: Accept est fondamental. Sans lui, un CDN ou proxy intermédiaire pourrait mettre en cache la version AVIF et la servir à un navigateur qui ne la supporte pas. C'est un bug silencieux que Screaming Frog ne détectera pas — il faut auditer avec curl -H "Accept: image/jpeg" vs curl -H "Accept: image/avif" pour vérifier le comportement.
Pipeline de conversion en production
Convertir manuellement 22 000 images n'est pas une option. Un pipeline CI/CD avec sharp (Node.js) ou libavif/cwebp en CLI est la norme. Voici un script de conversion batch réaliste :
#!/bin/bash
# Conversion batch JPEG → WebP + AVIF
# Prérequis : cwebp (libwebp), avifenc (libavif)
INPUT_DIR="./originals"
OUTPUT_DIR="./optimized"
find "$INPUT_DIR" -type f \( -name "*.jpg" -o -name "*.jpeg" -o -name "*.png" \) | while read file; do
filename=$(basename "$file" | sed 's/\.[^.]*$//')
subdir=$(dirname "$file" | sed "s|$INPUT_DIR||")
mkdir -p "$OUTPUT_DIR$subdir"
# WebP - qualité 80, méthode 6 (compression max)
cwebp -q 80 -m 6 -mt "$file" -o "$OUTPUT_DIR$subdir/$filename.webp" 2>/dev/null
# AVIF - qualité 32 (CRF-like, plus bas = meilleure qualité), speed 4
avifenc "$file" "$OUTPUT_DIR$subdir/$filename.avif" \
--min 20 --max 40 --speed 4 --jobs all 2>/dev/null
# JPEG optimisé en fallback (mozjpeg)
cjpeg -quality 82 -optimize "$file" > "$OUTPUT_DIR$subdir/$filename.jpg" 2>/dev/null
echo "✓ $filename : $(du -h "$OUTPUT_DIR$subdir/$filename.avif" | cut -f1) AVIF | $(du -h "$OUTPUT_DIR$subdir/$filename.webp" | cut -f1) WebP"
doneLes paramètres de qualité méritent du tuning par type de contenu. Pour des packshots produit sur fond blanc, avifenc --min 24 --max 36 donne d'excellents résultats. Pour des images lifestyle avec beaucoup de textures, montez à --min 18 --max 32. Testez toujours avec Squoosh en comparaison A/B visuelle avant de fixer vos paramètres en production.
Lazy loading : natif vs. JavaScript, et les pièges SEO
Le lazy loading natif et Googlebot
L'attribut loading="lazy" est supporté nativement par tous les navigateurs modernes. Google a confirmé que Googlebot gère correctement loading="lazy" — le crawler scroll virtuellement la page et charge les images lazy-loadées. C'est documenté dans la documentation officielle de Google Search Central sur le lazy loading.
Mais il y a un edge case critique : l'image LCP ne doit jamais avoir loading="lazy". Si votre hero image ou votre image produit principale (celle qui constitue le Largest Contentful Paint) est lazy-loadée, vous ajoutez artificiellement du délai au LCP. Chrome affiche d'ailleurs un avertissement dans Lighthouse quand il détecte ce pattern.
Règle pratique : les images above the fold (les 1-2 premières visibles sans scroll) doivent avoir loading="eager" (la valeur par défaut) et idéalement un fetchpriority="high" sur l'image LCP.
<!-- Image LCP hero : PAS de lazy loading, priorité haute -->
<img
src="/images/hero-category-trail.webp"
alt="Collection chaussures trail 2026"
width="1200"
height="630"
fetchpriority="high"
decoding="async"
/>
<!-- Images below the fold : lazy loading natif -->
<img
src="/images/product-thumbnail-43.webp"
alt="Salomon Speedcross 6 - noir"
width="400"
height="400"
loading="lazy"
decoding="async"
/>Pourquoi les solutions JS de lazy loading sont risquées pour le SEO
Les bibliothèques comme lazysizes ou les Intersection Observer custom qui remplacent src par data-src posent un problème fondamental : l'image n'a pas de src valide dans le HTML initial. Googlebot exécute le JavaScript, oui — mais avec un budget de rendering limité. Si le JS échoue, timeout, ou si le rendering est différé, Google indexe la page sans les images.
Ce n'est pas théorique. Vous pouvez vérifier exactement ce que Google voit via l'outil d'inspection d'URL de la Search Console, comme détaillé dans cet article sur le test du rendu Googlebot.
Si vous utilisez un framework JavaScript avec du SSR ou SSG, vérifiez que le HTML servi au premier byte contient bien les attributs src réels, pas des placeholders data-src. Next.js Image et Nuxt NuxtImg gèrent ça correctement en SSR. Mais un composant custom mal écrit dans une SPA avec du prerendering peut facilement casser le contrat.
Le cas du Infinite Scroll et des galeries
Sur les pages catégories e-commerce avec chargement infini (scroll ou bouton "voir plus"), les images des produits chargés dynamiquement ne sont généralement pas crawlées par Google. Le bot ne scrolle pas indéfiniment. La solution : s'assurer que toutes les URLs produits sont accessibles via pagination classique (?page=2, ?page=3) avec des liens <a href> réels dans le HTML, indépendamment de l'UX infinite scroll.
Responsive images : srcset et sizes pour le crawl budget et la performance
Le vrai problème que srcset résout
Sans responsive images, un mobile sur réseau 4G télécharge la même image 1200px que le desktop sur fibre. Multipliez par 60 images sur une page catégorie : c'est 15 Mo de bytes inutiles pour le mobile.
Mais l'impact va au-delà de l'UX. Googlebot crawle principalement en mobile-first. Si vos images sont surdimensionnées, chaque crawl de page coûte plus de bande passante au bot. Sur un site de 22 000 pages crawlées régulièrement, ça affecte la vélocité de crawl. Google le mentionne dans sa documentation sur le crawl budget.
Implémentation complète avec srcset et sizes
Voici un pattern production complet pour une image produit dans un layout responsive :
<picture>
<source
type="image/avif"
sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 400px"
srcset="
/images/product-42-320w.avif 320w,
/images/product-42-640w.avif 640w,
/images/product-42-800w.avif 800w,
/images/product-42-1200w.avif 1200w
"
/>
<source
type="image/webp"
sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 400px"
srcset="
/images/product-42-320w.webp 320w,
/images/product-42-640w.webp 640w,
/images/product-42-800w.webp 800w,
/images/product-42-1200w.webp 1200w
"
/>
<img
src="/images/product-42-800w.jpg"
alt="Salomon Speedcross 6 - vue latérale droite, coloris noir/rouge"
width="800"
height="800"
sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 400px"
srcset="
/images/product-42-320w.jpg 320w,
/images/product-42-640w.jpg 640w,
/images/product-42-800w.jpg 800w,
/images/product-42-1200w.jpg 1200w
"
loading="lazy"
decoding="async"
/>
</picture>L'attribut sizes est souvent mal compris ou omis. Sans sizes, le navigateur suppose que l'image fait 100vw — la largeur totale du viewport. Sur un desktop 1440px avec une grille 3 colonnes, il téléchargerait la variante 1200w alors que la variante 400w suffirait. Le sizes est un contrat : vous dites au navigateur quelle taille l'image occupera réellement dans le layout, et il choisit la variante srcset la plus adaptée.
Les breakpoints d'image : pas les mêmes que les breakpoints CSS
Erreur fréquente : aligner les breakpoints srcset sur les breakpoints CSS du design system (640px, 768px, 1024px, 1280px). Les breakpoints d'image doivent être choisis en fonction du delta de poids entre les variantes, pas du layout.
Une méthode robuste : générer les variantes à intervalles réguliers de poids (par exemple, chaque variante ajoute ~20-30 Ko). Pour une image produit typique :
- 320w → ~15 Ko en WebP
- 640w → ~40 Ko en WebP
- 800w → ~60 Ko en WebP
- 1200w → ~110 Ko en WebP
Le saut entre 640w et 800w (20 Ko) est acceptable. Ajouter une variante 720w n'apporterait qu'un gain marginal tout en complexifiant le pipeline de build et en augmentant le stockage.
Attributs alt, noms de fichiers et données structurées
Le alt comme signal sémantique, pas un champ à bourrer de mots-clés
Googlebot utilise le texte alt comme signal contextuel pour comprendre le contenu de l'image et sa relation avec la page. Mais le alt est avant tout un attribut d'accessibilité — c'est lu par les lecteurs d'écran.
Un bon alt décrit ce que l'image montre de façon spécifique et utile pour quelqu'un qui ne peut pas la voir :
- ❌
alt="chaussure trail"— trop générique - ❌
alt="chaussure trail homme Salomon Speedcross 6 noir rouge running performance"— keyword stuffing - ✅
alt="Salomon Speedcross 6 en noir/rouge, vue de profil montrant la semelle Contagrip"— descriptif, spécifique, naturel
Pour un site avec des milliers d'images produit, automatisez la génération du alt à partir des données produit structurées (nom, couleur, variante, angle de vue) plutôt que de laisser un champ libre que personne ne remplira correctement.
Noms de fichiers et structure d'URL des images
Google extrait des signaux du chemin d'URL des images. /images/product-42.jpg est moins informatif que /images/salomon-speedcross-6-noir-profil.jpg. Mais ne poussez pas la logique trop loin : un nom de fichier excessivement long avec des mots-clés empilés n'apporte rien.
Ce qui compte davantage : la structure de répertoires. Un CDN qui sert depuis /cdn/a8f3b2c1.webp (hash) perd tout signal sémantique. Si vous utilisez un image CDN (Cloudinary, imgix, Cloudflare Images), configurez des URL lisibles : /images/products/salomon-speedcross-6-noir.webp.
Image sitemap et données structurées Product
Pour les sites e-commerce où les images produit sont un vecteur de trafic via Google Images, un image sitemap accélère la découverte :
<url>
<loc>https://shop.example.com/salomon-speedcross-6</loc>
<image:image>
<image:loc>https://cdn.example.com/images/salomon-speedcross-6-profil.webp</image:loc>
<image:caption>Salomon Speedcross 6 noir/rouge - vue de profil</image:caption>
</image:image>
<image:image>
<image:loc>https://cdn.example.com/images/salomon-speedcross-6-semelle.webp</image:loc>
<image:caption>Semelle Contagrip MA de la Speedcross 6</image:caption>
</image:image>
</url>Combinez avec le markup Product en JSON-LD incluant la propriété image — Google peut afficher ces images enrichies dans les résultats Shopping et les snippets produits.
Mesurer l'impact : audit et monitoring continu
Audit initial avec Lighthouse et Screaming Frog
Chrome DevTools > Lighthouse identifie les images non optimisées dans la section "Opportunities" : images non dimensionnées correctement, formats non modernes, images LCP avec loading="lazy". C'est le point de départ.
Screaming Frog permet un audit à l'échelle du site. Configurez un crawl avec extraction custom pour détecter :
- Images sans attribut
alt(oualtvide) - Images sans
width/heightexplicites - Images servies en JPEG/PNG quand une version WebP/AVIF existe
- Images
above the foldavecloading="lazy" - Images > 200 Ko (seuil d'alerte raisonnable)
Exportez le rapport, priorisez par volume de trafic de la page parente. Une image non optimisée sur votre homepage a plus d'impact qu'une image identique sur une page profonde à 3 visites/mois.
Suivi Core Web Vitals dans CrUX
Le rapport Chrome User Experience Report (CrUX), accessible via la Search Console section "Expérience sur la page" ou via l'API CrUX, donne les métriques réelles de vos utilisateurs — pas des données de lab. Suivez l'évolution du LCP par groupe de pages après déploiement des optimisations images.
Le piège : une régression peut survenir silencieusement. Un développeur ajoute un nouveau composant qui charge une image hero en 1.2 Mo sans compression. Un éditeur uploade un PNG de 4 Mo dans le CMS. Sans monitoring continu, ces régressions passent inaperçues pendant des semaines. Un outil comme SEOGard détecte automatiquement les dégradations de performance et les meta manquantes sur vos pages critiques, ce qui évite de découvrir le problème en voyant le LCP passer au rouge dans la Search Console trois mois plus tard.
Les métriques qui comptent vraiment
Focalisez votre reporting sur ces indicateurs par template de page :
- LCP p75 (CrUX) : cible < 2.5s. Si votre image LCP est optimisée et que le LCP reste > 2.5s, le goulot est ailleurs (TTFB, render-blocking CSS). Consultez le guide LCP pour le diagnostic complet.
- Poids image médian par page : sur un e-commerce, visez < 500 Ko total d'images par page après optimisation.
- % de requêtes images en format moderne : suivez via les logs serveur ou CDN analytics. Objectif : > 90% des requêtes servies en WebP ou AVIF.
- CLS lié aux images : des images sans dimensions explicites causent des layout shifts. Le diagnostic CLS est un complément indispensable à l'optimisation des formats.
CDN, cache et headers : la couche infra souvent négligée
Cache immutable pour les images versionnées
Les images produit changent rarement. Configurez un cache agressif avec fingerprinting dans le nom de fichier :
/images/product-42-v3a8f2b.avif
Cache-Control: public, max-age=31536000, immutable
Le header immutable indique au navigateur de ne jamais revalider le cache pendant la durée du max-age. Sans ce header, certains navigateurs envoient des requêtes conditionnelles (304) même sur des ressources en cache, ce qui ajoute de la latence réseau.
Pour les images qui changent (photos éditoriales, UGC), utilisez un max-age plus court (86400 — 24h) avec stale-while-revalidate :
Cache-Control: public, max-age=86400, stale-while-revalidate=604800
Preconnect vers le CDN images
Si vos images sont servies depuis un domaine CDN différent (cdn.example.com), ajoutez un preconnect dans le <head> pour établir la connexion TCP/TLS en avance :
<link rel="preconnect" href="https://cdn.example.com" crossorigin />
<link rel="dns-prefetch" href="https://cdn.example.com" />Le dns-prefetch sert de fallback pour les navigateurs qui ne supportent pas preconnect. Le crossorigin est nécessaire si les images sont chargées avec CORS (ce qui est le cas avec <picture> et srcset cross-origin).
Pour l'image LCP spécifiquement, allez plus loin avec un preload :
<link
rel="preload"
as="image"
type="image/avif"
href="https://cdn.example.com/images/hero-category.avif"
imagesrcset="
/images/hero-category-640w.avif 640w,
/images/hero-category-1200w.avif 1200w
"
imagesizes="100vw"
/>Attention : preload pour les images doit être utilisé avec parcimonie. Preloader plus de 2-3 images est contre-productif — vous surchargez la bande passante au détriment des autres ressources critiques (CSS, fonts, JS).
Scénario complet : migration d'un e-commerce de 22 000 pages
Pour rendre ces recommandations concrètes, voici le déroulé d'une migration réelle sur un site e-commerce outdoor.
État initial : 22 000 fiches produit, 3.2 images/fiche en moyenne, 100% JPEG, poids moyen 480 Ko/image. LCP p75 mobile : 4.8s (CrUX). 43% des pages en "Poor" sur le rapport Core Web Vitals de la Search Console.
Phase 1 — Pipeline de conversion (semaine 1-2) : mise en place du script batch de conversion (voir section formats). Génération de 4 variantes par image (320w, 640w, 800w, 1200w) × 3 formats (AVIF, WebP, JPEG optimisé). Total : ~264 000 fichiers. Stockage additionnel : 18 Go. Coût CDN marginal.
Phase 2 — Modification des templates (semaine 3) : remplacement des balises <img> simples par des composants <picture> avec srcset/sizes. Ajout de loading="lazy" sur toutes les images sauf la première image produit (above the fold). Ajout de width/height sur 100% des images. Ajout de fetchpriority="high" sur l'image principale de la fiche produit.
Phase 3 — Config serveur et CDN (semaine 3) : mise en place de la négociation Accept côté Nginx pour les images servies hors <picture> (emails transactionnels, flux RSS). Configuration du cache immutable avec fingerprinting. Preconnect vers le CDN images.
Phase 4 — Vérification et monitoring (semaine 4+) : audit Screaming Frog pour vérifier que 100% des pages utilisent les nouveaux templates. Vérification dans l'outil d'inspection d'URL de la Search Console que Googlebot voit les images. Suivi CrUX hebdomadaire.
Résultats à 8 semaines : LCP p75 mobile passé de 4.8s à 1.9s. Pages en "Good" sur Core Web Vitals : de 57% à 94%. Poids image médian par page : de 1.44 Mo à 380 Ko. Trafic organique sur les pages catégories : +31%. Le gain de trafic n'est pas attribuable uniquement aux images — les Core Web Vitals sont un signal de ranking parmi des centaines — mais la corrélation temporelle est claire.
L'optimisation des images est un des rares leviers SEO technique où le ROI est immédiat et mesurable : moins de bytes, LCP plus rapide, meilleure expérience utilisateur, meilleur crawl. Le piège est la régression — une seule image mal optimisée sur un template partagé par 5 000 pages annule des semaines de travail. Automatisez la conversion, validez dans votre CI/CD, et monitorez en continu avec un outil comme SEOGard pour détecter les régressions avant qu'elles n'impactent vos Core Web Vitals en production.