J’ai beaucoup parlé de CSS, de réseau, de javascript, et j’entend parfois dire que le HTML lui n’a aucune importance. Ce n’est malheureusement pas vrai. Il y a au moins trois points à regarder dans le HTML : la qualité syntaxique du code, le mode de rendu des tableaux, et le nombre de noeuds DOM.
Je vous détaille le premier ici, les deux autres bénéficieront d’un billet dédié afin de mieux organiser les commentaires.
La syntaxe HTML
On vous dira par endroits que faire du code valide, suivant la norme HTML strictement, permettra d’améliorer les performances, d’améliorer votre référencement, et de faire le café. Ce n’est pas tout à fait vrai, mais un peu quand même (sauf pour le café).
Si vous avez des erreurs de syntaxe à répétition dans votre code, le navigateur va tenter de vous corriger. Suivant les cas il est possible qu’il arrête son rendu progressif et attende la fin du document pour savoir quelle correction appliquer et calculer l’ensemble de la page. Il est aussi possible qu’il tente une correction puis change d’avis quand il reçoit le reste du HTML, provoquant un recalcul du rendu. Dans les deux cas vous avez des problèmes de performance.
C’est d’ailleurs vrai même entre deux pages HTML bien formées : bien que facultatif, fermer toutes vos balises explicitement peut aider le navigateur à faire son travail plus facilement. C’est au point que Microsoft met ça en septième position dans son article Building High Performance HTML Pages (réaliser des pages HTML hautes performances).
Par ailleurs, la manière dont ces corrections sont appliquées est propre à chaque navigateur.
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.
Bonjour,
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 ?
Je n’ai pas de mesure à donner, je n’ai pas encore fait de test.
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.
Tiens, au passage, j’ai cru vaguement comprendre qu’une page déclarée en application/xhtml+xml serait traitée plus rapidement qu’en bon vieux text/html. Ça semble « logique », mais quid en pratique?
Pardon je n’ai peut être pas été assez explicite tout à l’heure…
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…
Pierre Goiffon :
Tout à fait ! C’est pourquoi dans ma dernière phrase je donnais l’exemple d’attributs non valides aujourd’hui, mais qui le seront un jour : ça ne pose pas de problème aujourd’hui (il suffit de tester pour s’en apercevoir), et il est raisonnable de penser qu’à l’avenir, aucun navigateur n’aura de problème pour les interpréter puisqu’ils sont prévus pour HTML5.
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…
@Benjamin: J’en doute, mais je suis preneur des chiffres (accompagné du jeu de test) si tu as le courage de le vérifier.
Benjamin, Eric :
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:autopar 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) parwindow.alert()par exemple, etDate.now()parnew Date().getTime().La remarque de Benjamin ne me surprendrait pas, vrai parseur XML par rapport à un parseur HTML plein de hacks, ca doit être mieux 🙂
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 🙂
Les li et p sont des balises assez simples parce que il sait automatiquement quoi fermer. il faudrait chercher un test qui prend en compte plus de difficultés, c’est à dire avec quelques erreurs de syntaxes cumulées à des balises non fermées qui imposent au navigateur de faire et refaire des corrections au fur et à mesure que le HTML est interprêté. Ca doit pouvoir être fait sur des balises de tableau, mais ça demande de bosser pas mal de temps à chercher ce que réalise le navigateur pour lui imposer le chemin le plus complexe.
Le billet http://ln.hixie.ch/?start=1138169545&count=1 de Ian Hickson est un bon point de départ sur les corrections DOM et ce que ça peut entrainer.
Et ne pas oublier qu’il y a des balises qu’on ne peut pas refermer avec <script />. par exemple 🙂
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 🙂
@Julien: moi je veux bien, je n’ai pas encore fait de test donc je ne vais pas te contredire fortement, mais c’est Microsoft qui affirme que les balises non fermées impactent les performance. J’ai tendance à les croires quant à leur moteur.