Faut-il vraiment spécifier width et height dans le HTML pour ranker ?

Pourquoi les attributs width et height ont-ils un impact SEO ?

La réponse tient en trois lettres : CLS (Cumulative Layout Shift). Quand le navigateur charge une page sans connaître les dimensions des images, il ne peut pas réserver l'espace nécessaire. Résultat : le contenu se déplace brusquement quand l'image apparaît.

Ce phénomène agace les utilisateurs, mais surtout — et c'est ce qui nous intéresse — il fait partie des Core Web Vitals. Google mesure ces déplacements et les intègre dans son algorithme de classement depuis plusieurs années. Alan Kent le dit franchement : ne pas spécifier ces attributs génère un signal négatif.

Quelle est la différence entre le CSS et les attributs HTML ?

Beaucoup de développeurs définissent les dimensions des images uniquement en CSS. Le problème ? Le navigateur doit d'abord télécharger et analyser le CSS avant de connaître ces dimensions. Pendant ce délai — même court — l'espace n'est pas réservé.

Avec les attributs width et height directement dans le HTML, le navigateur connaît instantanément les dimensions, avant même de charger le CSS ou l'image. Il peut donc réserver le bon espace dès le premier rendu. C'est cette anticipation qui évite le déplacement.

Tous les types d'images sont-ils concernés ?

Oui, sans exception. Que ce soit des images de contenu, des visuels produits, des bannières ou même des logos — toute balise <img> devrait avoir ses attributs width et height. Les images en background CSS ne sont pas concernées par cette recommandation spécifique.

• Les attributs width et height réduisent directement le CLS, un des trois Core Web Vitals
• Ces attributs doivent être placés dans le HTML, pas uniquement en CSS
• Le navigateur peut réserver l'espace avant le chargement de l'image
• Cette pratique s'applique à toutes les balises img du site
• L'absence de ces attributs constitue un signal négatif pour Google

Cette déclaration change-t-elle vraiment quelque chose ?

Soyons honnêtes : cette recommandation n'est pas nouvelle. Les specs HTML existent depuis des décennies, et les bonnes pratiques de performance web martelent ce point depuis l'arrivée des Core Web Vitals. Ce qui change, c'est la confirmation explicite qu'il s'agit d'un signal SEO négatif.

Sur le terrain, on observe effectivement une corrélation nette entre sites bien classés et faibles scores CLS. Mais attention — corrélation n'est pas causalité. Le CLS n'est qu'un facteur parmi des centaines. Un site avec un CLS parfait mais un contenu médiocre ne surclassera jamais un concurrent pertinent.

Quelle ampleur d'impact faut-il anticiper ?

Voilà où ça coince. Google ne quantifie jamais le poids relatif de ses facteurs de classement. Alan Kent parle d'un "signal négatif", mais sans préciser son intensité. [À vérifier] : est-ce qu'on parle d'une micro-pénalité ou d'un vrai handicap compétitif ?

Les tests A/B menés sur des sites e-commerce montrent généralement des gains modestes — rarement plus de quelques positions sur des requêtes déjà bien travaillées. L'impact est plus visible sur des sites techniquement négligés où le CLS explose. Mais si vos concurrents directs ont déjà optimisé ce point, le corriger vous ramène simplement à parité.

Dans quels cas cette règle pose-t-elle problème ?

Les images chargées dynamiquement via JavaScript posent question. Si vous utilisez un système de lazy loading custom ou un framework qui injecte les images côté client, spécifier width et height devient plus complexe — mais reste possible avec les bonnes techniques.

Les images dont les proportions varient selon le contexte (art direction, recadrage contextuel) nécessitent aussi une approche plus sophistiquée, souvent via <picture> et srcset. Dans ces cas, chaque source doit avoir ses propres dimensions spécifiées.

Que faut-il faire concrètement sur un site existant ?

Premier réflexe : auditer votre CLS via Google Search Console, section "Signaux Web essentiels". Si vous êtes dans le rouge ou l'orange, les images sans dimensions sont probablement en cause. PageSpeed Insights détaille précisément quelles images génèrent du layout shift.

Ensuite, l'intervention technique. Sur un site statique ou un CMS classique, ajouter width et height est généralement simple — c'est surtout fastidieux si vous avez des milliers d'images. Sur WordPress, des plugins comme Perfmatters ou WP Rocket peuvent automatiser cette tâche pour les nouvelles images.

Pour les sites avec du contenu généré dynamiquement, il faut que votre backend calcule et injecte ces attributs lors de la génération HTML. Ça implique souvent de stocker les métadonnées d'images en base ou de les calculer à la volée — une opération qui peut ralentir le serveur si elle est mal optimisée.

Quelles erreurs éviter pendant l'implémentation ?

Erreur classique : mettre des dimensions fantaisistes juste pour satisfaire l'outil d'audit. Si vous spécifiez width="500" height="300" alors que l'image fait réellement 1200×800, le navigateur va devoir recalculer — et potentiellement créer du layout shift quand même.

Autre piège : oublier les images en lazy loading. Même une image qui se charge tardivement doit avoir ses dimensions spécifiées, sinon elle provoquera un déplacement au moment où elle apparaît dans le viewport.

• Auditer le CLS actuel via Search Console et PageSpeed Insights
• Identifier toutes les balises <img> sans attributs width/height
• Récupérer les dimensions réelles de chaque image (pas les dimensions d'affichage CSS)
• Implémenter une solution automatisée pour les nouveaux uploads
• Vérifier que le responsive design fonctionne toujours correctement
• Tester sur mobile ET desktop après déploiement
• Re-mesurer le CLS après quelques jours pour valider l'amélioration

Comment mesurer l'impact réel après correction ?

Google Search Console met à jour ses données de Core Web Vitals avec un décalage de 28 jours. Ne vous attendez donc pas à voir des changements immédiats. Utilisez les outils temps réel (Chrome DevTools, WebPageTest) pour valider techniquement que le CLS a baissé.

Côté rankings, traquez vos positions sur vos requêtes stratégiques avant et après l'optimisation. Mais isoler l'impact spécifique de cette modification sera difficile — trop de variables bougent simultanément. L'essentiel est de confirmer que vous n'avez pas cassé quelque chose et que la tendance générale reste positive.