Code HTML propre versus HTML poubelle ?

[nantesweb]

Bon,

Même si j'ai une bonne partie de la réponse je la pose quand même pour avoir votre point de vue.

A votre avis est ce qu'un code HTML propre versus code HTML que j'appelle "poubelle" (genre 10 balises divs et span pour entourer un mot) généré par nos chers éditeurs "3 clics" à une quelconque importance ou incidence ?

J'ai basculé moi même sur ces éditeurs qui ajoutent des briques à Gutenberg (pour ne pas court-circuiter Wordpress) il y a quelques années, avant je codais toujours mes thèmes à la main pour avoir un maximum de main sur la qualité du code et sa référençabilité (ex: je pouvais par exemple mettre un lien seo uniquement dans le footer de l'accueil ou de certaines pages les plus côtées, rajouter des Michael JSON optimisés) et je n'ai pas vu que ça posait de problème (heureusement, 97% des sites commerciaux sont fait avec).

Vous allez trouver ma question débile je sais, j'ai l'habitude, mais comme GG passe son temps à vouloir un code de plus en plus détaillé, avec parfois des paramètres spécifiques dans les balises spécifiques pour indiquer ça ou ça, sans parler maintenant qu'il scanne les erreurs de design quand c'est carrément pas la différence de contraste entre le texte et le background - Google Speed - c'est pas un peu le grand écart : entre accepter un code poubelle en dehors des "normes" théoriques du secteur (à savoir séparation du design et du balisage html) et vouloir un balisage précis et propre ?

J'ai toujours pensé avant l'arrivé de Google Speed, que GG avait jeté l'éponge : l'essentiel des sites étant générés avec des outils générant ce code poubelle avec parfois (retour vers 2004) du css en ligne dans les balises avec du styles="" proscrit depuis 15 ans par le W3C. Mais serait-il possible d'envisager un retour en grâce dans les paramètres de l'algo, d'un code propre épuré de centaines de. balises div, span, svg et compagnies bourrées de css en ligne ?

Parce que l'inverse n'est pas vrai. Je n'ai jamais vu de pénalisation de mes sites codé à moitié en CSS et à la main avec Material Design, bien au contraire, ce qui a pu me faire penser (à tord ou pas) que c'était un avantage.

Je suis intéressé par vos retours

 

[rick38]

Ca n'a aucune importance.
Sauf du point de vue des performances (processeur et mémoire sur mobiles peu puissants en particulier)...
Speed Insights met un warning à partir de 800 balises, et une erreur à partir de 1400.
Ca n'est qu'un critère de performance parmi d'autres...
Mais si on veut écouter Google, il ne faut donc ne pas excéder 800 (perso je dépasse 1400 et je m'en fous).
Et le css en ligne n'est pas un problème (c'est même techniquement plus performant que le css dans un fichier même si c'est pas propre)...

 

[nantesweb]

Merci pour l'info,

Je connaissais pas la limite des 800 balises peut-être parce que je l'ai jamais eu (on voit ça où ? Et existe t-il un compteur de balises en ligne ?). Donc tout va bien. J'ai pensé vu comment GG scannait les fichiers des CMS qu'ils mettaient une pénalité aux ancien sites fait en html "tout court". Je pense que ça ça existe. Pas sûr que GG aime référencer les vieux sites pas dynamiques sans php.

 

[elji]

Il y a des années, je vérifiais mes pages avec la validator du W3. Et puis j'ai eu l'idée de tester les pages de très gros sites. J'étais pas le pire, loin de là...

 

[emualliug]

Pas sûr que GG aime référencer les vieux sites pas dynamiques sans php

Et pourquoi donc ? Outre le fait que ce n'est pas forcément décelable (du point de vue de l'internaute, ce n'est de toute façon que du HTML).

Il faut se mettre à la place de l'internaute : c'est cela qui compte, y compris pour Google. L'utilisateur se fout que le site soit dynamique ou statique, en PHP, en rubyonrail, en java, en Go ou autre. En revanche, ce qui compte c'est d'avoir un site rapide, compatible sur divers périphériques (mobiles et autres) et éventuellement sécurisé.

Un nombre imbriqué de balises peut ralentir la lecture du DOM, que Google en tienne compte (quand ça pète les plafonds) n'est pas incohérent.

 

[WebRankInfo]

tant que le code est compréhensible par Google (Chrome), c'est ok, sauf s'il devient tellement complexe que ça fait ramer
cf. règles sur le nb d'éléments imbriqués du DOM https://web.dev/dom-size-and-interactivity/

 

[colonies]

Et le css en ligne n'est pas un problème (c'est même techniquement plus performant que le css dans un fichier même si c'est pas propre)...

Au premier chargement, ça peut être un poil plus rapide. Mais si pour chaque page tu renvoies les styles, qui doivent être téléchargés et parsés, c'est plus lent que si tu avais fait une CSS séparée qui peut utiliser des caches.
Et si tu cherches la performance, avec des CSS séparées, tu peux les précompresser avec Brotli en niveau 11, par exemple.
Enfin bref, il n'y a pas de règle où on peut dire qu'un truc est plus performant qu'un autre : après combien de pages lues, à quelle fréquence sont modifiées les CSS, est-ce qu'elles sont bien séparées au lieu d'en faire une énorme qui contient tous les styles de toutes les pages du site, etc.