cnumr / greenit-analysis Goto Github PK

View Code? Open in Web Editor NEW

147.0 147.0 32.0 1.21 MB

GreenIT-Analysis

License: GNU Affero General Public License v3.0

HTML 2.63% JavaScript 97.31% CSS 0.06%

greenit-analysis's People

Contributors

Stargazers

Watchers

greenit-analysis's Issues

Adaptation nouvelles versions des 115 bonnes pratiques : fusionner les régles minifier les css et minifier les js

Ajouter le HTML et le SVG

Titre : Minifier les fichiers CSS, JavaScript, HTML et SVG

Note A si tout est minifié
Note C sinon

Question sur measures.responsesSize

Bonjour,

J'essaye tant bien que mal de reproduire le calcul, de mon côté manuellement, et je crois comprendre que measures.responsesSize provient d'une addition des entry.response._transferSize puis au final measures.responsesSize est converti en Ko grâce à un Math.round(measures.responsesSize / 1000)

Ma question, c'est, est-ce qu'il n'y aurait pas une erreur, ou est-ce que je suis mal documenté/j'ai raté une ligne, mais selon moi, entry.response._transferSize est en bytes, alors que derrière, on considère cela comme étant en octet, ne devrait-on pas convertir _transferSize en octet avant de le convertir en Ko puis de l'afficher / l'utiliser pour calculer l'ecoindex ?

Note:
1 bit = 0,125 octet

Si ce que je dis est correcte, le correctif serait alors:
measures.responsesSize += entry.response._transferSize / 8;

La source de données utilisées pour le calcul de l'EcoIndex diffère entre Chrome et Firefox

On m'a remonté hier un problème d'implémentation critique :

Sur Chrome (et consorts), le calcul de l'EcoIndex porte sur les données transférées ;
Sur Firefox, le calcul de l'EcoIndex porte sur les données décodées.

Le score qui en découle d'un écosystème à un autre n'est donc pas comparable (ni même valide sur Firefox, puisque ce sont il me semble les données transférées, relatives au tiers 2, qui doivent être prises en compte).

Il est possible de récupérer à la fois les données transférées et décodées sur l'ensemble des navigateurs :

L'en-tête de réponse bodySize peut être utilisé pour Firefox ;
L'en-tête de réponse _transferSize peut être utilisé pour Chrome (et consorts). À noter que c'est Chrome qui ici ne respecte pas la spécification HttpArchive (HAR).

À voir si cela doit (peut) être corrigé avant la sortie d'une nouvelle version.
La documentation devrait sinon expliciter que Firefox ne devrait pas être utilisé à cause de cette implémentation.

"No cookie for static ressources" when cookies have a path

The extension wrongly complains about cookies for static resources when cookies has a path.
For example, this resource : https://example.com/build/runtime.2b530b.js
The cookies on this domain are defined with a path that does not match the resource: "PHP=xxx; path=/admin".

résultats des fois troublants

Bonjour Didier,
Merci beaucoup pour le développement de cette extension. Cela nous est très utile.
Sinon, on obtient des résultats que l'on ne comprend pas très bien.
L'écoIndex de la même page est meilleur avant nettoyage du cache qu'après nettoyage du cache.
Les copies d'écrans sont jointes

On ne comprend pas trop.
Est-ce que l'on a mal compris quelque chose? ou, est-ce que c'est un bug?
Très cordialement.
T Hirsch

Champ url vide dans l'export

Lors que je sauvegarde une analyse puis l'exporte est CSV, le champ 'url' est vide.

Doublon

La propriété est définie deux fois avec deux valeurs différentes.

https://github.com/didierfred/GreenIT-Analysis/blob/1518e9bf7494aee0b9d2b937bb7339dd5dce88c9/GreenPanel.html#L87

Sauvegarder les bonnes pratiques

Après une analyse, je peux sauvegarder son résultat. J'y retrouve la taille du DOM ou le Co2. Par contre, les informations sur les bonnes pratiques ne sont pas historisées.

Enregistrement impossible

