Un petit peu de Javascript ? C’est Peter-Paul Koch aussi dit PPK qui lance la question sur Quicksmode il y a trois mois. Il tente de comparer diverses méthodes pour ajouter du contenu à une page, et plus spécifiquement innerHTML et les fonctions DOM (par DOM j’entend appendChild, createElement et associés).
On créé un tableau de 50×50 avec une astérisque dans chaque cellule et on compare. Le résultat est joli, en couleurs : DOM est lent, innerHTML est rapide. On parle d’un facteur 2 à 3, sauf pour Internet Explorer (oui, toujours) où on parle d’un facteur 20 à 30. Oui, vous avez bien lu.
En prenant en compte plus de détails
Ces résultats ne font pas l’unanimité. Laurens Holst met en valeur quelques résultats différents en détaillant le pourquoi. Pour faire court :
Tout d’abord avec innerHTML il faut gérer vous même les caractères spéciaux dans toutes les valeurs. Dans le cas contraire vous risquez des bugs ou des failles de sécurité. Il n’y a malheureusement et étonnament aucune fonction pour ça et ça revient à faire quatre rechercher/remplacer successifs sur chaque contenu de cellule. C’est le genre de choses qui sont transparentes avec DOM. PPK ne le faisait pas pour innerHTML et quand on corrige c’est déjà 40% à 2x plus lent.
Ensuite, le test de PPK utilise des tableaux comme balise HTML. C’est une structure complexe pour le navigateur. En utilisant de bêtes <div> Internet Explorer va déjà 4x plus vite pour DOM.
Enfin, si on utilise le moteur en mode XML au lieu du mode HTML, les performances de DOM sont du même ordre que celles de innerHTML. Internet Explorer se paye même le luxe d’être un peu plus rapide qu’avec innerHTML.
Bref, si on s’arrête aux performances brutes innerHTML reste le meilleur investissement mais la différence n’est pas si importante que ça, surtout si vous êtes obligés d’échapper tous vos contenus avant de les utiliser dans innerHTML. Pour des brides de HTML plus petites que nos tableaux 50×50, la différence est probablement négligeable. Baisser les performances n’est jamais bon mais là, pour le coup, DOM apporte une garantie suffisamment intéressante pour se justifier parfois.
L’important ?
Personnellement je suis bien plus intéressé par ce qui n’est pas très mis en valeur :
Le XHTML proposé en XHTML et pas HTML, pose visiblement beaucoup moins de problèmes aux navigateurs, et donc permet plus d’optimisations. Je regrette que cette possibilité de continuer dans un chemin de simplification par XML n’ai jamais été considéré comme une éventualité intelligente par ceux qui mettent en oeuvre le futur HTML 5.
L’utilisation de innerHTML est un risque majeur si vous ne contrôlez pas parfaitement vos données, il y a des injections de code possible. Ces considérations devraient toujours être prioritaire face aux optimisations de performance. DOM est à envisager au moins pour ça.
Ce que PPK ne dit pas non plus c’est qu’auparavant il avait testé deux types de code DOM : en insérant tous les noeuds un à un immédiatement, ou en construisant l’arbre DOM séparément puis en le rebranchant d’un coup dans le document. C’est cette seconde méthode qui se révèle bien plus performante.
Cloner un noeud DOM existant est toujours plus rapide que recréer un noeud de zéro.
En effet, ne pas prendre ce qu’affirme PPK au pied de la lettre. Il fait des trucs plutôt sympa mais ça manque de rigueur ou il donne trop souvent un avis définitif.
De toute façon, les navigateurs sont en train de se doter de méthodes natives pour la gestion du DOM. Les équipes de développement savent très bien que le DOM représente l’avenir et misent dessus.
Donc le point de vu de PPK, s’il est défendable dans une certaine mesure à présent, ne l’est absolument plus dès lors que l’application que l’on décide de bâtir à vocation à durer — et donc à être prête pour le futur et facile à maintenir, accessoirement.