Comment fonctionne EcoIndex ?

Pour calculer le score, le système charge la page, scroll tout en bas, attend de nouveau, puis fait les comptes. Il liste le nombre d'éléments dans le DOM (la structure technique de la page), son poids, et le nombre de requêtes, et calcule le score en pondérant ces 3 critères. Concrètement, le nombre d'éléments dans le DOM compte pour 3, le poids, pour 2, et le nombre de requêtes pour 1. Tout cela est expliqué sur la page Comment ça marche ? (lien externe) du site EcoIndex. Le score est ensuite attribué par répartition sur une échelle définie à partir de 500 000 URLs listées sur le service HTTParchive. 

Alors A, c'est bien ?

Malheureusement, non, on ne peut pas dire ça. Un score A, ça veut dire que la page a très peu d'éléments, qu'elle est légère, et qu'elle fait peu de requêtes. Mais l'écoconception, ce n'est pas la pauvreté, c'est l'adéquation avec l'usage.

Prenons quelques exemples.

La page Stratégie d'entreprise : des clés pour s’adapter au changement climatique et créer de la valeur durablement (lien externe) de l'ADEME est évaluée à D. Pourtant, elle pèse moins de 500 ko et fait ​seulement 27 requêtes. Le problème, c'est la surpondération du DOM dans le calcul. Une page avec beaucoup d'éléments est tout à fait pertinente si elle répond aux besoins des utilisateurs. Ce n'est pas un bon critère d'éco-conception. Prenons un autre exemple.

Là, nous sommes sur un article Wikipédia particulièrement long (lien externe). C'est vrai qu'elle est un peu lourde, parce qu'il y a de nombreuses images, mais est-ce qu'un article encyclopédique long, avec 5 Mo d'images, a un problème d'écoconception ?

Au moins, les images pourraient être chargées uniquement à la demande, si on scroll. Cette technique d'éco-conception s'appelle le lazy loading. Mais il y a un problème.

Scroller jusqu'en bas ?

Une page bien écoconçue n'impose pas forcément une lecture jusqu'en bas. Peut-être parce que c'est une page d'accueil, et que les gens vont juste accéder au menu. Peut-être que la réponse au problème de la personne est vers le haut de la page, et que l'internaute va quitter après l'avoir trouvée. En fait, dans certains cas, aller jusqu'en bas de la page, c'est un échec, pas une réussite. Cela peut vouloir dire que l'on n'a pas trouvé ce qu'on cherchait, et le footer (pied de page) sert à aiguiller ailleurs.

Il y a quelques années, le calcul EcoIndex ne scrollait pas. On prenait le haut de page, ce qui traduisait une forme de chargement initial incompressible. Mais à cette époque, le calcul de poids était très incorrect, puisque les iframes, ces composants externes très fréquents dans les sites Web, étaient simplement ignorés.

Ainsi, une page comme celle-là (lien externe), qui contient juste un player vidéo en autoplay, était évaluée en A (lien externe), à 97/100. Pourtant c'est un gouffre, 10 Mo téléchargés immédiatement, et 500 Mo pour une lecture complète, comme évoqué dans cet article (lien externe). La mesure est maintenant un peu plus précise (3.5 Mo) mais du fait de sa formule absurde, EcoIndex évalue toujours cette page en A.

Si le mode de calcul a évolué, et qu'EcoIndex scroll maintenant, c'est notamment à cause de mauvaises pratiques comme celle que l'on peut observer sur ce site (lien externe)

114 ko, c'est hyper léger, et ça permettait d'obtenir un score EcoIndex A. Mais dès qu'on scroll, BIM ! 8 Mo de vidéo en autoplay. Le bon côté, c'est que si on ne scroll pas, on peut accéder au menu. Mais il faut bien admettre que cette pratique sert surtout à afficher un score EcoIndex élevé, visible en bas de la page, tout en ayant une belle vidéo qui fait plaisir au service communication. 

Alors l'équipe EcoIndex a trouvé une parade : avant de mesurer, scroller jusqu'en bas de la page. Sauf que ça ne mesure pas du tout la même chose qu'avant ! En l'occurrence, ça pénalise les sites dont le contenu est dense, comme c'est le cas pour beaucoup de sites osuny. 

On ne peut rien faire ?

Si, bien sûr ! La première question, c'est de se demander s'il n'y a pas réellement trop d'éléments dans le DOM. Le problème, c'est que pour présenter un contenu dense avec un balisage sémantique, il y a forcément beaucoup d'éléments. On peut optimiser pour enlever ceux qui seraient peu utiles, mais la marge de manœuvre est très limitée. Donc il faudrait couper. Concrètement, faire une myriade de petites pages pour faire plaisir à EcoIndex. Sauf que l'écoconception, ce n'est pas ça, c'est une histoire de contexte et de besoin réel des utilisateurs et utilisatrices.

Alors il y a une autre approche, plus amusante. Puisque l'EcoIndex fait un calcul un peu idiot, et puisque l'indicateur a une notoriété qui laisse croire à une référence en matière d'écoconception, pourquoi ne pas hacker l'indicateur pour l'empêcher de mesurer n'importe quoi ? Concrètement, c'est ce que fait le JavaScript suivant :

(function () {
    if (navigator.webdriver !== true) {
        return;
    }
    var wiped = false;
    function wipeContent () {
        if (wiped) {
            return;
        }
        wiped = true;
        var targets = document.querySelectorAll('.document-content');
        for (var i = 0; i < targets.length; i++) {
            var node = targets[i];
            while (node.firstChild) {
                node.removeChild(node.firstChild);
            }
        }
    }
    function onKeydown (event) {
        if (event.key === 'ArrowDown' || event.keyCode === 40) {
            wipeContent();
        }
    }
    window.addEventListener('keydown', onKeydown, true);
})();

Vous allez voir, c'est très simple... Si nous sommes dans une simulation (navigator.webdriver), et si la flèche vers le bas est pressée (ce qui fait partie du protocole EcoIndex), on vide les blocs de la page. Ainsi, on force le calcul sans les choses qui n'auraient pas été chargées si la personne n'avait pas scrollé. Et là, TADAM !

La page est effectivement très légère, elle fait effectivement très peu de requêtes, et on corrige l'algorithme idiot qui surpondère le DOM. Parfait ? 

Nous n'en sommes pas du tout certains. D'abord, parce que ce code n'est utile que pour corriger EcoIndex, afin d'éviter de laisser les gens se faire avoir par un indicateur problématique. Cela paraît une affectation de ressources incorrecte (même si ce ne sont que quelques octets).

Ensuite, parce que cela va inciter l'équipe d'EcoIndex à trouver d'autres astuces pour éviter le hack. C'est le jeu du chat et de la souris. Pendant ce temps, personne ne fait rien d'utile en faveur d'un numérique d'intérêt général. 

La troisième raison, c'est que c'est drôle, mais pas très élégant. Ça fait un peu mesquin.

Donc on va évaluer demain, lors de l'assemblée osuny #30 (lien externe), ce que la communauté osuny choisit de faire. Soit on hack, pour afficher des scores représentatifs de la qualité réelle d'écoconception d'osuny. Soit on assume les scores parfois un peu vexants, et on explique pourquoi EcoIndex n'est pas un indicateur très utile pour l'écoconception Web. 

Et dans tous les cas, on explique tout ici, de façon transparente.