Mesurer la performance JavaScript grâce aux DevTools : anatomie d’un bouton paresseux

Le principal mantra des expert·es en performance web est le suivant : « avant d’optimiser, il faut toujours mesurer ». Il est en effet facile de tomber sur un bout de code et de se dire qu’il pourrait être plus efficient, puis passer quelques heures à l’optimiser pour qu’à la fin le gain de performance soit tout à fait invisible pour les utilisateurs et utilisatrices du site. Il faut donc toujours prendre le temps de bien mesurer les performances d’un site avant de se décider à essayer de l’améliorer. Et pour pouvoir le faire, il est essentiel de bien maîtriser les outils qui nous servent à effectuer ces mesures.

Dans cet article nous allons nous concentrer sur un aspect bien précis des performances web : l’exécution du code JavaScript. Il peut arriver que notre code JavaScript pose des problèmes de performances, ce qui en général se traduit par un manque de fluidité de la page : les interactions ne sont pas immédiates, la page défile par à‑coups, les animations se traînent péniblement, parfois même la page s’arrête complètement de fonctionner. Nous allons voir à l’aide d’un exemple concret comment diagnostiquer ce genre de problèmes, et nous verrons quelques pistes pour les résoudre.

Petit avertissement avant de commencer : j’utilise beaucoup de mots anglais dans l’article, lorsque je trouve que l’équivalent français est moins clair et moins usité.

Prendre la mesure

Voici donc un exemple que j’ai repris du site d’un de mes clients. Il a bien sûr été simplifié à l’extrême pour que nous puissions nous concentrer sur l’essentiel. Il s’agit d’un simple bouton qui déplie un menu.

Si vous ne constatez pas de problème de performance, utilisez la jauge de CPU (Central Processing Unit, en français le processeur) qui simule un processeur plus lent. La plupart du temps lorsqu’on teste les performances d’un site internet, on le fait sur des ordinateurs qui sont bien plus puissants que ceux de nos utilisateur·rices, ce qui peut fausser l’idée qu’on se fait de la fluidité des pages testées. C’est d’ailleurs tellement courant que l’onglet Performance de Chrome vous permet lui aussi de simuler des terminaux moins puissants, via l’option de configuration « CPU Throttling ».

Maintenant que nous avons constaté que le bouton présente des problèmes de performance, nous allons essayer de comprendre ce qu’il se passe. La plupart des navigateurs proposent leur propres outils de développement, nous allons nous concentrer ici sur ceux de Chrome, tout simplement car ce sont ceux que je connais le mieux.

La première chose à faire est d’ouvrir la page en mode navigation privée, afin que vos éventuelles extensions Chrome n’interfèrent pas avec l’outil de profilage. Ensuite il faut ouvrir le panneau d’outils de développement, aller sur l’onglet « Performance », et lancer nouvel un enregistrement des performances.

Cette visualisation est ce qu’on appelle un « flamechart ». Elle permet de voir les appels de fonctions, et le temps pris par chaque fonction (plus une barre est large, plus on a passé de temps dans la fonction). Ici on peut le lire comme ceci (Je laisse volontairement de côté la barre principale Task et ce que signifie Main pour l’instant) :

• L’événement click sur notre bouton déclenche l’appel de la fonction onMenuClick.
• Cette fonction appelle elle-même une fonction sendAnalytics, ainsi qu’une fonction openMenu.
• La fonction sendAnalytics appelle une fonction checkConsentCookie, qui elle-même a appelé une fonction expensiveComputation.
• La fonction openMenu appelle elle aussi la fonction expensiveComputation.

La fonction expensiveComputation, que j’ai écrite, simule volontairement un code très lent.

En survolant chaque barre du flamechart, on peut également voir combien de temps on a passé dans cette fonction. Par exemple sur la capture d’écran on voit qu’on a passé 344 millisecondes dans la fonction sendAnalytics.

En cliquant sur chacune des fonctions, il est possible d’accéder à leur implémentation. En cliquant sur onMenuClick, on arrive sur ce code :

const onMenuClick = event => {
  if (event.target.parentNode.getAttribute("aria-expanded") === "false") {
    sendAnalytics("open-menu");
    openMenu();
  }
  // ...
};

On peut en déduire que notre menu est lent à s’ouvrir parce qu’on envoie des statistiques d’utilisation avant de mettre à jour le DOM (nous allons voir qu’en réalité c’est un peu plus complexe que ça).

const onMenuClick = event => {
  if (event.target.parentNode.getAttribute("aria-expanded") === "false") {
    openMenu(); // d'abord on ouvre le menu
    sendAnalytics("open-menu"); // ensuite on envoie les statistiques
  } 
  // ...
};

Deuxième essai : de belles promesses

Nous savons maintenant qu’il nous faut trouver un moyen d’exécuter notre code en deux tâches, une pour mettre à jour le menu, et une pour envoyer nos statistiques d’utilisation. Peut-être qu’en utilisant des promises (littéralement « Promesses »), qui permettent d’exécuter du code JavaScript de façon asynchrone, nous arriverons à nos fins :

