Problème de l'incohérence des données entre nos différents outils

[DocRoms]

Le sujet du bug d'EcoIndex à été traité, je laisse cette conversation ouverte pour que l'on puisse discuter de la cohérence de nos données, et de nos méthodes de calcul au sein du collectif. Nous ne devrions pas avoir de recommandations différentes sur EcoIndex, dans les bonnes pratiques, et dans nos autres projets.

Citation de @aureliebaton avec les membres de l'organisation :

Nous avons également une question concernant les valeurs “cibles” indiquées dans les détails des résultats. En effet, nous avons du mal à trouver quelles sont les valeurs “cibles” à indiquer pour les requêtes, le DOM et le poids. Pour l’instant nous avons :

• Nb de requêtes < 27
• Nb d’éléments du DOM < 500
• Poids de la page < 0,9 Mo
  Mais nous ne trouvons pas ces mêmes valeurs partout. Par exemple, GreenIT Analysis indique un nombre maximum “cible” de 27 pour les requêtes alors que la V4 des 115 BP indique 40 requêtes.

❓ Quelles sont les valeurs que nous devons prendre en compte ?

Lorsque l'on analyse une page, et qu'elle pèse quasiment 3mo. Le tag qui apparait est si légère.
Je trouve que ça n'est pas forcément cohérent.

Si on regarde le dernier rapport HTTPArchive, le poids médian d'une page en Aout 2022 est de 2262.0 KB sur Desktop et de 2007.3 KB sur mobile.

Je penses (raisonnement personnel) qu'il n'est pas cohérent d'afficher qu'une page plus lourde que la médiane mondiale soit qualifiée de légère. Il faut que l'on revois cet affichage pour ne pas faire croire qu'un site avec un poids énorme soit "léger".

De plus, on constate que sur l'affichage du résultat, le site à un poids supérieur à la médiane que l'on à défini ;)

J'ouvre une discussion pour :
➡️ Savoir ce que vous penser.
➡️ Connaitre la méthode d'affichage de ces tags.
➡️ Trouver une taille idéale pour l'affichage d'une page si légère qui ne soit pas supérieure à 2Mo ^^
➡️ Trouver quelle source prendre pour définir ce qu'est une page légère, moyenne, lourde. ( HttpArchive ?)

[vvatelot]

@DocRoms je pense qu'il y a un vrai sujet de cohérence global des données pour le calcul écoindex. C'est ce que je remonte depuis quelques temps. Les sources actuelles datent de 2014. Ça date. Selon moi il faudrait avoir 1 source de données unique, à jour et partagée par tous les projets du collectif...

[aureliebaton]

Les tags sont maintenant bien affichés par rapport à la cible et non par rapport à la médiane (merci @Bastou ).

Reste le problème de cohérence globale des données à traiter avec le reste du collectif.

[bordage]

Bonjour tout le monde,

L'échelle EcoIndex est figée dans le temps de 0 à 100 et de à G avec une répartition par la méthode des quantiles.

La traduction du score Ecoindex en impacts environnementaux dépend uniquement de :
a. la valeur des facteurs d'impacts ;
b. La méthode pour sur-sous pondérer ces impacts.

Le min et max des 3 paramètres (DOM, Ko transférés, nb req. HTTP) est stable dans le temps (ce sont des extrêmes statistiques). La médiane évolue :