Bonjour,
Impossible pour moi d'enregistrer une analyse. J'ai beau cliquer sur le bouton "sauver une analyse", rien ne se passe et rien n'apparait dans l'historique. :(
Une idée d'où vient le soucis?

Issue? Current implementation gives EcoIndex between -5 and 94 instead of 0 to 99

Hi,
I suspect there is an issue (or an inconsistency against the Ecoindex specification) in the current EcoIndex implementation located in the file ecoIndex.js.

As it is currently computed, EcoIndex value is between -5 and 94 rather than between 0 and 99 :

The smallest possible HTML page (<html></html> containing 3 DOM objects (page + empty header + empty body), generating 1 HTTP request and being 13-byte long) gets an EcoIndex equal to 94.00 (if rounded to 2 digits after the decimal point).
The theorically-worst HTML page (594,601 DOM objects; 3,920 HTTP requests; 223,213 kilobytes) gets a EcoIndex equal to -5.

Rachel Pellin's EcoIndex simulator (https://rachelwe.github.io/Simulateur-ecoindex/), which uses ecoIndex.js current implementation, helps highligting this behaviour:

the returned EcoIndex for a (theorical) HTML page with 0 DOM element, 0 HTTP request, 0-byte long gives an EcoIndex of 95 instead of 100.
the returned EcoIndex for the smallest HTML page described above if 94 instead of 99.
the returned EcoIndex for the worst-possible HTML page is -5 instead of 0.
if you compute the EcoIndex while using the worst value for one parameter and zero for the two others, the returned EcoIndex is lower than expected: for instance, the combination of 594,601 DOM objects, 0 HTTP requests and 0 kB gives an EcoIndex of 47.5 instead of the expected 50.

In my opinion, the issue lies in the calculateIndex function, which should return:
return ((i - 1) + (value - quantiles[i - 1]) / (quantiles[i] - quantiles[i - 1]));
and
return quantiles.length - 1;
instead of:
return (i + (value - quantiles[i - 1]) / (quantiles[i] - quantiles[i - 1]));
and
return quantiles.length;

If such a change were to be made, the grade computation would obviously have to be also altered, by adding 5 to every threshold:
case score >= 80: return 'A'; // instead of 75
case score >= 70: return 'B'; // instead of 65
...
case score >= 10: return 'F'; // instead of 5

Best Regards,
Olivier Descout

Calcul de l'eco index

Bonjour,

En regardant le code qui calcule l'eco index je trouve la formule suivante (code):

return 100 - 5 * (3*q_dom + 2*q_req + q_size)/6;

Or sur le site ecoindex , on trouve la suivante:

100 - (3q_dom + 2q_req + q_size)/6

Il y a-t-il une erreur quelque part?

Adaptation nouvelles versions des 115 bonnes pratiques: Ajouter des expires ou cache-control headers

Modifier les seuils :

S'il manque au moins 1 expires ou cache control , note C

Adaptation nouvelles versions des 115 bonnes pratiques : fusionner les régles externaliser les css et externaliser les js

Note A : si 0,1 ou 2 css / js inline
Note C sinon

License

Bonjour,

Une (grosse) partie du code d'analyse des bonnes pratiques semble avoir été copiée/collée depuis EcoMeter, et enfreint la license Affero GPL: aucune mention des auteurs / copyright, et changement de license en MPL.

Ne mettant plus d'énergie à maintenir EcoMeter, je soutiens cette initiative de reproduire ces analyses dans un plugin de navigateur, mais la license d'EcoMeter avait été soigneusement choisie et doit être respectée (d'autant plus par un membre de la communauté), même si je ne doute pas une seule seconde qu'il s'agisse de méconnaissance et/ou “manque d'attention”, et pas de malveillance.

/cc @Bornholm, @Cadoles, @atolcd, @lowki, @logomotion

Print CSS pas toujours pris en compte

Bonjour

La règle pour rechercher les print css est uniquement basée sur la recherche d'une balise link avec un attribut media=~print

Dans les language type React, buildé par du webpack, le bloc @media print est ressemblé dans le même fichié que les autres règles CSS, et n'a pas de balise link dédiée pour son import.

Le print css n'est donc pas pris en compte par cd plugin.

Tests unitaires

Compléter les tests unitaires, comparer avec EcoIndex et EcoMeter.

Adaptation nouvelles versions des 115 bonnes pratiques: Limiter le nombre de domaines

Modifier l'echelle :

Note de B si 4 domaines
Note de C si > 5

GES et Eau

Ajouter les champs GES et Eau, de façon similaire à ce qui a été fait sur l'extension EcoIndex.

Prise en compte des modules ECMAScript

Les modules ECMAScript ne semblent pas être pris en compte correctement et génèrent systématiquement des erreurs sur la partie Javascript dans le rapport.

[Chrome] Résultats différents selon paramétrages de l'onglet "Network"

Selon le paramétrage de l'onglet network dans Chrome (ici Brave browser), le score peut être différent et instable (se détériore).

En tant que développeur, j'ai tendance à utiliser les options suivantes:

Record network log
Preserve log

Utiliser ces options altére le score d'écoindex calculé par l'extension.

Cas standard

Url : https://mobilizon.org/fr/
Ecoindex : D
Network :
- Record network log : false
- Preserve Log : false

Score stable mais détérioré

Url : https://mobilizon.org/fr/
Ecoindex: E
Network :
- Record network log : true
- Preserve Log : false

Score détérioré et instable

Url : https://mobilizon.org/fr/
Ecoindex: D, E, F, G ...
Network :
- Record network log : true
- Preserve Log : true

"Page d’accueil" on mozilla addons still redirect to old repo

Adaptation nouvelles versions des 115 bonnes pratiques : Supprimer la bonne pratique sur les Etags

Readme

Ajouter un readme détaillant comment utiliser cette extension.

Adaptation nouvelles versions des 115 bonnes pratiques: Limiter le nombre de fichiers css

Modifier l'echelle :

Note de B si 8 css
Note de C si > 10

Bonnes pratiques

Ajouter du texte de commentaires sur les bonnes pratiques (par exemple à l’image de la rubrique « how to fix « du site ecometer)

[Comptage des inline styles] Images <svg>

Bonjour,

Lors de l'utilisation de l'extension, les balises styles contenues au sein des images SVG sont comptabilisées comme des feuilles de syle inline.

Exemple actuel :
https://lowtechlab.org/en , 3 feuilles de style inline sont détectées par le plugin mais elles font toutes les 3 parties d'une image SVG.

Je ne connais pas les normes de calcul pour les notes de l'écoindex mais je pense qu'on pourrait supposer que les balises <style> inclues dans les SVG ne sont pas des feuilles de style inline pour la page elle-même.

Code de reproduction (Compte 3 inline style) :

<html>
  <head>
    <title>This is the title of the webpage!</title>
  </head>
  <body>
  <svg viewBox="0 0 10 10" xmlns="http://www.w3.org/2000/svg">
  <style>
    circle {
      fill: gold;
      stroke: maroon;
      stroke-width: 2px;
    }
  </style>

  <circle cx="5" cy="5" r="4"></circle>
</svg>
<svg viewBox="0 0 10 10" xmlns="http://www.w3.org/2000/svg">
  <style>
    circle {
      fill: gold;
      stroke: maroon;
      stroke-width: 2px;
    }
  </style>

  <circle cx="5" cy="5" r="4"></circle>
</svg>
<svg viewBox="0 0 10 10" xmlns="http://www.w3.org/2000/svg">
  <style>
    circle {
      fill: gold;
      stroke: maroon;
      stroke-width: 2px;
    }
  </style>

  <circle cx="5" cy="5" r="4"></circle>
</svg>
  </body>
</html>

Cordialement,

Onglet GreenIT Analysis disparaît après la dernière mise à jour de Edge

Sur Edge, depuis la dernière mise à jour, après avoir appuyé sur F12 l'onglet GreenIT Analysis n'apparaît plus.
J'ai essayé de désinstaller et réinstaller le plugin mais le problème persiste.

Résultats différents

Bonjour,
En testant le même site nous avons des résultats qui diffèrent d'un navigateur à l'autre, ou d'un ordinateur à l'autre. Nous n'arrivons pas à comprendre ce qui peut poser problème.

Ordi 1 - Chrome

Ordi 1 - FireFox

Ordi 2 - Chrome

Une idée ?
Merci !!

[Bug]: Incohérences dans le comportement de l'extension de projet sur différents navigateurs

Lors de l'utilisation de l'extension du projet sur différents navigateurs, j'ai remarqué des incohérences dans son comportement. En particulier, j'ai constaté qu'elle fonctionne différemment d'un navigateur à un autre.

J'ai récemment installé l'extension du projet pour calculer l'impact environnemental des sites web que j'ai créés ( #238 ). Toutefois, je me suis rendu compte que le calcul du nombre de DOM (éléments de la page) ne fonctionne pas correctement sur Chrome et Edge.

En effet, lorsque j'utilise l'extension sur ces navigateurs, le nombre de DOM visités semble toujours être inférieur au nombre attendu. En outre, elle ne prend pas en compte le contenu des iframes dans le calcul de l'écoindex d'une page. Le nombre de nœuds DOM détectés est de 6, ce qui correspond au contenu du fichier html principal, mais cela n'inclut pas le contenu du html à l'intérieur de l'iframe (J'utilise les fichiers suivants comme testcase.zip servi localement sur le port 8080).

En revanche, lorsque j'utilise l'extension sur Firefox, le calcul du nombre de DOM visités semble fonctionner correctement et le nombre affiché correspond à mes attentes (18).

Ce problème de calcul sur Chrome et Edge rend l'utilisation de l'extension du projet moins fiable sur ces navigateurs. J'aimerais donc savoir s'il existe une solution pour résoudre ce problème.

Prise en compte mix énergétique ?

Hello,

Je suis en train de faire quelques tests sur des sites avec une réflexion sur la localisation du datacenter, j'avais une question concernant les mix énergétiques : est ce qu'il serait possible dans une prochaine version de les paramétrer (Datacenter, Réseau, Terminal) ?

Merci d'avance !

Bouton d'analyse inactif après un premier test

Bonjour,
Nous rencontrons un bug avec GreenIT analysis : le bouton d'analyse n'est plus actif après un premier test et il faut quitter les outils de développement et réafficher pour débloquer. Ce problème n'était pas présent il y a quelques semaines.
Cela rend l'analyse d'un parcours complet assez pénible.
Constaté par moi même et plusieurs autres personne cmme @EmmanuelDemey , @margaux-e , @aureliebaton

Adaptation nouvelles versions des 115 bonnes pratiques: Ajouter la régle "Privilégier HTTP/2 à HTTP/1"

Nombre d'éléments du DOM très importants

Bonjour,

Je pense qu'il y a un bug dans la dernière version de l'extension.
Config : W10, FF 106.03

Lors de l'enregistrement d'un parcours utilisateurs classique, tout se passe bien (nombre d'éléments du DOM cohérent). Mais arrivé sur un formulaire, l'extension GIT-Analysis me remonte 26501 éléments du DOM alors qu'on a entre 500 et 800 sur les autres pages.

Des stagiaires en formation ont également eu cette situation sur d'autres sites à partir d'autres configurations (autres OS et navigateur).

Cf. par exemple ce dump avec la valeur 26501 dans la deuxième ligne :
Date;Url;Nombre requêtes;Taille(kb);Taille du dom;GES;Eau;ecoIndex;Note
05/11/2022 10:52:17;"https://www.techchallenger.fr/inscription/";187;8824;26501;2.85;4.28;7.42;G
05/11/2022 10:51:36;"https://www.techchallenger.fr/reglement-du-concours/";85;2965;750;2.21;3.32;39.32;E
05/11/2022 10:51:26;"https://www.techchallenger.fr/conferences/";86;3016;585;2.11;3.16;44.62;D
05/11/2022 10:51:14;"https://www.techchallenger.fr/";91;3316;740;2.24;3.36;37.95;E

Adaptation nouvelles versions des 115 bonnes pratiques : Utiliser des polices de caractères standards

Ne plus donner une note sur la base de la taille mais sur le nombre de polices téléchargées :

Note A si 1 max
Note B si 2
Note C sinon

Historique

Ajout d’une fonction d’historique à l’image d’ecoindex (ajout d’un bouton « add to history ») avec fonction d’export

Impossible d'exécuter le plug in avec la touche F12

Bonjour, je travaille sur un PC windows et je n'arrive pas à exécuter le plug in lorsque j'appuie sur la touche F12. Est ce que quelqu'un d'autre a rencontré le problème ? Auriez-vous une solution pour contourner ce problème ? Merci

Comment calculer l'ecoindex sur un parcours utilisateur ?

Bonjour,

Cette issue fait suite à cnumr/GreenIT-Analysis-cli#40.
Je cherche à calculer l'écoindex des pages traversées dans un scénario utilisateur, que je définis ainsi : c'est un parcours, généralement à partir de la page d'accueil, où l'on passe d'une page à l'autre via des actions effectuées au travers du navigateur (click, remplissage de formulaire, etc.).

Au delà de l'outil lui même (qu'il faudrait éventuellement faire évoluer), que pensez-vous de cette approche. Je vois deux façon de procéder :

Dérouler l'ensemble du scénario en cumulant le nombre de requêtes et la quantité de données transmises et calculer l'écoindex global du parcours. Je suis suis pas convaincu par cette approche, je pense que la définition de l'écoindex ne le permet pas réellement :
- elle utilise la complexité du DOM, qui n'a de sens que pour une page unique, à moins éventuellement de cumuler les tailles de dom tout au long du parcours
- la calibration de l'écoindex a été faire sur des pages, et n'est donc pas utilisable : il faudrait n'utiliser que la note sur 100 et pas sa traduction sous forme de lettres
- elle ne permet pas d'identifier les pages du parcours qui ont le plus besoin d'être revues / optimisées
Calculer un score écoindex page par page, à chaque changement de page ou éventuellement changement majeur dans l'écran sans changement d'url, dans le cas d'une SPA.

Idéalement, je pense qu'il faudrait obtenir un score par page, et un score global pour le scénario. Ce score global pourrait être calculé soit en faisant une simple moyenne (bof), soit en trouvant une méthode un peu plus intelligente qui pénaliserait les parcours trop longs et trop lourds (pour favoriser un parcours avec moins de requêtes et moins de données échangées).

Adaptation nouvelles versions des 115 bonnes pratiques : Supprimer la bonne pratique sur les tags src vides

Adaptation nouvelles versions des 115 bonnes pratiques: Eviter les redirections

Modifier le seuil

0 ou 1 : note A

1 : note C

cnumr / greenit-analysis Goto Github PK

greenit-analysis's People

Contributors

Stargazers

Watchers

Forkers

greenit-analysis's Issues

Cas standard

Score stable mais détérioré

Score détérioré et instable

Recommend Projects

Recommend Topics

Recommend Org

Jobs