14 méthodes pour différer ou planifier JavaScript

Comment choisir la bonne méthode de report ?

Tous les scripts ne sont pas identiques et chaque script a sa propre fonctionnalité. Certains scripts sont importants à avoir tôt dans le processus de rendu, d'autres non.

J'aime catégoriser les JavaScripts en 4 groupes basés sur leur niveau d'importance.

1. Critique pour le rendu. Ce sont les scripts qui changeront l'apparence d'une page web. S'ils ne se chargent pas, la page ne semblera pas complète. Ces scripts doivent être évités à tout prix. Si vous ne pouvez pas les éviter pour une raison quelconque, ils ne doivent pas être différés. Par exemple un slider supérieur ou un script de test A/B.
2. Critique. Ces scripts ne changeront pas l'apparence d'une page web (trop) mais la page ne fonctionnera pas bien sans eux. Ces scripts doivent être différés ou mis en async. Par exemple vos scripts de menu.
3. Important. Ce sont des scripts que vous voulez charger car ils sont précieux pour vous ou le visiteur. J'ai tendance à charger ces scripts après que le load event a été déclenché. Par exemple analytics ou un bouton 'retour en haut'.
4. Nice to have. Ce sont des scripts dont vous pouvez vous passer si vous en avez absolument besoin. Je charge ces scripts avec la priorité la plus basse et je les exécute seulement quand le navigateur est inactif (idle). Par exemple un widget de chat ou un bouton facebook.

Méthode 1 : Utiliser l'attribut defer

Les scripts avec l'attribut defer se téléchargeront en parallèle et sont ajoutés à la file d'attente JavaScript différée. Juste avant que le navigateur ne déclenche l'événement DOMContentLoaded, tous les scripts de cette file d'attente s'exécuteront dans l'ordre dans lequel ils apparaissent dans le document.

<script  src='javascript.js'></script>

Le 'truc defer' corrige généralement beaucoup de problèmes, surtout les métriques de peinture. Malheureusement il n'y a pas de garantie, cela dépend de la qualité des scripts. Les scripts différés s'exécuteront une fois que tous les scripts ont été chargés et que le HTML est analysé (DOMContentLoaded). L'élément LCP (généralement une grande image) pourrait ne pas être chargé d'ici là et les scripts différés causeront toujours un retard dans le LCP.

Quand l'utiliser :

Utilisez des scripts différés pour les scripts Critiques qui sont nécessaires dès que possible.

Avantages :

1. Les scripts différés se téléchargeront en parallèle
2. Le DOM sera disponible au moment de l'exécution

Désavantages :

1. Les scripts différés pourraient retarder vos métriques LCP 
2. Les scripts différés bloqueront le main thread une fois exécutés
3. Il pourrait ne pas être sûr de différer des scripts lorsque des scripts inline ou async dépendent d'eux

Méthode 2 : Utiliser l'attribut async

Les scripts avec l'attribut async se téléchargent en parallèle et s'exécuteront immédiatement après avoir fini de se télécharger.

<script  src='javascript.js'></script>

Les scripts async feront peu pour corriger vos problèmes de vitesse de page. C'est génial qu'ils soient téléchargés en parallèle mais c'est à peu près tout. Une fois téléchargés, ils bloqueront le main thread lorsqu'ils seront exécutés.

Quand l'utiliser :

