[New] Eviter les traitements Javascripts trop longs

[Fred-artwai]

Je sais que l'écoindex donne beaucoup d'importance au DOM. Coef 3 par rapport aux autres. Toutefois, si l'on conçoit une page avec un gros DOM sans traitement JS, on sollicite moins le terminal que si on fait une page avec un petit DOM mais avec un JS qui ne fait que le parcourir.

Cela a 3 impacts néfastes :

1. çà m'énerve
2. çà utilise le processeur plus que de raison donc cela vide la batterie plus vite
3. çà encourage l'utilisateur à changer de smartphone

Or grâce à des outils de perf comme LightHouse ou Dareboost, on peut mesurer l'impact des JS.
Google à une recommandations concernant le Total Blocking Time qui doit être sous la barre des 300ms.
Pour rappel, le Total Blocking Time (TBT) mesure le temps total occupé par des « Long Tasks » (Tâches longues) durant l’activité principale du thread JavaScript. Une Long Task est un traitement qui dure plus de 50ms et qui monopolise le navigateur web. Pendant le traitement de cette « long Task », la page web est incapable de répondre à une interaction utilisateur.

Autres métriques possibles mais pour l'instant sans recommandations quelconques, le BootUp Time ou le temps de chargements total (mais je préfère pour le moment le TBT).

[ACTLEM]

A chaud, je dirais que c'est une bonne idée même si le titre semble générique: expliquer pourquoi cette bonne pratique et dans la description donner des pistes pour évaluer la BP. Bref +1 pour moi ;)

[DocRoms]

Je suis plutôt d'accord sur le TBT .
On vois de plus en plus de sites avec un DOM relativement léger, mais avec des scripts de TP atrocement lourds, et executant des actions toutes les 3ms... c'est lent, c'est pénible, c'est une hérésie au niveau de la qualité web.

On pourrait aussi copier outrageusement le graphique d'explication sur https://web.dev/tbt/ :) pour le TBT, Il est top.

Et rajouter un principe de validation de règle :

Nombre de ms bloquant le rendu de la page doit être < 300.
(Perso je dirais bien moins , mais au moins, mais au moins on reste iso à ce qui se dit chez lightouse ;) )

[tbroyer]

scripts de TP

Tu peux préciser ? on ne partage visiblement pas le même jargon 😅

Nombre de ms bloquant le rendu de la page doit être < 300.
(Perso je dirais bien moins , mais au moins, mais au moins on reste iso à ce qui se dit chez lightouse ;) )

https://web.dev/tbt/#what-is-a-good-tbt-score dit 200 😉

[DocRoms]

TP = Third Parts = Tierces parties en 🇫🇷 .

Ce sont tous les scripts JS de partenaires (Pub / Tracking / Modules sociaux...)

[fzaninotto]

Je ne suis pas sur que la formulation soit adéquate. D'abord parce qu'il peut y avoir un JS long mais non bloquant, auquel cas ça ne gêne pas l'utilisateur. Par ailleurs, long ne veut pas forcément dire consommateur de ressources. Un JS peut être long parce qu'il attend la réponse d'un service tiers. Enfin, "long" nécessite un référentiel, parce que ça ne veut pas forcément dire grand chose.

Sur le sujet de l'empreinte environnementale, l'impact du JS se mesure en Watt.heures (ce que nous faisons avec GreenFrame). C'est plus sur ce genre de métrique qu'il faudrait attirer l'attention, plutôt que sur le temps d'exécution lui-même.

[tbroyer]

Sur le sujet de l'empreinte environnementale, l'impact du JS se mesure en Watt.heures (ce que nous faisons avec GreenFrame). C'est plus sur ce genre de métrique qu'il faudrait attirer l'attention, plutôt que sur le temps d'exécution lui-même.

Sauf erreur, il y a 2 aspects:

• la conso électrique qui impacte directement le cycle de recharge de la batterie (pour un laptop ou un smartphone/tablette); voir aussi https://www.greenit.fr/2020/01/21/lelectricite-nest-pas-un-indicateur-environnemental/
• le blocage du thread principal, qui dégrade l'expérience utilisateur, et qui peut être corrélée à la puissance du processeur (notamment sur mobile)

Ces deux aspects peuvent mener à un renouvellement du terminal utilisateur.

Découper un traitement "lourd" en de nombreuses petites tâches pour éviter de bloquer le thread principal va potentiellement améliorer l'expérience utilisateur (disons qu'a minima les spinners vont correctement s'animer 😅) mais n'aura aucun impact sur la batterie (conso élec). Et pourtant ça peut être un premier levier pour diminuer l'impression que son device est "à la ramasse" et qu'il faut en changer.

[fzaninotto]

je suis d'accord, la consommation impacte directement le changement climatique via les émissions liées à la production d'énergie, et le ralentissement impacte indirectement le changement climatique via les émissions liées à la production d'un nouvel appareil.

Il n'en reste pas momins que la formulation initiale n'est à mon sens pas adaptée. Si l'on veut éviter une forte conso d'énergie et un fort ralentissement, c'est plus sur des temps de rendu de frames qu'il faut se concentrer que sur un "javascript long" (qui, encore une fois, veut dire une chose différente pour chacun).

[Fred-artwai]

Je suis d'accord avec @fzaninotto la formulation n'est pas assez précise.
Attention : le TBT mesure les temps où le navigateur travaille où il utilise le processeur. Le temps d'attente d'une requête n'est pas compatibilisé dans ce temps. où alors c'est que c'est codé avec les pieds.
J'essaie :
Eviter les temps de blocages par des traitements javascript trop longs.
ou
Eviter de bloquer le navigateur avec des traitements javascript trop longs.

[DocRoms]

Non, le TBT ne mesures pas le temps d'attente des requests (à moins qu'on puisse avoir des définitions différentes sur des metrics de #webPerf 😅) Il est calculé en temps d'execution sur le main-thread ;) .

Oui, la formulation n'est pas précise, je suis d'accord avec @Fred-artwai et @fzaninotto sur ce point là, on pourrait parler de réduire le temps d'exécution du Javascript (cf le JS bloquant sur le main-thread :) )

ℹ️ Normalement, c'est un indicateur que l'on peut visuellement voir assez simplement avec un test sur webpagetest.org ;)
exemple ci dessous :

[ACTLEM]

Plutôt pour "Eviter les temps de blocages par des traitements javascript trop longs"

[ACTLEM]

@Fred-artwai j'ai créé l'issue pour que tu puisses proposer quelque chose de concret: #309