Accès DOM

La première étude vient de Dijitalife. L’auteur a comparé le temps nécessaire à l’exécution d’une fonction vide, et comparé avec différent types d’opération. La lecture complète est recommandée. On s’y attend, manipuler un élément prend forcément plus de temps qu’exécuter une fonction vide. Certains temps sont toutefois surprenants.

En comparant la lecture d’un attribut sur un objet javascript et la lecture de l’attribut « id » sur un élément DOM via getAttribute(), on repère facilement le problème. On est six fois plus lent sur Internet Explorer 7, quatorze fois plus lent sur Firefox 3, et deux fois plus lent sur Safari 3. Quatorze ? le chiffre est énorme pour une information aussi simple que l’identifiant d’un élément déjà récupéré. Même en comparant par rapport à la lecture d’un attribut d’objet javascript via un getter, on reste sept fois plus lent sous Firefox 3 (alors que sous Safari, lire dans le DOM ou dans un objet js via un getter est aussi rapide). Je vous invite à lire le tableau de résultats chiffré sur Dijitalife.

Alors voilà : l’accès au DOM est lent, un peu sous Internet Explorer, beaucoup sous Firefox.

Étonnamment, sur ce même Firefox 3.0 qui met longtemps à lire un attribut DOM, récupérer tous les éléments d’un certain type ou l’élément d’un certain identifiant est rapide (2,5 fois plus que la lecture de l’identifiant dans l’objet DOM ainsi récupéré), sous Internet Explorer 7 elle l’est beaucoup moins (3 à 5 fois plus lent que la lecture de l’identifiant dans l’objet DOM récupéré). Je soupçonne Firefox 3 d’utiliser l’index pour la recherche mais de ne pas importer les différents attributs et valeurs de l’objet avant d’en avoir besoin.

Manipulations de l’arbre DOM

Dans tous les navigateurs, la modification du DOM, que ce soit par innerHTML ou createTextNode est lente, mais on s’y attendait. Par contre, changer la valeur className d’un élément est aussi lent que l’utilisation de innerHTML sur Internet Explorer 7 ou Safari 3. Pour Firefox 3 c’est toujours lent, mais bien moins qu’un innerHTML (5 fois plus rapide exactement).

Premières conclusions

Qu’en tirer ? en fait la comparaison entre navigateurs n’apporte pas grand chose par elle-même puisqu’il faut accepter de développer pour tous les navigateurs. De plus, Firefox et Internet Explorer n’ayant pas leur force et leur faiblesse au même endroit pour ce qui est des performances DOM, je serai bien à mal de dire qui a fait le bon choix sans faire des tests (attention toutefois, on parle de performance relative à une opération étalon pour chaque navigateur, même si la performance relative d’Internet Explorer par rapport à son étalon est meilleure, en valeur absolue Firefox reste plus rapide dans tous les cas ou presque).

Par contre il est clair que l’accès au DOM est lent, même en lecture sur de simples attributs. On peut en tirer une recommandation simple : mettez en cache les lectures d’attribut DOM, ne les répétez pas à chaque utilisation.

Jquery a d’ailleurs un Datastore pour éviter ça. Quand vous stockez des informations sur un élément, au lieu d’ajouter des attributs directement dans le DOM (avec toute la lenteur associée), on utilise le datastore. Conceptuellement c’est juste un attribut unique pour chaque élement DOM, et un dictionnaire qui associe ce que vous voulez stocker avec cet identifiant unique.

Créer ou modifier une structure DOM complexe

La seconde info vient de John Resig. Il nous rappelle la présence des objets DocumentFragment dans les navigateurs modernes (et même d’autres puisque Internet Explorer 6 supporte cette fonctionnalité). il s’agit d’un espace temporaire, hors du document, où on peut manipuler le DOM, créer des éléments, les supprimer, les déplacer.

John a fait quelques tests, et créer une structure DOM complexe dans un fragment pour la cloner ensuite dans le document réel est bien plus efficace que la créer directement dans le document. On a un gain de performance de 2 à 3. Bien entendu c’est valable si vous souhaitez créer toute une structure, pas un seul noeud.

Sean sullivan en parle aussi, avec des graphiques explicites.

Plus généralement,

• utiliser cloneNode est bien plus rapide que recréer à chaque fois des éléments.
• créer une structure dans un fragment ou au moins dans un élément détaché de la page jusqu’au dernier moment sera plus rapide que d’ajouter un à un des éléments dans un bloc déjà affichable
• utiliser innerHTML sera plus rapide que de créer une structure DOM si vous ne réutilisez pas cette structure ensuite (attention aux fuites de mémoire et aux événements)
• modifier des éléments invisibles (display:none par exemple) impactera moins les performance (pas de reflow)