Pourquoi les dimensions d'image dans le HTML sont-elles devenues incontournables pour le CLS ?

Qu'est-ce que le CLS et pourquoi les images posent-elles problème ?

Le Cumulative Layout Shift mesure l'instabilité visuelle d'une page pendant son chargement. Les images sans dimensions explicites sont la cause numéro un de ces décalages.

Quand le navigateur rencontre une balise <img> sans attributs width/height, il ne peut pas anticiper l'espace à réserver. Il affiche d'abord le texte, puis charge l'image qui repousse brutalement le contenu vers le bas — exactement ce que le CLS pénalise.

Comment les dimensions HTML résolvent-elles le problème ?

En déclarant width="800" height="600", le navigateur calcule le ratio d'aspect avant même de charger l'image. Il réserve immédiatement l'espace correct, même si l'image pèse 2 Mo et met 3 secondes à arriver.

Les navigateurs modernes utilisent ces dimensions pour créer un placeholder proportionnel via CSS. Résultat : zéro décalage au moment où l'image s'affiche réellement.

Cette recommandation s'applique-t-elle à tous les types d'images ?

Techniquement oui, mais l'impact varie. Les images above the fold (visibles immédiatement) sont critiques — c'est là que le CLS se joue dans les premières secondes.

Pour les images lazy-loadées en bas de page, l'urgence est moindre puisque le CLS principal est déjà calculé. Mais maintenir une cohérence reste une bonne pratique.

• Les dimensions HTML permettent au navigateur de réserver l'espace avant le chargement
• Cette pratique corrige la majorité des problèmes CLS liés aux images
• L'impact est maximal pour les images visibles immédiatement (above the fold)
• Les navigateurs modernes calculent automatiquement le ratio d'aspect à partir de width/height
• Même avec du lazy-loading, les dimensions restent nécessaires pour éviter les sauts visuels

Cette recommandation est-elle vraiment nouvelle ?

Non, et c'est presque gênant. Spécifier les dimensions d'image dans le HTML était une pratique standard du web 1.0, abandonnée à l'ère du responsive design par peur que width="800" fixe la taille en dur.

Sauf que depuis 2019, les navigateurs interprètent ces attributs différemment : ils calculent un ratio d'aspect, pas une taille absolue. Le CSS prend le relais avec max-width: 100%; height: auto; pour le responsive. Google ne fait que répéter ce que les dev web sérieux font déjà depuis 5 ans.

Tous les CMS gèrent-ils correctement ces dimensions ?

WordPress ajoute automatiquement width/height depuis la version 5.5 (2020). Shopify et la plupart des CMS modernes font pareil. Mais — et c'est là que ça coince — les thèmes custom, les builders visuels mal codés et les images insérées manuellement via éditeurs WYSIWYG oublient souvent ces attributs.

Pire : certains développeurs les suppriment volontairement en pensant "faire du responsive". Résultat, des sites récents avec des scores CLS catastrophiques alors que la solution tient en deux attributs HTML.

Cette pratique suffit-elle à elle seule pour un bon CLS ?

Soyons honnêtes : non. Les dimensions d'image règlent le problème le plus fréquent, mais pas les seuls responsables de CLS. Les bannières publicitaires qui s'insèrent dynamiquement, les web fonts qui chargent tardivement (FOIT/FOUT), les iframes d'embeds sociaux sans hauteur définie — tout ça dégrade aussi le CLS.

Google simplifie volontairement le message pour toucher le maximum de sites. Mais un vrai audit CLS regarde bien au-delà des seules images. [À vérifier] : l'impact réel de cette seule optimisation sur des sites avec des sources multiples de layout shift.

Comment vérifier si mes images ont bien leurs dimensions ?

Ouvre la console développeur de Chrome (F12), inspecte une image et regarde si les attributs width et height sont présents dans le HTML source. Pas dans le CSS — dans le balisage HTML lui-même.

Pour un audit complet, utilise Screaming Frog en mode "Images" avec l'option "Missing Width/Height Attributes". Tu verras immédiatement toutes les images non conformes. PageSpeed Insights signale aussi ce problème dans la section "Diagnostics" sous "Image elements do not have explicit width and height".

Que faire si mon CMS n'ajoute pas ces dimensions automatiquement ?

Première étape : vérifie la version de ton CMS et mets-le à jour. WordPress 5.5+, Shopify, Webflow gèrent ça nativement. Si tu es sur un CMS custom ou une vieille version, il faut intervenir au niveau du template ou du plugin de gestion d'images.

Pour WordPress, si ton thème supprime ces attributs, ajoute dans functions.php :

add_filter('wp_img_tag_add_width_height_attr', '__return_true');

Pour du pur HTML/PHP, assure-toi que tes fonctions de génération d'images incluent systématiquement ces attributs. C'est du code de base, mais beaucoup de devs l'oublient.

Quelles erreurs éviter lors de l'implémentation ?

Ne mets jamais de valeurs arbitraires ou fausses juste pour "cocher la case". Si ton image fait 1200×800 mais que tu mets width="100" height="100", le navigateur réservera un carré — puis l'image réelle va tout décaler quand même. Les dimensions doivent correspondre aux proportions réelles du fichier source.

Autre piège : ne pas adapter ces dimensions pour les images responsive avec srcset. Dans ce cas, utilise les dimensions de l'image par défaut (celle du src), pas celles des variantes. Le navigateur ajustera proportionnellement.

• Audite toutes les images de ton site avec Screaming Frog ou PageSpeed Insights
• Vérifie que ton CMS est à jour et ajoute automatiquement width/height
• Pour WordPress, force l'activation via le filtre wp_img_tag_add_width_height_attr
• Contrôle que les dimensions correspondent aux proportions réelles des fichiers
• Ne confonds pas dimensions HTML et taille d'affichage CSS — ce sont deux choses différentes
• Teste ton CLS réel avec Chrome User Experience Report ou Lighthouse avant/après
• N'oublie pas les images dans les éléments dynamiques (sliders, modales, contenus AJAX)