const onMenuClick = event => {
  if (event.target.parentNode.getAttribute("aria-expanded") === "false") {
    new Promise((resolve, reject) => {
      openMenu();
      resolve();
    }).then(() => {
      sendAnalytics("open-menu");
    });
  //...
}

A priori le résultat n’a pas l’air meilleur. Relançons un profil pour comprendre ce qu’il se passe :

On voit qu’une nouvelle barre est apparue : « Run MicroTasks ». L’exécution des promises est en effet différée par rapport à une séquence d’exécution normale, mais plutôt que d’être exécutées dans une nouvelle tâche, elles le sont à la fin de la tâche en cours, dans ce qu’on appelle les « MicroTasks ».

Nous avons donc rendu notre code un peu plus complexe, mais du point de vue des performances rien n’a changé.

const onMenuClick = event => {
  if (event.target.parentNode.getAttribute("aria-expanded") === "false") {
    openMenu();
    setTimeout(() => {
      sendAnalytics("open-menu");
    }, 0);
  }
  //...
}

Diviser pour mieux régner

Une première méthode pour éviter notre Long Task est de la diviser en plusieurs tâches plus petites, chacune lancée grâce à un appel à setTimeout. Pour ce faire il va falloir changer l’implémentation de sendAnalytics.

const sendAnalytics = eventName => {                                                                  
  for (let i = 0; i < 40; i++) {                                                                      
    if (checkConsentCookie()) {                                                                       
      // send analytics                                                                               
    }                                                                                                 
  }                                                                                                   
};

Ceci est une simplification du code que j’ai pu voir chez un client : une quarantaine de services de tracking collectaient des statistiques d’utilisation, et chaque service devait vérifier si l’utilisateur·rice avait bien accepté de voir ses données collectées. Entre l’accès aux cookies et les autres appels de fonctions, la fonction sendAnalytics finissait par générer une Long Task à chaque appel ².

Essayons donc de créer une tâche par service :

const sendAnalyticsInBatches = eventName => {
  for (let i = 0; i < 40; i++) {
    setTimeout(() => { // chaque itération crée une nouvelle tâche
      if (checkConsentCookie()) {
        // send analytics
      }
    });
  }
};
}

Ça fonctionne mieux (la boule noire ne se fige plus complètement), mais on peut toujours constater un petit manque de fluidité dans l’animation. Encore une fois, faisons un nouveau profil pour comprendre ce qu’il se passe :

Nous pouvons voir que la Long Task a bien disparu au profit de nombreuses tâches plus courtes. Mais j’ai inclus dans la capture d’écran un onglet supplémentaire : les frames.

Une histoire de « framerate »

Nous l’avons déjà dit, pour afficher une page à l’écran, le navigateur doit transformer le DOM et le CSS en pixels. Lorsque la page n’est pas figée (ouverture d’un menu, défilement, animation, etc.) le navigateur doit produire plusieurs images. C’est comme au cinéma, on nous fait défiler devant les yeux des images à une certaine vitesse, et notre cerveau les relie entre elles pour en faire une vidéo. Le cinéma est en général à 25 images par seconde, le navigateur lui vise plutôt 60 images par seconde.

Cela signifie que pour que notre animation paraisse fluide, il faut que le navigateur puisse transformer notre DOM en image 60 fois par seconde, c’est-à-dire une fois toutes les 16,6 ms. Et comme vous l’avez peut-être retenu, c’est notre Main Thread qui s’en occupe, ce qui veut dire que le temps pris par notre code JavaScript est du temps en moins pour générer ces images. Lorsque le navigateur n’a pas le temps de générer une image dans le délai imparti, on dit qu’on a « laissé tomber une frame » (dropped a frame en anglais). Dans ce cas, le navigateur laisse affichée la frame précédente. Si ça arrive plusieurs fois d’affilée, ça finit par se voir, comme notre boule noire qui bouge par à‑coups.

L’onglet « Frame » permet de visualiser facilement les frames passées à la trappe (les carrés rouges). Sur notre capture d’écran on constate bien que de nombreuses frames n’ont pas pu être générées car elles étaient bloquées par nos tâches. C’est parce que nous empilons nos appels à setTimeout sans laisser assez de temps au navigateur pour générer des images de temps en temps.

Cela dit, je ne m’explique pas pourquoi Chrome exécute de nombreuses fois des appels consécutifs à nos callbacks sans passer par une étape de « rendering » entre les deux : d’après la spécification le navigateur devrait pourtant passer par cette étape entre chaque tâche JavaScript. Si vous avez l’explication, je serais ravi de l’entendre (par ailleurs cet exemple fonctionne mieux sur Firefox, qui lui semble passer régulièrement par des étapes de rendering, ce qui pourrait indiquer des divergences d’implémentation du standard).

