Les sites HTML statiques sont-ils vraiment à l'abri des problèmes de Core Web Vitals ?

Pourquoi cette mise au point de Google sur les sites HTML statiques ?

Il existe une idée reçue tenace dans la communauté SEO : les sites HTML statiques seraient naturellement performants et exempts de problèmes de Core Web Vitals. Cette croyance découle du fait que JavaScript est souvent pointé du doigt comme principal responsable des mauvaises performances web.

Google prend ici le contre-pied de cette simplification. Martin Splitt souligne qu'un site peut être techniquement simple — du HTML pur sans framework lourd — et afficher pourtant des métriques CWV catastrophiques. La complexité technique n'est pas le seul facteur déterminant.

Quel est le problème principal identifié sur ces sites ?

Le coupable récurrent ? Les images non dimensionnées qui chargent sans que le navigateur connaisse à l'avance leur taille finale. Lorsqu'une image de 800px de hauteur apparaît brutalement dans le viewport après le rendu initial, tout le contenu en dessous se décale violemment.

Ce phénomène génère du Cumulative Layout Shift (CLS), l'une des trois métriques Core Web Vitals. Et contrairement à ce qu'on pourrait penser, le problème se produit même si l'image charge rapidement — c'est le décalage visuel qui pose problème, pas la vitesse de chargement en tant que telle.

En quoi cela concerne-t-il concrètement les praticiens SEO ?

Pour les consultants SEO, cette déclaration rappelle qu'un audit de performance ne peut pas se limiter à analyser le poids du JavaScript ou les appels API. Un site WordPress basique avec un thème léger peut très bien échouer sur les CWV à cause de photos mal intégrées.

Cela signifie aussi que vos clients propriétaires de sites vitrines — souvent persuadés que leur "simple site HTML" est optimal — peuvent avoir des problèmes invisibles pour eux mais pénalisants pour le référencement. La perception de simplicité technique ne garantit rien.

• Les Core Web Vitals touchent tous les types de sites, quelle que soit leur stack technique
• Le CLS causé par les images est un problème fréquent même sur des sites HTML statiques
• L'absence d'attributs width et height sur les balises <img> est le facteur de risque principal
• Un site techniquement simple peut afficher de mauvaises performances si les fondamentaux ne sont pas respectés
• L'audit de performance doit systématiquement inclure une vérification des images, pas seulement du JavaScript

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

Absolument. Sur le terrain, on constate régulièrement que des sites développés "à l'ancienne" — HTML/CSS basique, peu de scripts — affichent des scores CLS désastreux. Le réflexe de nombreux développeurs consiste encore à intégrer des images sans spécifier leurs dimensions, comptant sur le navigateur pour "s'adapter".

Ce que Splitt ne dit pas explicitement mais qui mérite d'être souligné : le problème s'aggrave avec le responsive design mal implémenté. Une image qui s'affiche à 100% de la largeur du conteneur sans hauteur définie va créer un layout shift différent sur mobile et desktop, rendant l'audit plus complexe.

Quelles nuances faut-il apporter à cette affirmation ?

Première nuance : si les sites HTML peuvent avoir des problèmes de CWV, ils restent statistiquement plus performants que les SPAs mal optimisées. La déclaration de Google ne doit pas être interprétée comme "tous les sites se valent". Un site statique mal codé reste généralement plus rapide qu'une application React surchargée.

Deuxième point : Google mentionne les "images trop grandes" mais ne précise pas le seuil. [À vérifier] À partir de quelle dimension une image devient-elle problématique ? Un visuel de hero de 2000px de large est-il acceptable si les attributs de dimensions sont présents ? La déclaration reste floue sur les critères quantitatifs.

Dans quels cas cette règle s'applique-t-elle le plus souvent ?

Les sites les plus vulnérables sont ceux qui intègrent du contenu éditorial avec beaucoup de visuels : blogs, sites d'actualités, portfolios créatifs. Les rédacteurs y ajoutent des images via des CMS sans se soucier des aspects techniques, et les templates ne forcent pas toujours les bonnes pratiques.

À l'inverse, les sites e-commerce ont généralement des systèmes de gestion d'assets qui normalisent les images, même sur des stacks simples. Le problème y est moins systématique, même si les carrousels de produits peuvent générer du CLS s'ils ne réservent pas l'espace correctement.

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

Première action : auditer systématiquement toutes les balises <img> du site pour vérifier la présence des attributs width et height. Un simple crawl avec Screaming Frog ou Sitebulb permet d'extraire les images qui en sont dépourvues.

Ensuite, intégrer ces dimensions dans le HTML, même si le CSS applique ensuite un max-width: 100%. Le navigateur utilise le ratio width/height pour réserver l'espace nécessaire avant le chargement complet de l'image, évitant ainsi le layout shift.

Pour les sites avec beaucoup de contenu existant, il peut être judicieux d'automatiser cette correction via un script qui calcule les dimensions réelles des images et injecte les attributs manquants. Sur WordPress, des plugins comme Perfmatters peuvent aider, mais une intervention manuelle reste souvent préférable pour un contrôle total.

Quelles erreurs éviter lors de l'optimisation des images ?

Erreur courante : définir des dimensions arbitraires qui ne correspondent pas au ratio réel de l'image. Si vous spécifiez width="800" height="400" pour une image qui fait réellement 800x600, le navigateur réservera le mauvais espace et vous aurez quand même du CLS au chargement.

Autre piège : appliquer du lazy loading sur les images above the fold. Les visuels visibles immédiatement ne doivent jamais être en lazy load — cela retarde leur affichage et génère du CLS. Réservez cette technique aux images situées plus bas dans la page.

Enfin, ne négligez pas les images de background CSS. Elles ne bénéficient pas des attributs HTML width/height et peuvent causer du CLS si le conteneur n'a pas de hauteur définie. Utilisez des techniques comme aspect-ratio ou des padding-bottom calculés pour réserver l'espace.

Comment vérifier que mon site respecte les bonnes pratiques ?

Utilisez PageSpeed Insights et observez spécifiquement la section "Éviter les changements de disposition importants". L'outil identifie les éléments responsables du CLS et indique souvent les images sans dimensions comme coupables.

En complément, testez manuellement sur connexion 3G throttlée. Le CLS est souvent invisible sur connexion rapide car les images chargent avant que vous ne scrolliez. En ralentissant artificiellement la connexion, vous verrez exactement ce que vivent vos utilisateurs mobiles.

Pour un suivi dans le temps, configurez des alertes Search Console sur les problèmes CWV. Google vous notifiera si des pages basculent dans la zone rouge, vous permettant d'intervenir rapidement avant que cela n'impacte le ranking.

• Ajouter systématiquement les attributs width et height sur toutes les balises <img>
• Vérifier que les dimensions spécifiées correspondent au ratio réel de l'image
• Ne jamais appliquer de lazy loading sur les images above the fold
• Auditer les images de background CSS et réserver l'espace via aspect-ratio ou padding-bottom
• Tester régulièrement les CWV avec PageSpeed Insights et sur connexion throttlée
• Configurer des alertes Search Console pour détecter les régressions de performance