Vos images sabotent-elles votre CLS sans que vous le sachiez ?

Pourquoi les images provoquent-elles du Cumulative Layout Shift ?

Le navigateur construit le DOM et calcule la mise en page avant que les ressources externes (images, notamment) ne soient téléchargées. Si aucune dimension n'est spécifiée dans le HTML, le navigateur alloue zéro pixel de hauteur à l'emplacement de l'image.

Quand l'image arrive enfin, le navigateur recalcule la mise en page pour l'intégrer. Tout le contenu situé en dessous se déplace brutalement vers le bas. Ce décalage visuel est mesuré comme du Cumulative Layout Shift, un des trois piliers des Core Web Vitals.

Quelles sont les « utilisations incorrectes » dont parle Google ?

La formulation d'Alan Kent — « si elles sont utilisées incorrectement » — désigne principalement l'absence d'attributs width et height sur les balises <img>. C'est la cause la plus fréquente.

D'autres scénarios incluent les images chargées via JavaScript sans réservation d'espace (lazy loading mal implémenté), les web fonts qui modifient la hauteur de ligne, ou les bannières publicitaires injectées dynamiquement sans conteneur dimensionné. Mais l'erreur de base reste la négligence des dimensions.

Le CLS impacte-t-il réellement le classement Google ?

Oui, depuis la Page Experience Update, le CLS fait partie du signal de classement — mais son poids relatif reste modeste comparé à la pertinence du contenu. Google l'a dit ouvertement : un CLS désastreux ne fera pas plonger une page bien positionnée si elle répond parfaitement à l'intention de recherche.

Cela dit, entre deux pages de qualité équivalente, celle qui affiche un meilleur CLS aura un avantage. Et surtout, un mauvais CLS dégrade l'expérience utilisateur réelle : taux de rebond, engagement, conversions. L'impact indirect peut être brutal.

• Spécifier width et height sur chaque balise <img> est obligatoire pour éviter le CLS.
• Le navigateur utilise le ratio intrinsèque (width / height) pour réserver l'espace, même si l'image est redimensionnée en CSS.
• Les images lazy-loadées doivent aussi avoir des dimensions explicites — le lazy loading n'exempte pas de cette règle.
• Le CLS est un signal de classement faible, mais son impact UX est mesurable sur les métriques business.
• Un CLS élevé sera visible dans les Core Web Vitals de la Search Console et peut déclencher une alerte si le seuil « Good » n'est pas atteint.

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

Absolument. Les audits PageSpeed Insights continuent de pointer les images sans dimensions comme cause numéro un de CLS sur la majorité des sites analysés. Ce n'est pas une nouveauté — Google recommande d'indiquer width et height depuis 2020.

Ce qui interpelle, c'est que cette pratique élémentaire reste négligée. CMS mal configurés, builders visuels qui génèrent du HTML sans dimensions, développeurs qui ignorent le ratio intrinsèque : la réalité du terrain montre qu'un rappel régulier de Google est encore nécessaire. Soyons honnêtes — si Alan Kent en reparle, c'est que le problème persiste à grande échelle.

Quelles nuances faut-il apporter à cette affirmation ?

La déclaration de Google est correcte mais incomplète. Les images ne sont qu'un contributeur parmi d'autres au CLS. Les bannières publicitaires dynamiques, les embeds (YouTube, Twitter), les web fonts mal chargées, les éléments injectés par JavaScript — tout cela peut générer du layout shift, parfois bien plus sévère que celui causé par une simple image.

De plus, certaines images ne provoquent aucun CLS même sans dimensions — celles qui sont au-dessus du fold et chargées en priorité, par exemple, ou celles dont le conteneur parent a une hauteur fixe définie en CSS. Le contexte d'intégration compte autant que les attributs HTML.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Si une image est positionnée en position: absolute ou position: fixed, elle sort du flux normal et ne provoque généralement pas de CLS, même sans dimensions. Mais c'est un cas marginal.

Les images de fond CSS (background-image) ne déclenchent pas de CLS non plus, puisqu'elles ne modifient pas la hauteur calculée du conteneur — à condition que ce conteneur ait une hauteur explicite. Si le conteneur n'a pas de hauteur définie, il sera vide jusqu'au chargement de l'image… mais cela ne comptera pas comme CLS au sens strict (juste une UX dégradée).

Que faut-il faire concrètement pour corriger le CLS lié aux images ?

Ajoutez les attributs width et height sur toutes les balises <img> de vos templates. Ces valeurs doivent correspondre aux dimensions intrinsèques du fichier source, pas à la taille d'affichage finale.

Exemple : si votre image fait 1200×800 pixels et que vous l'affichez en 600px de large via CSS, vous écrivez <img src="photo.jpg" width="1200" height="800" style="max-width:100%; height:auto;">. Le navigateur calcule le ratio (1200/800 = 1.5) et réserve l'espace proportionnellement à la largeur disponible.

Pour les images responsive avec srcset ou <picture>, assurez-vous que toutes les variantes ont le même ratio. Si vous servez une image 16:9 en desktop et 4:3 en mobile, le navigateur ne pourra pas anticiper correctement — vous aurez du CLS au changement de breakpoint.

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

Ne laissez jamais un CMS ou un page builder insérer des images sans dimensions. WordPress, par exemple, ajoute width et height automatiquement depuis la version 5.5 — mais uniquement si le thème n'écrase pas ces attributs. Vérifiez votre thème et vos plugins.

Évitez le lazy loading natif (loading="lazy") sur les images au-dessus du fold. Le navigateur les chargera quand même, mais avec un délai inutile qui peut paradoxalement augmenter le CLS si le rendu initial ne réserve pas l'espace correctement.

Attention aux images servies via CDN avec transformation à la volée (Cloudinary, Imgix, etc.). Si l'URL générée change les dimensions sans que le HTML soit mis à jour, vous créez une incohérence. Automatisez la synchronisation entre les dimensions réelles et les attributs HTML.

Comment vérifier que votre site est conforme ?

Lancez un audit PageSpeed Insights sur vos pages principales. La section « Éviter les décalages de mise en page importants » listera explicitement les éléments responsables du CLS, avec leur contribution mesurée.

Utilisez aussi Lighthouse en local (via Chrome DevTools) pour tester en conditions contrôlées. Activez la simulation de throttling 4G pour voir comment le CLS se comporte avec une connexion lente — c'est souvent là que les problèmes deviennent visibles.

Enfin, consultez le rapport Core Web Vitals dans la Search Console. Si une portion significative de vos URLs est marquée « Nécessite une amélioration » ou « Médiocre » pour le CLS, c'est que le problème est systémique. Priorisez les templates les plus utilisés (page d'accueil, fiches produit, articles de blog).

• Ajouter width et height sur toutes les balises <img> avec les dimensions intrinsèques du fichier source.
• Vérifier que toutes les variantes responsive (srcset, picture) partagent le même ratio d'aspect.
• Ne pas lazy-loader les images au-dessus du fold — les charger en priorité avec fetchpriority="high" si possible.
• Auditer les images injectées par JavaScript (sliders, galeries) et réserver l'espace avant l'injection.
• Tester les pages avec PageSpeed Insights et Lighthouse en throttling 4G.
• Surveiller le rapport Core Web Vitals dans la Search Console pour détecter les régressions.
• Automatiser la synchronisation entre dimensions réelles et attributs HTML si vous utilisez un CDN avec transformation.