Notons également qu’en ajoutant une animation sur la page, j’ai ajouté beaucoup de pression sur le navigateur qui doit maintenant générer une frame toutes les 16,6 ms, alors qu’en l’absence d’élément animé, réagir en moins de 100 ms suffirait. Quand vous souhaitez optimiser les performances d’un site, il est important de prendre en compte ce contexte pour déterminer quoi optimiser et à quel point. Sur un vrai site il est tout à fait possible que j’arrête dès l’ajout du premier setTimeout, en laissant la Long Task en place si j’estime qu’elle ne nuit pas à l’expérience utilisateur.

Vers une meilleure répartition des ressources

Essayons tout de même d’améliorer encore la fluidité de l’animation. Pour ce faire nous allons changer la façon dont nous créons nos tâches :

const sendAnalyticsInDistributedBatches = eventName => {                                              
  doSendDistributed(40);                                                                              
};                                                                                                    
                                                                                                      
const doSendDistributed = i => {                                                                      
  if (i === 0) {                                                                                      
    return;                                                                                           
  }                                                                                                   
                                                                                                      
  if (checkConsentCookie()) {                                                                         
    // send analytics                                                                                 
  }                                                                                                   
  setTimeout(() => {                                                                                  
    doSendDistributed(i - 1);                                                                         
  });                                                                                                 
};

Si nous n’êtes pas familier des fonctions récursives il est possible que ce bout de code soit difficile à saisir. Ne vous en faites pas, ça n’empêche pas de comprendre le principe : avant nous avions une première tâche qui en programmait quarante d’un coup, maintenant chaque tâche a la responsabilité de programmer la suivante.

Le résultat est plus satisfaisant : nous avons toujours nos nombreuses tâches qui viennent remplacer la Long Task originale, mais elles sont maintenant légèrement plus espacées, ce qui laisse le temps au navigateur de générer nos frames. Il en manque encore quelques-unes, mais c’est parfois inévitable quand une de nos tâches prend plus de 16 millisecondes à s’exécuter.

Il existe cependant une dernière méthode dont j’aimerais dire un mot.

const sendAnalyticsWithRequestIdleCallback = eventName => {                                           
  let i = 0;                                                                                          
  const callback = deadline => {                                                                      
    while ((deadline.timeRemaining() > 0 && i < 40) {                         
      if (checkConsentCookie()) {                                                                     
        // send analytics                                                                             
      }                                                                                               
      i++;                                                                                            
    }                                                                                                 
    if (i < 40) {                                                                                     
      requestIdleCallback(callback);                                                                  
    }                                                                                                 
  };                                                                                                  
  requestIdleCallback(callback);                                                   
};

Conclusion

Je n’ai fait ici qu’effleurer les fonctionnalités de outils de développement de Chrome, véritable mine d’information qui, même si elle peut être intimidante, vaut vraiment la peine d’être explorée quand on passe une partie non négligeable de ses journées de travail à écrire du code JavaScript.

Pour finir j’aimerais noter que les problèmes de performance liés à l’exécution de JavaScript ont à mes yeux une place un peu particulière dans le panel des problèmes de webperf. En effet, encore plus que les problèmes de Layout Shifts ou de connectivité, ils sont liés à la puissance du processeur et vont donc davantage se faire sentir sur les terminaux les moins chers, ce qui signifie qu’ils vont pénaliser plus systématiquement et plus fortement les utilisateur·ices les plus pauvres. J’espère vous avoir convaincu qu’il n’est pas si compliqué d’analyser les performances d’exécution de votre code javascript, et que vous vous sentirez capable de prendre un peu de temps pour vous assurer qu’il ne rend pas votre site inutilisable pour certaines personnes. Vos utilisateur·ices ne remarqueront probablement pas vos efforts, mais c’est bien là le but de la manœuvre.

Quelques ressources utiles (en anglais)

• Une présentation sur l’Event Loop, qui explique comment sont gérées les différentes activités du fil principal d’exécution
• Using requestIdleCallback
• Inside look at modern web browser
• Investigate animation performance with DevTools

En bonus

Les plus curieux d’entre vous seront peut-être allés voir l’implémentation de l’animation de la boule noire :

@keyframes circle {                                                                                   
  0% {                                                                                                
    transform: rotate(0deg) translate(-4rem) rotate(0deg);                                            
  }                                                                                                   
  50% {                                                                                               
  }                                                                                                   
  100% {                                                                                              
    width: 1rem;                                                                                      
    transform: rotate(360deg) translate(-4rem) rotate(-360deg);                                       
  }                                                                                                   
}

Pourquoi avoir ajouté cette propriété width qui ne sert à rien ? Eh bien si on la retire, alors la seule propriété animée de notre élément est la propriété transform, qui partage avec la propriété opacity une caractéristique importante : elle est animée par le GPU (la carte graphique). Cela signifie que lorsque vous animez uniquement ces propriétés sur un élément, le Main Thread n’a pas à générer les 60 images par seconde qui montrent l’élément bouger, c’est la carte graphique qui s’en occupe.

Pour notre exemple cela signifie que si l’on retire la propriété width, nous n’aurons plus aucun problème de fluidité sur l’animation, même si nous générons des Long Tasks avec notre code JavaScript.