• vite sur un échantillon restreint (quelque milliers ou dizaines de milliers d'URLs) ;
• lentement / pas sur un gros échantillon (centaines de milliers d'URLs).

L'EcoIndex est surtout intéressant pour se comparer :

• à soit-même dans le temps ;
• et / ou à un échantillon spécifique.

Pour apporter de la stabilité dans le temps, la médiane des 3 paramètres (DOM, etc.) devrait être fixée en fonction des médianes HTTParchive de 2022. On peut se doter d'une règle telle que : si la médiane varie de xx% alors on met à jour les médianes EcoIndex (ce qui revient à déplacer le barycentre de la courbe de Gauss).

Concernant les valeurs cibles, nous avions initialement un système de calcul simpliste du genre xx % en moins de la valeur constatée (DOM, etc.). Il serait plus judicieux de fixer des seuils statiques tels que 30 req HTTP, 800 él. DOM, et 1 000 Ko.

Voilà pour mes suggestions et pour faire avancer la prise de décision.

[Amael-PE]

Hello All,
Chez Resilio, nous avons le même "problème", et l'avons résolu différemment (pour ranquer des SI).

De A à E ou de 1 à 100, nous ne trions pas entre min et max (qui sont trop sensibles) et avec méthode des quantiles, mais en fonction des écarts types. Nous sommes donc plus sévères : A veut dire "exceptionnellement bon", pas simplement "très bon", G "Exceptionnelement mauvais", pas juste "mauvais".
Le premier à l'avantage de Benchmarker, Le deuxième d'évaluer/trier. Si l'échelle a été fixée pour A à G, gardez la (et gardez en tête que ça marche moins bien pour le benchmarking).

Pour le reste, je n'ai pas une grande connaissance de l'algo d'EcoIndex, mais coté stats, voici mon avis :

• Des reco techniques différentes d'un outils à l'autre, c'est une mauvaise chose.
• Utiliser des min ou max, c'est aussi une mauvaise chose comme bornes... Des quantiles 2,5/5% et 95/97,5% seront beaucoup mieux, ou des moyenne +/- 3 sigmas sur une grand échantillon
• La politique de mise à jour de EcoIndex doit être claire : tous les ans par exemple, ou tous les x mois.
• Je ne l'ai pas vu mais je trouverai très interessant d'avoir les stats sur lesquelles se basent les analyses : # de pages scrawlées, min, max, quntiles, moyenne/mediane, etc. A la fois en termes de score (histogramme des notes) et en termes techniques (histogrammes des # requetes, poids, éléments DOM, etc)

[DocRoms]

Okay. Merci pour ces échanges !
On peut donc définir que nous partons sur les valeurs cibles suivantes :

• <= 40 requêtes HTTP (ce qui est égale au principe de validation du référentiel des bonnes pratiques)
• < 600 éléments de DOM (nouvelle valeur cible d'après les médianes ecoIndex, à ajouter dans la v4 du référentiel)
• < 1024 Ko transférés (nouvelle valeur cible d'après les médianes ecoIndex, à ajouter dans la v4 du référentiel)

Il faudra aussi mettre à jour nos autre projets par rapport à ces valeurs cibles. @didierfred C'est déjà le cas sur GreenItAnalysis ?

C'est bon pour tout le monde ? Que l'on parte dessus, que je puisse clore la discussion et créer des issues :)

[vvatelot]

Ok pour moi, je répercute sur ecoindex_cli

[JulienWilhelm]

Dans le cadre d'EcoIndex, et vis à vis de ce qui se fait effectivement en construction de page, ces nouvelles valeurs médianes me semblent assez cohérentes à moi aussi. Elles ne préjugent pas de la qualité de l'écoconception du service (ce n'est pas le propre de l'outil, de toute manière), mais sont à la fois assez strictes et permissives pour challenger des efforts de conception sans permettre tout et n'importe quoi.

[didierfred]

En ce qui concerne GreenIt-analysis :

• Pour le nombre de requete cible on est bien à 40 cependant il y a un état intermédiaire qui est en orange quand on est >= 27 ( Vert < 27 , Orange < 40 , rouge sinon) . Je peux supprimer ce status intermédiaire si besoin pour plus de cohérence et de simplicité . A noter qu'il est utilisé pour d'autres bonnes pratiques .

• Pour la taille du DOM et le volume téléchargé , ce n'est pas traduit en bonnes pratiques avec une cible à atteindre . Cela peut cependant facilement s'ajouter

[vvatelot]

Au fait @Amael-PE si ça vous intéresse: https://dataviz.ecoindex.fr/public/dashboard/6e744456-410c-4010-b603-3361a3b50580

Et quand vous voulez pour échanger sur les outils python... 🙂

[vvatelot]

@bordage conernant ta question:

Je ne sais pas ce que sont les "valeurs de base".

Je parle de ces valeurs: https://github.com/cnumr/ecoindex_python/blob/main/ecoindex/quantiles.py qui sont les quantiles qui servent au calcul de l'ecoindex. Peut être est ce plus clair ? 😃

[aureliebaton]

Bonjour, Je rattrape la discussion. Je suis d'avis de garder la cible à *30 requêtes *plutôt que 40, même si 40 peut correspondre à un intermédiaire orange comme Fred Didier l'indique. L'objectif de la cible étant de donner une idée de ce vers quoi on *"devrait tendre". * Désolée de relancer la discussion ;) Si tout le monde s'aligne sur 40 je me rangerai à la majorité, mais 30 requêtes me semble atteignable et je trouverais ça dommage de mettre la cible trop "haute". Aurélie

…

On Mon, Sep 19, 2022 at 8:11 AM DidierFred ***@***.***> wrote: En ce qui concerne GreenIt-analysis : - Pour le nombre de requete cible on est bien à 40 cependant il y a un état intermédiaire qui est en orange quand on est > 27 ( Vert < 27 , Orange < 40 , rouge sinon) . Je peux supprimer ce status intermédiaire si besoin pour plus de cohérence et de simplicité . A noter qu'il est utilisé pour d'autres bonnes pratiques . - Pour la taille du DOM et le volume téléchargé , ce n'est pas traduit en bonnes pratiques avec une cible à atteindre . Cela peut cependant facilement s'ajouter — Reply to this email directly, view it on GitHub <#109 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AULFCC7RHOR76KC3FDKJIH3V6772JANCNFSM6AAAAAAQI7NUKU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- *Aurélie Baton* Eco By Design UX Designer / Numérique Responsable / Sustainable Design +33 (0)6 84 83 49 18 www.linkedin.com/in/aureliebaton

[Christophe-Cl]

J'arrive après et prends lecture de ces passionnants échanges.
Je valide la proposition de Romuald :
< 40 requêtes HTTP
< 600 éléments de DOM
< 1024 Ko transférés
D'expérience, avoir ces indicateurs à atteindre est un bon objectif ; lorsque la majorité des services y parviendront ce sera déjà "une première marche de rêve franchie"

[DocRoms]

Hello 👋 .
Je reviens sur ce fil de discussion pour clarifier ce que nous allons faire. La remarque d'@aureliebaton étant plus que pertinente :

1️⃣ Dans un premier temps, nous allons garder ce que nous avons spécifié dans la conversation , c'est à dire, les valeurs suivantes :

• <= 40 requêtes HTTP (ce qui est égal au principe de validation du référentiel des bonnes pratiques)
• < 600 éléments de DOM (nouvelle valeur cible d'après les médianes d'écoIndex, que l'on ajoutera dans la v4 du référentiel)
• < 1024 Ko transférés (nouvelle valeur cible d'après les médianes d'écoIndex, que l'on ajoutera dans la v4 du référentiel)

Cela nous permettra de garder une cohérence entre les outils que nous avons et le référentiel des bonnes pratiques d'écoconception.
@vvatelot a créé une PR pour modifier cela sur la v2 d'écoIndex.

Pour GreenIt-analysis, je rebondis sur ce que tu as suggéré @didierfred :

En ce qui concerne GreenIt-analysis :

• Pour le nombre de requêtes cible on est bien à 40 cependant il y a un état intermédiaire qui est en orange quand on est >= 27 ( Vert < 27 , Orange < 40 , rouge sinon) . Je peux supprimer ce statut intermédiaire si besoin pour plus de cohérence et de simplicité . A noter qu'il est utilisé pour d'autres bonnes pratiques .
• Pour la taille du DOM et le volume téléchargé , ce n'est pas traduit en bonnes pratiques avec une cible à atteindre . Cela peut cependant facilement s'ajouter.

Si, actuellement, nous avons la possibilité de supprimer le statut, et d'ajouter les cibles que l'on a spécifiées pour le nombre d'éléments du DOM et le volume téléchargé, ça serait par-fait. On serait cohérent sur tous nos projets pour la sortie de la v2 🎉 .

Il faudrait peut-être également voir les autres projets, et communiquer les valeurs cibles. (@jules-delecour-dav il y a des règles EcoCode là-dessus ? )

Et voir avec rachelwe (Rachel Pellin) pour qu'elle mette à jour https://rachelwe.github.io/Simulateur-ecoindex/ 😅 (projet dont j'ignorais l'existence : on peut peut-être lui demander de l'intégrer sur le dépôt du cNumR ? 🤔 )

2️⃣ En parallèle, nous allons ouvrir une discussion sur le dépôt du référentiel des bonnes pratiques pour que l'on débatte des valeurs cibles à prendre en compte. Peut-être que l'on peut passer le nombre de requêtes à 20, ou à 15 ? Mais techniquement, ça dépend aussi du protocole utilisé. Les requêtes du protocole "HTTP/2" profitent du multiplexage: réduire le nombre de requêtes peut avoir moins d'intérêt qu'en HTTP/1. On peut aussi mieux profiter du cache avec plusieurs petits fichiers ayant un cache long qu'avec peu de gros fichiers souvent réactualisés ! On pourrait aussi spécifier les valeurs des règles que l'on doit ajouter (pour la v5 🤔) avec le nombre d'éléments de page, et le poids de page.

Bref, il y a des choses à dire et à spécifier. Ça peut être intéressant d'avoir une base commune de valeur cible qui peut être intégrée au référentiel : le projet qui est une de nos références à toutes et à tous. (on se base tous dessus pour nos différents projets)

---

Est-ce que tout le monde est en accord avec ça ? ( un 👍 suffit, sinon une petite argumentation permettra de nous orienter au mieux vers une solution idéale).

[bordage]

Très bonne idée de créer un espace d'échange pour prendre le temps de mettre à jour ces seuils en toute transparence. Lorsqu'il sera prêt je ré-expliquerai brièvement comment et pourquoi j'ai choisi ces 3 indicateurs techniques pour construire l'EcoIndex. On peut aussi caler un échange en visio si plus efficace (il me reste quelques dispos à partir de mi-octobre à des heures acceptables).

[aureliebaton]

Oui bonne idée @DocRoms !

@bordage ce serait effectivement super d'échanger de vive voix sur ces questions et aussi sur la vision plus long terme des outils du collectif. Pourrais-tu nous envoyer tes dispos à Romuald et moi par mail et on s'organisera pour voir avec les autres le créneau qui peut fonctionner ?

[DocRoms]

Je bloque la discussion actuelle, Une discussion à été créé sur le dépôt des bonnes pratiques ici => cnumr/best-practices#412