Faut-il vraiment spécifier les dimensions des images pour corriger le CLS ?

En quoi les dimensions d'images influencent-elles le CLS ?

Le Cumulative Layout Shift (CLS) mesure l'instabilité visuelle d'une page — chaque fois qu'un élément se déplace sans intervention de l'utilisateur, le score se dégrade. Les images sans dimensions explicites posent un problème classique : le navigateur ne connaît pas leur taille finale avant de les télécharger.

Résultat ? Il affiche d'abord un espace vide ou arbitraire, puis reflow la page une fois l'image chargée. Ce décalage brutal pénalise le CLS, surtout sur mobile où la bande passante est capricieuse.

Que signifie exactement « spécifier les dimensions » ?

Il s'agit d'ajouter les attributs width et height directement dans la balise <img>. Ces valeurs n'ont pas besoin d'être exactes en pixels absolus — le CSS peut les redimensionner via max-width: 100% — mais elles doivent respecter le ratio d'aspect de l'image.

Le navigateur utilise ces informations pour calculer l'espace nécessaire dès le parsing du HTML, avant même de télécharger le fichier. C'est un mécanisme natif, rapide, et qui ne nécessite aucune librairie tierce.

Cette pratique est-elle nouvelle ou juste rappelée ?

Elle existait déjà dans les premières recommandations du W3C, mais avait été largement abandonnée avec l'arrivée du responsive design. Beaucoup de développeurs ont supprimé ces attributs par peur qu'ils rigidifient la mise en page.

Sauf que les navigateurs modernes ont évolué : ils comprennent désormais le aspect-ratio intrinsèque et ajustent l'espace réservé même quand le CSS redimensionne l'image. Google ne fait que réactualiser une bonne pratique oubliée, adaptée aux Core Web Vitals.

• Les dimensions HTML permettent au navigateur de pré-allouer l'espace avant le téléchargement
• Le CSS peut toujours contrôler la taille finale via width: 100% et height: auto
• Cette méthode fonctionne nativement sans JavaScript ni framework
• Le ratio d'aspect doit être respecté pour éviter les déformations
• Les images lazy-loaded bénéficient aussi de ce traitement

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, et c'est même une des interventions les plus efficaces pour corriger le CLS rapidement. Sur des sites où les images n'avaient pas de dimensions, on observe régulièrement des baisses de CLS de 30 à 50% juste en ajoutant width et height. Pas de magie, juste de la mécanique navigateur.

Par contre — et Alan Kent ne le précise pas — cette solution ne règle que les décalages causés par les images. Si votre CLS provient de publicités qui s'injectent dynamiquement, de bannières cookies sans espace réservé, ou de polices web qui reflow le texte, spécifier les dimensions d'images ne changera rien. Il faut diagnostiquer la cause réelle avant d'appliquer le remède.

Dans quels cas cette technique ne suffit-elle pas ?

Les images dont le ratio change selon le viewport — typiquement via <picture> ou srcset avec des crops différents — peuvent poser problème. Si l'image desktop est en 16:9 et la version mobile en 4:3, spécifier une seule paire de dimensions ne suffit pas. [À vérifier] : certains frameworks modernes gèrent ça via CSS custom properties, mais ce n'est pas documenté par Google de manière exhaustive.

Autre cas délicat : les images chargées via JavaScript après interaction utilisateur. Si votre script insère une balise <img> sans dimensions dans le DOM, le navigateur n'a aucun moyen de prévoir l'espace nécessaire. Il faut alors dimensionner le conteneur parent en CSS ou calculer le ratio avant injection.

Quelle est la meilleure méthode pour implémenter ça à grande échelle ?

Sur un site de quelques pages, tu peux corriger manuellement. Sur un site de plusieurs milliers d'URLs avec des images gérées par des rédacteurs non-techniques, il faut automatiser au niveau du serveur ou du système de templating. WordPress fait ça nativement depuis la version 5.5, mais encore faut-il que le thème n'écrase pas ces attributs.

Pour les sites custom, l'idéal est d'extraire les métadonnées EXIF ou de lire les dimensions au moment de l'upload, puis de stocker ces valeurs en base. Le template se charge ensuite de les injecter dans le HTML. Si tu utilises un CDN avec transformation d'images, certains comme Cloudinary ou Imgix peuvent ajouter ces attributs automatiquement via leur SDK.

Que faut-il faire concrètement sur son site ?

Première étape : auditer le HTML de vos pages principales. Inspectez les balises <img> et vérifiez si width et height sont présents. Un script Chrome DevTools peut lister toutes les images sans dimensions en quelques secondes.

Ensuite, déterminez où sont générées ces balises. Thème WordPress ? Template Liquid sur Shopify ? Composant React ? Une fois la source identifiée, ajoutez les attributs soit manuellement, soit via un hook ou un helper de templating.

Pour les images déjà en ligne, vous pouvez récupérer leurs dimensions via un script serveur qui parse les fichiers avec une lib comme ImageMagick ou Sharp (Node.js). Stockez ces valeurs en base ou dans un fichier JSON, puis injectez-les au rendering.

Comment vérifier que l'implémentation corrige bien le CLS ?

Utilisez PageSpeed Insights ou Lighthouse en mode mobile pour mesurer le CLS avant/après. Comparez les scores sur plusieurs pages représentatives, pas juste la homepage. Le CLS peut varier énormément selon le contenu.

En complément, ouvrez Chrome DevTools, onglet Performance, et enregistrez le chargement de la page en throttling 3G. La timeline vous montrera visuellement les moments où le layout shift se produit. Si les images n'apparaissent plus comme source de décalage, c'est gagné.

• Auditer les balises <img> pour identifier celles sans width/height
• Vérifier que le ratio spécifié correspond bien aux dimensions réelles de l'image
• Tester le comportement responsive : l'image ne doit pas se déformer avec width: 100%; height: auto;
• Contrôler que les images lazy-loaded conservent aussi leurs dimensions
• Mesurer le CLS avant/après avec PageSpeed Insights et Chrome DevTools
• Automatiser l'extraction des dimensions au moment de l'upload ou du build
• Vérifier que le CMS ou le framework ne supprime pas ces attributs au rendering