javascript

Voyons les différences entre les attributs synchrone, asynchrone et defer, et en quoi utiliser du JS asynchrone à foison peut être contre-productif.

Différences entre sync, async et defer

Dans un billet publié sur le Perf Calendar en 2016, Steve Souders détaille ces 3 attributs et explique pourquoi il préfère defer à async, bien que dans les deux cas, s’ils ne bloquent pas le parser HTML, ils peuvent bloquer le rendu de la page. Voici le fonctionnement de chacune de ces méthodes.

Javascript Asynchrone

Pour aller plus loin, cet article détaille la façon dont une page se construit élément par élément, et explique pourquoi certains scripts sont bloqués par le parser (analyseur) HTML.

Sync

Avec cet attribut, l'exécution de JavaScript est bloquante pour l'analyseur. Pourquoi ? Parce que lorsque le navigateur détecte un script, il doit suspendre la construction du DOM, télécharger le script, céder la place à l'exécution JavaScript, et laisser le script s'exécuter avant de terminer la construction du DOM.

Cette méthode est utilisée par exemple pour les scripts d’A/B testing afin d’éviter l’effet de flickering.

Async

Async est réputé non bloquant, mais nous allons voir que ce n’est pas totalement vrai.

Dans le cas du JS asynchrone, le navigateur ne va pas interrompre l’analyse du code HTML, il télécharge le script en parallèle. Cependant, une fois le téléchargement achevé, il exécute immédiatement le script et bloque alors l’analyse de la suite du code HTML, l’exécution des autres scripts, ainsi que le rendu de la page.

Le problème que peut poser async est donc le suivant : l’exécution des scripts ne suit pas l’ordre du code, et selon la quantité de JavaScript à exécuter, cela peut bloquer le fil d’exécution principal (main thread) et donc dégrader le Time To Interactive.

Defer 

Avec l’attribut defer, le navigateur identifie le script, le télécharge, mais ne l’exécute qu’une fois que le HTML est parcouru en entier. Dans ce cas de figure, l’ordre d’exécution des scripts est respecté et démarre après le DOM Interactive.

JS asynchrone, ou la tentation d’empiler les scripts

Profitant de cette réputation (pourtant injustifiée) d’être non bloquant, l’attribut async a fleuri sur tous les sites, au point qu’on en oublierait presque qu’un navigateur n’a qu’un seul fil d’exécution principal se chargeant à la fois du parsing du HTML, des CSS, de l’exécution du JS et du rendu de la page - et ce en plus des téléchargements qui peuvent se dérouler en tâche de fond. 

Ce phénomène est aussi renforcé par le fait que les temps de réponse serveur et de connexion sont de plus en plus courts, mais ce n’est pas une raison pour multiplier sans limite les scripts en utilisant un attribut async. Ça ne les rend pas gratuits en termes de webperf !

En effet, quand beaucoup de scripts asynchrones s’exécutent, si ce n’est pas bloquant pour le téléchargement, ça le reste pour l’exécution. Le principe est d’ailleurs très bien illustré par ce tableau publié par Addy Osmani qui récapitule la priorisation des scripts dans Chrome : les scripts asynchrones sont en bas, même quand ils sont prioritaires pour l’exécution.

Remettons l’église au milieu du village, soyons précis sur ce qu’on entend par “non bloquant” : cela concerne en réalité uniquement la stack réseau, et non le rendu de la page et l’interactivité.

Sachez que même un script asynchrone peut ainsi entraîner un SPOF, non pas au niveau du rendu de la page mais de l’exécution, mettant à mal l’interactivité de la page. Et si c’est un script tiers vous n’aurez évidemment pas la main dessus.

Alors, comme nous sommes bien conscients de l’utilité des scripts - qui plus est pour le marketing -, voici quelques bonnes pratiques pour vous aider à les utiliser en préservant vos performances :

  • Découpez votre code pour éviter les long tasks (scripts qui mettent plus de 50ms à s’exécuter) qui bloquent le navigateur et dégradent votre Time To Interactive, et donc votre UX.
  • Fixez un budget performance et faites le ménage dans vos scripts.
  • Ne vous en remettez pas uniquement à un gestionnaire de tags, car cela ne vous aidera en rien pour l’exécution des scripts.

Enfin, si vous vous demandez plus précisément comment intégrer efficacement vos scripts et améliorer vos performances, Steve Souders aborde le sujet dans sa conférence “Make JavaScript Faster” à performance.now 2018 ; Flavio Copes en parle ici sur son blog ; et nos amis de Dareboost également.

Et pour optimiser automatiquement et durablement vos performances :

Découvrez nos fonctionnalités

 

 


Hello SMX Paris !