Format et taille d'image mobile : quels critères impactent réellement votre SEO ?

Pourquoi Google insiste-t-il encore sur l'optimisation des images mobiles ?

Depuis le mobile-first indexing, Google crawle et indexe prioritairement la version mobile de votre site. Des images lourdes ou mal formatées ralentissent le chargement, dégradent les Core Web Vitals (LCP notamment), et pénalisent directement votre positionnement.

Le problème reste massif sur le terrain : une majorité de sites servent encore les mêmes images desktop aux mobiles, avec des fichiers de 2-3 Mo qui explosent les budgets data des utilisateurs. Google le sait et continue de marteler ce message parce que l'adoption reste trop lente.

Que signifie concrètement « choisir le bon format » ?

Google fait référence aux formats modernes comme WebP, AVIF ou JPEG XL, qui offrent une compression supérieure au JPEG et PNG traditionnels. Un WebP peut réduire le poids de 25-35% à qualité visuelle identique.

Le hic ? La compatibilité navigateur. AVIF offre les meilleures performances mais nécessite un fallback via la balise picture. Si votre stack technique ne permet pas cette souplesse, WebP reste le compromis optimal : support universel depuis 2020, gains significatifs sur le poids.

Qu'entend Google par « images redimensionnées pour correspondre à l'appareil » ?

Servir une image de 1920px de large à un écran mobile de 375px constitue un gaspillage de bande passante évident. Google attend que vous génériez plusieurs versions de chaque image et serviez celle qui correspond à la résolution de l'appareil.

Techniquement, cela passe par les attributs srcset et sizes de la balise img, ou par des solutions côté serveur qui détectent le viewport et servent dynamiquement la bonne taille. Les CDN modernes comme Cloudflare ou ImageKit automatisent ce processus, mais beaucoup de CMS le font mal par défaut.

• Le mobile-first indexing rend les images mobiles critiques pour votre crawl et votre ranking
• Les formats WebP et AVIF réduisent significativement le poids sans perte de qualité perceptible
• Les attributs srcset/sizes permettent de servir des images adaptées à chaque résolution d'écran
• Un mauvais dimensionnement d'image impacte directement le LCP, métrique Core Web Vitals critique pour le SEO
• Les CDN spécialisés automatisent le redimensionnement et la conversion de format à la volée

Cette recommandation suffit-elle à améliorer vos Core Web Vitals ?

Google reste volontairement vague sur les seuils. Optimiser le format et la taille d'image améliore le LCP, certes, mais jusqu'à quel point ? Sur des sites testés en production, le passage JPEG vers WebP + srcset a réduit le LCP de 0,8 à 1,2 secondes en moyenne. Significatif, mais pas miraculeux si votre serveur répond en 3 secondes.

Le vrai piège : Google ne parle pas de lazy loading, de priorité de chargement, ni de preload pour les images above-the-fold. Ces techniques ont un impact souvent plus important que le simple format. [A verifier] : Google laisse entendre que format + taille suffisent, mais les observations terrain montrent que la stratégie de chargement prime.

La compression d'image peut-elle nuire à votre SEO ?

Compresser trop agressivement dégrade la qualité perceptible, surtout sur les écrans Retina qui représentent désormais 60%+ du trafic mobile. Une image floue ou pixelisée augmente le taux de rebond, signal UX que Google capte via Chrome.

L'équilibre est délicat. En pratique, un quality score de 80-85 pour le WebP offre le meilleur compromis poids/qualité pour la majorité des contenus. Les images critiques (produits e-commerce, visuels éditoriaux) méritent un score de 90. Tester sur vrais devices reste indispensable, les simulateurs mentent.

Tous les CMS gèrent-ils correctement le responsive images ?

WordPress génère des srcset depuis la version 4.4, mais avec des breakpoints arbitraires qui ne collent pas forcément à votre design. Shopify fait mieux avec son objet image.srcset Liquid, mais nécessite une configuration manuelle.

Les CMS headless comme Strapi ou Contentful externalisent souvent vers un DAM qui gère ça proprement. Le problème reste les sites custom ou les vieux CMS propriétaires : implémenter un système de redimensionnement dynamique robuste demande du dev backend non trivial. [A verifier] : beaucoup de sites croient avoir du responsive images parce que leur img a un width 100%, mais servent en réalité toujours la même source.

Quelles actions concrètes mettre en œuvre maintenant ?

Commencez par un audit de vos images via PageSpeed Insights ou Lighthouse. Ces outils identifient précisément les images surdimensionnées ou mal formatées. Concentrez-vous d'abord sur les pages stratégiques : home, catégories principales, fiches produits top.

Ensuite, implémentez la génération automatique de versions multiples pour chaque upload. La plupart des CMS modernes le font nativement, mais vérifiez les paramètres : combien de tailles sont générées ? Quels formats ? Si votre stack le permet, activez la conversion WebP automatique et configurez un fallback JPEG pour les vieux navigateurs.

Comment vérifier que votre implémentation fonctionne réellement ?

Inspectez le code source d'une page mobile et cherchez les attributs srcset sur vos balises img. Vous devez voir plusieurs URLs avec des descripteurs de largeur (exemple : image-800w.webp 800w, image-1200w.webp 1200w). Testez ensuite sur un vrai device Android avec DevTools ouvert pour confirmer que le bon fichier est effectivement téléchargé.

Mesurez l'impact sur le LCP avant/après avec un outil comme WebPageTest sur connexion 3G simulée. Si le gain dépasse 500ms, vous êtes sur la bonne voie. En dessous de 200ms, votre goulot d'étranglement est ailleurs (serveur, CSS bloquant, JS tiers).

Quelles erreurs critiques éviter lors de l'optimisation ?

Ne servez jamais une image plus petite que son conteneur sur écrans Retina : l'appareil l'étirera et le résultat sera flou. La règle : servir 1,5x à 2x la taille d'affichage CSS pour ces écrans. Un conteneur de 400px CSS nécessite une image de 600-800px réelle.

Attention aussi au format SVG pour les photos : c'est un format vectoriel inadapté aux images bitmap. Réservez-le aux logos, icônes et illustrations. Enfin, ne négligez pas les attributs width et height sur vos balises img : leur absence cause du layout shift, pénalisant votre CLS.

• Auditer les images avec PageSpeed Insights et prioriser les pages stratégiques
• Activer la génération automatique de multiples tailles et formats (WebP minimum)
• Implémenter srcset et sizes sur toutes les balises img de contenu
• Tester le chargement réel sur devices Android et iOS avec DevTools
• Mesurer l'impact LCP avant/après sur connexion 3G simulée
• Ajouter width/height explicites pour éviter le layout shift