Le DOM comme métrique de suivi de sobriété du web ?

Posted on by Olivier PHILIPPOT
Reading Time: 3 minutes

Nous avons validé l’usage de l’énergie dans nos outils (se référer à notre article sur la mesure de la consommation énergétique et notre article sur le calcul d’impacts). Nous utilisons et mesurons cependant d’autres métriques comme entre autres le CPU. Cette métrique peut être complexe à mesurer et certains outils ou équipements utilisent d’autres éléments plus accessibles techniquement. Le CPU est utilisé pour mesurer l’empreinte des ressources côté terminal. En effet, nous avons réalisé des mesures sur plusieurs centaines de sites et il apparait clairement que le CPU est la métrique prépondérante si l’on veut analyser l’impact d’un logiciel. C’est pour cela que tous les modèles qui utilisent les données échangées pour calculer l’impact du terminal ne sont pas cohérents. On privilégiera des modèles basés sur le CPU comme par exemple Power API.

Il faut cependant être rigoureux dans l’analyse de cette métrique car il peut y avoir des biais d’interprétation (Nous en avons parlé dans un article précédent : critique sur le CPU). La critique doit être encore plus importante sur la façon d’obtenir cette métrique, et plus particulièrement dans le cas de modélisation du CPU. C’est le cas par exemple des méthodes de projection du CPU dans le web à partir des éléments du DOM. 

Cela part de l’hypothèse que la structure du DOM impacte la consommation des ressources sur le terminal. Plus le DOM est complexe, plus il est nécessaire de le traiter par le navigateur et plus cela utilise de ressources (CPU et RAM). En fonction de cette complexité l’impact environnemental sera plus ou moins élevé.

En supposant qu’on valide l’hypothèse de la corrélation entre complexité du DOM et impact environnemental, la métrique souvent utilisée est le nombre d’éléments. Un DOM avec beaucoup d’éléments sera peut-être complexe mais pas systématiquement. Pour prendre en compte la complexité du DOM, il faudrait prendre en compte l’architecture du DOM, en particulier la profondeur, le type de nœud (tous les nœuds n’ayant pas le même impact pour le browser…). Le choix du nombre d’éléments du DOM est donc discutable.

Mais est-ce que le choix de la complexité du DOM est une hypothèse viable ? On peut avoir plusieurs critiques sur cela. 

Le DOM est une structure brute qui n’est pas suffisante au navigateur pour afficher la page. Le style est utilisé avec le DOM pour créer le CSSOM, une complexité du style peut donc impacter grandement le CSSOM, même avec un DOM simple. Ensuite le layout tree est une structure qui va permettre de gérer l’affichage (Les typos, les tailles…), cette gestion est beaucoup plus complexe à traiter pour les navigateurs. 

Un DOM peut être modifié après sa création. On va parler de reflow et repaint. Le navigateur va recalculer le layout et différentes choses. Ceci peut arriver plusieurs fois lors du chargement et après ce dernier. La profondeur du DOM (et pas le nombre d’éléments) peut influencer la consommation de ressources mais pas uniquement; le chargement et l’exécution de code JS sont également à prendre en compte.

Indépendamment du DOM, la consommation de ressources peut être impactée par différents traitements sur le terminal. En particulier, tous les traitements JS qui vont s’exécuter au chargement de la page. Dans le web, le principal coût est actuellement sur le CPU. On peut avoir un DOM avec 100 éléments (c’est à dire peu) et une usine à gaz JS.

Les animations graphiques vont augmenter la consommation de ressources sans forcément impacter le DOM. Même si la plupart de ces traitements sont pris en charge par les GPU, l’impact sur les ressources existe et n’est pas négligeable. On peut aussi mettre dans cette catégorie le lancement de vidéos, de podcasts (et plus généralement les fichiers médias) et de publicités.

Il existe aussi bien d’autres sources de consommation de ressources : Requêtes réseau non regroupées, fuite mémoire. 

L’usage du DOM doit donc être utilisé avec beaucoup de précaution. Il est plutôt utilisable comme une métrique de qualité logicielle qui indique la “propreté du HTML”. Réduire le nombre d’éléments DOM et simplifier la structure du DOM pourra être une bonne pratique de sobriété mais pas un KPI de réduction de la sobriété ou de calcul du CO2.

Je contacte l’équipe Greenspector