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…