Pourquoi srcset est-il devenu incontournable pour le SEO mobile ?

Qu'est-ce que srcset et pourquoi Google insiste dessus ?

L'attribut srcset permet de définir plusieurs versions d'une image avec leurs dimensions respectives. Le navigateur choisit automatiquement la version adaptée selon la résolution et la taille d'écran de l'appareil. Google pousse cette pratique car elle réduit drastiquement le poids des pages mobiles, un facteur direct de performance perçue.

Le mobile représente désormais plus de 60% du trafic web. Charger une image desktop 2400x1600px sur un smartphone qui ne peut en afficher que 800x533 constitue un gaspillage de bande passante. Ce gaspillage se traduit par des temps de chargement rallongés, des scores Core Web Vitals dégradés et une expérience utilisateur médiocre.

Quel lien avec les Core Web Vitals ?

Le Largest Contentful Paint (LCP) mesure le temps nécessaire pour afficher le plus gros élément visible. Dans 70% des cas, cet élément est une image. Si cette image pèse 3 Mo au lieu de 200 Ko, le LCP explose. Google a confirmé que LCP fait partie des signaux de ranking depuis la mise à jour Page Experience.

Le Cumulative Layout Shift (CLS) est également concerné. Sans dimensions explicites ou srcset optimisé, les images chargées tardivement provoquent des décalages de mise en page. L'utilisateur clique sur un bouton qui se déplace au dernier moment : frustration garantie et signal négatif pour Google.

Srcset remplace-t-il les autres techniques d'optimisation ?

Non. Srcset complète une stratégie globale d'optimisation. La compression (WebP, AVIF), le lazy loading, et les dimensions explicites (width/height) restent indispensables. Srcset résout spécifiquement le problème du responsive : servir la bonne taille selon l'appareil.

Un piège courant : croire que srcset optimise automatiquement le poids. Faux. Si vos images sources sont mal compressées, srcset servira juste différentes versions de fichiers lourds. L'optimisation de poids et l'adaptation responsive sont deux combats distincts qui se mènent ensemble.

• Srcset adapte la résolution aux capacités de l'écran, réduisant le poids transféré
• LCP et CLS sont directement impactés par la gestion des images mobiles
• Compression et format (WebP/AVIF) restent obligatoires en amont de srcset
• Dimensions explicites (width/height) évitent les reflows pendant le chargement
• Lazy loading natif (loading="lazy") complète srcset pour différer les images hors viewport

Cette recommandation est-elle alignée avec les observations terrain ?

Totalement. Les audits PageSpeed Insights flaggent systématiquement les images non responsive comme opportunité d'optimisation prioritaire. Les sites e-commerce qui ont implémenté srcset rapportent des gains LCP de 30 à 50% sur mobile. Les données Search Console montrent une corrélation claire entre temps de chargement mobile et taux de clic organique.

Un point rarement mentionné : srcset améliore aussi le crawl budget. Googlebot mobile consomme moins de ressources sur des pages légères, ce qui accélère l'indexation des sites volumineux. Sur un catalogue de 50 000 produits avec 10 images chacun, la différence est mesurable en jours de délai d'indexation.

Quelles sont les limites de cette approche ?

Srcset introduit une complexité technique non négligeable. Il faut générer et héberger 3 à 5 versions de chaque image, ce qui multiplie l'espace disque et la charge serveur. Les CMS et frameworks ne gèrent pas tous srcset nativement : WordPress le fait depuis 4.4, mais Magento ou certains headless nécessitent du développement custom.

Autre écueil : la maintenance. Modifier une image produit signifie régénérer toutes ses variantes. Sans automatisation (script build, CDN intelligent), c'est ingérable à l'échelle. Les CDN comme Cloudinary ou Imgix simplifient le process, mais ajoutent un coût et une dépendance externe. [A vérifier] : l'impact réel de srcset sur les positions dans les SERPs reste difficile à isoler des autres facteurs d'optimisation.

Dans quels cas srcset n'apporte-t-il rien ?

Sur des images déjà petites (icônes, logos sous 50 Ko), srcset est inutile voire contre-productif. Le surcoût HTML du markup srcset dépasse parfois le gain de poids image. Pour les sites 100% desktop (B2B niche), l'effort d'implémentation peut ne pas valoir le retour.

Les images non critiques en bas de page, chargées en lazy loading, bénéficient moins de srcset. Si l'image ne s'affiche que lorsque l'utilisateur scroll, et que 80% des visiteurs ne scrollent pas jusque-là, optimiser sa résolution mobile est secondaire. Priorise srcset sur les images above-the-fold et le visuel hero.

Comment implémenter srcset efficacement sur un site existant ?

Commence par un audit des images critiques : identifie les 10-20 visuels qui contribuent au LCP (hero, bannières, première image produit). PageSpeed Insights te donne la liste exacte. Génère pour chacune 3 versions : 400px, 800px, 1200px de largeur, compressées en WebP.

Le code srcset ressemble à ceci : <img src="image-800.webp" srcset="image-400.webp 400w, image-800.webp 800w, image-1200.webp 1200w" sizes="(max-width: 600px) 100vw, 50vw" alt="Description">. L'attribut sizes est crucial : il indique que sur mobile (<600px), l'image occupe 100% de la largeur viewport, sinon 50%. Le navigateur calcule quelle version charger.

Quelles erreurs bloquent les gains de performance ?

Erreur n°1 : oublier width et height dans la balise img. Même avec srcset, sans dimensions explicites, le navigateur ne peut réserver l'espace avant le chargement, provoquant du CLS. Erreur n°2 : servir des images JPEG quand WebP ou AVIF réduiraient le poids de 40%. Srcset sert la bonne taille, mais si le format est obsolète, le gain reste limité.

Erreur n°3 : définir des breakpoints srcset qui ne correspondent pas aux vraies résolutions d'usage. Analytics révèle souvent que 80% des mobiles sont entre 360-430px. Générer une version 320px et une 800px laisse un trou béant. Erreur n°4 : négliger le fallback src. Les vieux navigateurs (IE11) ignorent srcset : si src pointe vers une miniature 200px, ces utilisateurs voient une image pixelisée.

Comment vérifier que srcset fonctionne correctement ?

Ouvre les DevTools Chrome, onglet Network, filtre Images. Charge la page en mode mobile (Device Toolbar). Vérifie que le fichier téléchargé correspond à la version mobile (ex: image-400.webp, pas image-1200.webp). Change la résolution simulée : le navigateur devrait charger une version différente au refresh.

PageSpeed Insights doit retirer l'alerte "Diffuser des images aux bonnes dimensions" après implémentation. Si elle persiste, inspecte l'attribut sizes : une valeur incorrecte pousse le navigateur à choisir la mauvaise variante. Search Console > Expérience > Core Web Vitals doit montrer une amélioration LCP sous 2,5s pour au moins 75% des URL mobiles dans les 28 jours suivant le déploiement.

• Générer 3-5 variantes de chaque image critique (400px, 800px, 1200px minimum)
• Compresser en WebP ou AVIF, pas seulement en JPEG
• Ajouter width et height explicites sur toutes les balises img
• Définir sizes en fonction de la mise en page responsive réelle
• Tester en DevTools Network que la bonne variante est chargée par device
• Monitorer LCP dans Search Console sur 28 jours post-déploiement