Utilisez des scripts async pour les scripts Critiques qui sont nécessaires dès que possible et sont autonomes (ne dépendent pas d'autres scripts).

Avantages :

1. Les scripts async se téléchargeront en parallèle.
2. Les scripts async s'exécuteront dès que possible.

Désavantages :

1. DOMContentLoaded peut se produire avant et après async.
2. L'ordre d'exécution des scripts sera inconnu à l'avance.
3. Vous ne pouvez pas utiliser de scripts async qui dépendent d'autres scripts async ou différés

Méthode 3 : Utiliser les modules

Les scripts modulaires sont différés par défaut à moins qu'ils n'aient l'attribut async. Dans ce cas, ils seront traités comme des scripts async

<script  src='javascript.js'></script>

Les modules sont une nouvelle façon de penser JavaScript et corrigent certains défauts de conception. À part cela, l'utilisation de modules de script n'accélérera pas votre site web. 

Quand l'utiliser :

Lorsque votre application est construite de manière modulaire, il est logique d'utiliser également des modules JavaScript.

Avantages :

1. Les modules sont différés par défaut
2. Les modules sont plus faciles à maintenir et fonctionnent très bien avec la conception web modulaire
3. Les modules permettent un découpage de code facile avec des imports dynamiques où vous n'importez que les modules dont vous avez besoin à un certain moment.

Désavantages :

1. Les modules eux-mêmes n'amélioreront pas les Core Web Vitals
2. Importer des modules just-in-time ou à la volée pourrait être lent et aggraver le FID et l'INP 

Méthode 4 : Placer les scripts vers le bas de la page

Les scripts de pied de page sont mis en file d'attente pour le téléchargement plus tard. Cela priorisera d'autres ressources qui sont dans le document au-dessus de la balise script.

<html>
   <head></head>
   <body>
      [votre contenu de page ici]
      <script defer src='javascript.js'></script>
   </body>
</html>

Placer vos scripts en bas de la page est une technique intéressante. Cela planifiera d'autres ressources (comme les images) avant vos scripts. Cela augmentera la chance qu'elles soient disponibles pour le navigateur et peintes à l'écran avant que les fichiers JavaScript n'aient fini de se télécharger et que le main thread ne soit bloqué par l'exécution du script. Pourtant... aucune garantie.

Quand l'utiliser :

Lorsque vos scripts fonctionnent déjà assez bien mais que vous voulez prioriser légèrement d'autres ressources comme les images et les polices web.

Avantages :

1. Placer les scripts en bas de la page ne nécessite pas beaucoup de connaissances.
2. Si c'est fait correctement, il n'y a pas de risque que cela casse votre page

Désavantages :

1. Les scripts critiques pourraient être téléchargés et exécutés plus tard
2. Cela ne corrige aucun problème JavaScript sous-jacent

Méthode 5 : Injecter des scripts

Les scripts injectés sont traités comme des scripts async. Ils sont téléchargés en parallèle et sont exécutés immédiatement après le téléchargement.

<script>
    const loadScript = (scriptSource) => {
        const script = document.createElement('script');
        script.src = scriptSource;
        document.head.appendChild(script);
    }
    
    // appeler la fonction loadscript qui injecte 'javascript.js'
    loadScript('javascript.js');
</script>

D'un point de vue Core Web Vitals, cette technique est exactement la même que l'utilisation de <script async>.

Quand l'utiliser :

Cette méthode est souvent utilisée par des scripts tiers qui se déclenchent le plus tôt possible. L'appel de fonction rend facile l'encapsulation et la compression du code.

Avantages :

1. Code contenu qui injecte un script async.

Désavantages :

1. DOMContentLoaded peut se produire à la fois avant et après que le script soit chargé.
   
2. L'ordre d'exécution du script sera inconnu à l'avance.
3. Vous ne pouvez pas utiliser cela sur des scripts qui dépendent d'autres scripts async ou différés

Méthode 6 : Injecter des scripts plus tard

Les scripts Nice-to-have ne devraient à mon avis jamais être chargés en différé. Ils devraient être injectés au moment le plus opportun. Dans l'exemple ci-dessous, le script s'exécutera après que le navigateur a envoyé le 'load event'.

<script>
window.addEventListener('load', function () {
  // voir méthode 5 pour la fonction loadscript
  loadScript('javascript.js');
});
</script>

C'est la première technique qui améliorera de manière fiable le Largest Contentful paint. Toutes les ressources importantes, y compris les images, seront téléchargées lorsque le navigateur déclenche le 'load event'. Cela pourrait introduire toutes sortes de problèmes car cela pourrait prendre beaucoup de temps pour que le load event soit appelé.

Quand l'utiliser :

Pour les scripts nice-to-have qui n'ont aucune raison d'impacter les métriques de peinture.

Avantages :

1. N'entrera pas en compétition pour les ressources critiques car il injectera le script une fois que la page et ses ressources ont chargé

Désavantages :

1. Si votre page est mal conçue du point de vue Core Web Vitals, cela pourrait prendre beaucoup de temps pour que la page envoie le 'load' event
2. Vous devez faire attention à ne pas appliquer cela aux scripts critiques (comme le lazy loading, menu, etc.)

Méthode 7 : Changer le type de script (puis le rechanger)

Si une balise script est trouvée quelque part sur la page qui 1. a un attribut type et 2. l'attribut type n'est pas "text/javascript", le script ne sera pas téléchargé et exécuté par un navigateur. De nombreux chargeurs JavaScript (comme RocketLoader de CloudFlare) reposent sur ce principe. L'idée est assez simple et élégante.

D'abord tous les scripts sont réécrits comme ceci :

<script  src="javascript.js"></script>

Ensuite, à un moment donné pendant le processus de chargement, ces scripts sont reconvertis en 'javascripts normaux'.

Quand l'utiliser :

Ce n'est pas une méthode que je recommanderais. Corriger l'impact JavaScript prendra beaucoup plus que simplement déplacer chaque script un peu plus loin dans la file d'attente. D'un autre côté, si vous avez peu de contrôle sur les scripts s'exécutant sur la page ou avez des connaissances JavaScript insuffisantes, cela pourrait être votre meilleur pari.

Avantages :

1. C'est facile, activez juste rocket loader ou un autre plugin et tous vos scripts sont maintenant exécutés à un moment un peu plus tardif.
2. CELA corrigera probablement vos métriques de peinture à condition que vous n'ayez pas utilisé de lazy loading basé sur JS.
3. Cela fonctionnera pour les scripts inline et externes.

Désavantages :

1. Vous n'aurez aucun contrôle fin sur le moment où les scripts s'exécutent
2. Un script mal écrit pourrait casser
3. Cela utilise JavaScript pour corriger JavaScript
4. Cela ne fait rien pour corriger les scripts à longue exécution

Méthode 8 : Utiliser l'intersection observer

Avec l'intersection observer, vous pouvez exécuter une fonction (qui dans ce cas charge un JavaScript externe) lorsqu'un élément défile dans la fenêtre visible (viewport).

<script>
const handleIntersection = (entries, observer) => {
    if (entries?.[0].isIntersecting) {
        // charger votre script ou exécuter une autre 
           fonction comme déclencher un élément chargé paresseusement (lazy loaded)
        loadScript('javascript.js');

        // retirer l'observateur
        observer.unobserve(entries?.[0].target);
    }
};
const Observer = new window.IntersectionObserver()
Observer.observe(document.querySelector('footer'));
</script>

C'est de loin la méthode la plus efficace pour différer JavaScript qui existe. Chargez seulement les scripts dont vous avez besoin, juste avant d'en avoir besoin. Malheureusement, la vie réelle est rarement aussi propre et peu de scripts peuvent être liés à un élément qui défile dans la vue.

Quand l'utiliser :

Utilisez cette technique autant que possible ! Chaque fois qu'un script interagit seulement avec un composant hors écran (comme une carte, un slider, un formulaire), c'est la meilleure façon d'injecter ce script.

Avantages :

1. N'interférera pas avec les Core Web Vitals LCP et FCP
2. N'injectera jamais de scripts qui ne sont pas utilisés. Cela améliorera le FID et l'INP

Désavantages :

1. Ne doit pas être utilisé avec des composants qui pourraient être dans le viewport visible
2. Est plus difficile à maintenir que le basique <script src="...">
3. Pourrait introduire un layout shift

Méthode 9 : Utiliser readystatechange

document.readystate peut être utilisé comme une alternative à l'événement 'DOMContentloaded' et 'load'. Le readystate 'interactive' est généralement un bon endroit pour appeler des scripts critiques qui doivent changer le DOM ou ajouter des gestionnaires d'événements. 
Le readystate 'complete' est un bon endroit pour appeler des scripts qui sont moins critiques.

document.addEventListener('readystatechange', (event) => {
  if (event.target.readyState === 'interactive') {
    initLoader();
  } else if (event.target.readyState === 'complete') {
    initApp();
  }
});

Méthode 10 : Utiliser setTimeout sans délai

setTimeout est une méthode mal vue mais fortement sous-estimée dans la communauté pagespeed. setTimeout a mauvaise réputation car il est souvent mal utilisé.  De nombreux développeurs croient que setTimeout ne peut être utilisé que pour retarder l'exécution du script du nombre de millisecondes défini. Bien que ce soit vrai, setTimeout fait en fait quelque chose de bien plus intéressant. Il crée une nouvelle tâche à la fin de la boucle d'événements du navigateur. Ce comportement peut être utilisé pour planifier vos tâches efficacement. Il peut également être utilisé pour décomposer de longues tâches en tâches plus petites séparées

<script>
   setTimeout(() => {
       // charger un script ou exécuter une autre fonction
       console.log('- Je suis appelé depuis un timeOut() de 0ms')
    }, 0);

   console.log('- J'étais dernier dans la file mais exécuté en premier')
   /*
      Sortie :
      - J'étais dernier dans la file mais exécuté en premier
      - Je suis appelé depuis un timeOut() de 0ms
   */
</script>

Quand l'utiliser :

setTimeout a créé une nouvelle tâche dans la boucle d'événements du navigateur. Utilisez ceci lorsque votre main thread est bloqué par de nombreux appels de fonction qui s'exécutent séquentiellement.

Avantages :

1. Peut décomposer du code à longue exécution en morceaux plus petits.

Désavantages :

1. setTimeout est une méthode plutôt rudimentaire et n'offre pas de priorisation pour les scripts importants.
2. Ajoutera le code à exécuter à la fin de la boucle

Méthode 11 : Utiliser setTimeout avec un délai

Les choses deviennent encore plus intéressantes lorsque nous appelons setTimeout avec un délai de plus de 0ms

<script>
   setTimeout(() => {
       // charger un script ou exécuter une autre fonction
       console.log('- Je suis appelé depuis un timeOut() de 10ms')
    }, 10);

   setTimeout(() => {
       // charger un script ou exécuter une autre fonction
       console.log('- Je suis appelé depuis un timeOut() de 0ms')
    }, 0);

   console.log('- J'étais dernier dans la file mais exécuté en premier')
   /*
      Sortie :
      - J'étais dernier dans la file mais exécuté en premier
      - Je suis appelé depuis un timeOut() de 0ms
      - Je suis appelé depuis un timeOut() de 10ms
   */
</script>

Quand l'utiliser :

Lorsque vous avez besoin d'une méthode facile pour planifier un script après un autre, un petit délai fera l'affaire

Avantages :

1. Supporté sur tous les navigateurs

Désavantages :

1. N'offre pas de planification avancée

Méthode 12 Utiliser une promesse pour définir une microtâche

Créer une micro-tâche est aussi une façon intéressante de planifier JavaScript. Les micro-tâches sont planifiées pour une exécution immédiatement après que la boucle d'exécution actuelle a fini.

<script>
   const myPromise = new Promise((resolve, reject) => {
      resolve();
   }).then(
      () => {       
         console.log('- J'ai été planifié après une promesse')
         }
   );   
   console.log('- J'étais dernier dans la file mais exécuté en premier')

   /*
      Sortie :
      - J'étais dernier dans la file mais exécuté en premier
      - J'ai été planifié après une promesse
   */
</script>

Quand l'utiliser :

Lorsqu'une tâche doit être planifiée immédiatement après une autre tâche. 

Avantages :

1. La microtâche sera planifiée immédiatement après que la tâche a fini de s'exécuter.
2. Une microtâche peut être utilisée pour retarder des morceaux de code JavaScript moins importants dans le même événement. 

Désavantages :

1. Ne décomposera pas le main thread en plus petites parties. Le navigateur n'aura aucune chance de répondre à l'entrée utilisateur.
2. Vous n'aurez probablement jamais besoin d'utiliser des microtâches pour améliorer les Core Web Vitals à moins que vous ne sachiez déjà exactement ce que vous faites.

Méthode 13 Utiliser une microtâche

Le même résultat peut être obtenu en utilisant queueMicrotask(). L'avantage d'utiliser queueMicrotask() par rapport à une promesse est qu'il est légèrement plus rapide et vous n'avez pas besoin de gérer vos promesses.

<script>
   queueMicrotask(() => {
      console.log('- Je suis une microtâche')
   })
     
   console.log('- J'étais dernier dans la file mais exécuté en premier')

   /*
      Sortie :
      - J'étais dernier dans la file mais exécuté en premier
      - Je suis une microtâche
   */
</script>

Méthode 14 : Utiliser requestIdleCallback

La méthode window.requestIdleCallback() met en file d'attente une fonction à appeler pendant les périodes d'inactivité (idle) d'un navigateur. Cela permet aux développeurs d'effectuer un travail de fond et de faible priorité sur la boucle d'événements principale, sans impacter les événements critiques pour la latence tels que l'animation et la réponse aux entrées. Les fonctions sont généralement appelées dans l'ordre premier entré, premier sorti ; cependant, les rappels (callbacks) qui ont un timeout spécifié peuvent être appelés dans le désordre si nécessaire afin de les exécuter avant que le timeout ne s'écoule.

<script>
requestIdleCallback(() => {
    const script = document.createElement('script');
    script.src = 'javascript.js';
    document.head.appendChild(script);
});
</script>

Quand l'utiliser :

Utilisez ceci pour les scripts qui sont Nice to have ou pour gérer des tâches non critiques après l'entrée utilisateur

Avantages :

1. Exécuter JavaScript avec un impact minimal pour l'utilisateur
2. Améliorera très probablement le FID et l'INP

Désavantages :

1. Supporté dans la plupart des navigateurs mais pas tous. Il existe des poly-fills qui se rabattent sur setTimeout();
2. Aucune garantie que le code se déclenchera un jour 

Méthode 15 : Utiliser postTask

La méthode permet aux utilisateurs de spécifier optionnellement un délai minimum avant que la tâche ne s'exécute, une priorité pour la tâche, et un signal qui peut être utilisé pour modifier la priorité de la tâche et/ou annuler la tâche. Elle renvoie une promesse qui est résolue avec le résultat de la fonction de rappel de la tâche, ou rejetée avec la raison de l'annulation ou une erreur levée dans la tâche.

<script>
scheduler.postTask(() => {
    const script = document.createElement('script');
    script.src = 'javascript.js';
    document.head.appendChild(script);
}, { priority: 'background' });
</script>

Quand l'utiliser :

postTask est l'API parfaite pour planifier un script. Malheureusement, le support du navigateur à ce moment est mauvais donc vous ne devriez pas l'utiliser.

Avantages :

1. Contrôle complet sur la planification de l'exécution JavaScript !

Désavantages :

1. Non supporté dans certains navigateurs importants.