Ceci dit, les trucs qui déclenchent les recalculs de page, ce sont surtout des images dont il n’y a pas les tailles, par exemple dans des tables, etc…

A mon avis, le plus grand saut de performance vient du passage de la mise en page par tableaux à la mise en page par CSS. (et souvent, quand on fait ça, on a peu de problèmes de syntaxe restants)
Après, ce dont tu parles ici, ça peut surtout provoquer des problèmes de rendu, mais pas trop de performance, et en tout cas c’est négligeable.

Autant passer du temps sur les algorithmes utilisés dans vos scripts, ce temps sera plus utile 🙂

Sinon, une remarque quand même: ne faites pas n’importe quoi, les élements déclarés EMPTY dans la dtd ne doivent jamais être fermés avec une autre balise, et en XHTML doivent uniquement être fermés avec /> (slash-plus grand que, si le html est strippé dans les commentaires 🙂

Je viens de faire un test (sur Firefox 3 uniquement), et les résultats sont assez similaires.

Le test est constitué d’une liste de 10 000 lignes, chacune contenant un paragraphe de texte fictif. Pour la version « HTML4 balises ouvertes », les balises <p> et <li> ne sont pas fermées.

Le temps passé en millisecondes est relevé en début et en fin de document.

Je ne sais pas si ce test est réellement représentatif, mais si l’un d’entre vous a une idée et veut l’améliorer, qu’il n’hésite pas 🙂

Les tests (moyenne sur 20 chargements) :

HTML4 strict, balises ouvertes, text/html : 2.003 secondes
HTML4 strict, balises fermées, text/html : 2.222 secondes
XHTML1 strict, balises fermées, text/html : 2.263 secondes
HTML1.1 strict, balises fermées, application/xhtml+xml : 2.171 secondes

On peut voir que « HTML4 balises ouvertes » est un peu plus rapide que les autres et c’est normal, car la chaîne « </li></p> » est absente sur l’ensemble des lignes.

Le XHTML servi en application/xhtml+xml est en deuxième position, mais l’écart est léger.

Si quelqu’un s’en sent le courage, il pourrait être intéressant d’adapter et de tester ça sur les autres navigateurs (notamment IE puisque Microsoft recommande de fermer les balises).

On pourrait aussi créer une page plus complexe, avec un tableau en table-layout:auto par exemple.

Et consulter le résultat détaillé ici : http://spreadsheets.google.com/pub?key=pEgfOn-yIxmcq2g-FIlHWeg

Vous pouvez télécharger les fichiers de test ici (avec le .htaccess) : http://essais.pierrebertet.net/parsing_html.tar.gz

Au courageux testeur : pour que le script fonctionne sur Internet Explorer, il faudrait remplacer console.log() (Firebug) par window.alert() par exemple, et Date.now() par new Date().getTime().

L’inverse est vrai comme tu l’indiques : les navigateurs savent lire HTML4, ils savent donc très bien lire des balises non fermées, puisque c’est toléré. En XHTML, aucun problème non plus lorsqu’il est envoyé en text/html, ce qui revient pour les navigateurs à lire du HTML.

Bref, je veux simplement dire qu’on ne peut pas, en théorie, se reposer sur la gestion des erreurs par les navigateurs, sauf dans certains cas (spécifications passées ou futures sous certaines conditions par exemple).

C’est d’ailleurs le problème des hacks CSS, qui se basent sur l’interprétation d’erreurs pour cibler certains navigateurs.

PS : Désolé pour le hors-sujet, cela n’a pas grand chose à voir avec les performances de nos pages…

Cette technique était vraiment énormément utilisé du temps des tableaux, cela faisait gagner beaucoup en terme de poids des pages. Le gain est le plus important sur les tableaux bien entendu ( et ).

Ce n’est sans doute pas vraiment d’actualité aujourd’hui si l’on génère du HTML contenant le moins possible de mise en forme ?
Ok, en n’aillant pas de chiffres on va garder ce prb à l’esprit…

Je classerai tout de même ça dans les problématiques mineures (les majeures étant les javascripts bloquants, les questions de cache et d’expiration, le nombre de requêtes HTTP, etc.).

Bref, probablement pas de quoi reprendre vos pages mais si vous définissez des conventions de codages pour votre entreprise ça ajoute un argument supplémentaires pour y spécifier « mettre des balises fermantes explicites » pour prendre ça comme convention par défaut.

J’ai prévu tout de même de faire quelques tests parce que autant c’était quelque chose de connu, autant je suis surpris que ça apparaisse explicitement dans deux de leurs documents publics à propos de performance.

Attention Pierre, je crois qu’il faut bien faire la distinction entre code invalide et le fait que l’on puisse ne pas spécifier la balise fermante en HTML !

Concernant ce 2eme cas (code valide mais toutes les balises pas fermées comme le permet HTML), dont j’ai été le 1er à user massivement au temps des HTML pleins de mise en forme en tableau, j’entends cet argument mais sans mesures chiffrées j’ai du mal à juger quelle criticité lui donner ? Existe-t-il des mesures sur lesquelles on pourrait se baser quelque part ?

En se reposant sur la manière dont les navigateurs interprètent les erreurs dans la structure HTML, on prend le risque d’obtenir des effets inattendus, maintenant ou dans l’avenir.

Exemple déjà vu : un <a href="url"> dans un <a href="url">.
Ce n’est évidemment pas valide et absurde.

Dans ce cas, Firefox place le premier à la suite de l’autre, tandis qu’IE (de mémoire) les laisse imbriqués.

Aucun n’est en faute, puisqu’aucun document dans la recommandation HTML n’indique comment corriger chaque erreur pouvant se produire : c’est logique, car en dehors de l’aspect titanesque d’un tel travail, une recommandation a pour but d’indiquer aux auteurs comment produire du code, et aux éditeurs comment l’interpréter. Si HTML n’est pas rigoureusement respecté, ce n’est plus du HTML, au sens strict.

Ceci dit, cette logique est à nuancer : par exemple, on sait tous que l’ajout d’un attribut inexistant ne pose pas de problème, et qu’il est donc possible d’utiliser les attributs data- de la future recommandation HTML5 dès aujourd’hui.