Spécification des valeurs cibles de nos BP concernant les indicateurs d'ÉcoIndex

[DocRoms]

Suite à la discussion ouverte sur le dépôt d'EcoIndex nous voulons spécifier et discuter des valeurs cibles de nos BP prises en compte par ÉcoIndex.

Nous avons déjà spécifié celles-ci, qui sont les valeurs "officielles" prises en compte par tous nos projets (des issues existent et doivent être créées pour des mises à jour):

• <= 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)

Comme ça, nous sommes cohérents sur tous nos projets, y compris avec les bonnes pratiques du référentiel (ici) qui possède la bonne pratique Limiter le nombre de requêtes HTTP qui stipule le principe de validation suivant :

• Nombre de requête HTTP : <= 40 requêtes .

Nous allons surement créer deux règles supplémentaires dans la prochaine version des bonnes pratiques pour parler des deux autres indicateurs :

• Le poids de page.
• Le nombre d'élément du DOM.

Le but de cette discussion est de spécifier et de débattre sur le sujet de la mise à jour de ces valeurs cibles :

• D'où proviennent ces valeurs ? ❓ (cc @bordage )
• Doit-on les faire évoluer ? ❓
• Ne sont-elles pas devenues obsolète avec l'avènement du HTTP/2 et du multiplexage ? ❓
• Doit-on avoir plusieurs seuils par type de protocole ? HTTP/1 avec les valeurs actuelles , HTTP/2+ avec d'autres valeurs ? ❓
• Doit-on récupérer des valeurs d'autres organisme ayant plus de données que nous ? ❓ (cf les données HTTPArchive , CRUX/BigQUery est-ce que c'est possible ?...)

Avant notre spécification, le plugin GreenIt Analysis agissait de la sorte : (comme expliqué par @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 .

• Doit-on avoir un seuil inférieur à 40 requêtes ? et redéfinir la valeur cible à 27 requêtes ? ❓ (d'où vient le 27 d'ailleurs ?)

@aureliebaton a également réagit à ce sujet dans la conversation en expliquant

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

• Doit-on prendre une cible inférieure à 40 requête et partir sur 30 ? ❓ (et d'où provient le 30).

---

ℹ️ Je mettrais à jour ce premier post avec les informations de la discussion régulièrement.
❓ : Point à spécifier.
Quand c'est barré : c'est qu'on a déjà vu ça dans la conversation ci-dessous !

[vvatelot]

Pour info, sur httpArchive, on peut récupérer facilement plusieurs données:

• L'évolution du nombre de requêtes totales
• L'évolution des données totales téléchargées

Attention, il s'agit ici d'une répartition au percentile, et on n'a pas les infos concernant le nombres d'éléments constituant une page.

Httparchive met son dataset à dispo sur Google Bigquery. Mais il est énorme et la moindre reque coûte un bras. Donc, très attention !

Je rejoins @DocRoms concernant le nombre de requêtes VS HTTP2. Peut être faut il corréler le nombre d'éléments téléchargés avec le nombre de connexions TCP ouvertes par la page ?.

Une autre évolution permet également d'optimiser le téléchargement de ressources au chargement de la page: Le prefetch. Or, le nombre d'éléments téléchargés ne tient pas compte non plus du prefetch...

[bordage]

Le nombre de requêtes HTTP est là pour évaluer la surcharge / souscharge côté serveur. Ce n'est pas un indicateur que nous utilisons pour le réseau. Je ne pense donc pas que HTTP2 change quoi que ce soit. Welcome si vous avez un meilleur indicateur externe / non intrusif côté serveur.