Skip to main content

Identification des problèmes de performances dans l’application Bad Bunch

Objectifs de formation

Une fois cette unité terminée, vous pourrez :

  • Présenter différentes façons de limiter les performances
  • Utiliser le panneau Performance monitor (Surveillance des performances) pour localiser les problèmes de nœuds DOM

Appels d’événements consommant des ressources de manière excessive

Dans l’unité précédente, nous avons procédé au dépannage d’un composant Web Lightning peu performant dont une partie du code était mal placé dans une boucle. Examinons un autre exemple de situation problématique et la manière de la résoudre.

  1. Avec l’application Bad Bunch ouverte, sélectionnez Example 2: Scroll List (Exemple 2 : liste déroulante) et attendez que la page se charge complètement.
  2. Dans le volet Performance (Performances) de DevTools, cliquez sur Enregistrement pour démarrer un enregistrement de profil.
  3. Faites maintenant défiler la liste sous Scroll This List! (Faites défiler cette liste !)
    Exemple 2 : liste déroulante avec la liste défilée vers le bas.
    Le défilement de la liste devrait vous sembler un peu lent ou saccadé.
  4. Dans le volet Performance (Performances), cliquez sur Stop (Arrêter) pour mettre fin à l’enregistrement et laisser le volet compiler les données.
    Volet Performance (Performances) affichant plusieurs événements appelés.
    Regardez tous les événements JavaScript appelés dans la section Main (Principal). Vous remarquerez la présence de nombreux petits triangles rouges.
    Volet Performance (Performances) avec un événement mis en évidence.
    Chrome, à l’aide de ce triangle rouge, indique qu’il est possible qu’un appel ait pris trop de temps.
  5. Descendez dans la pile d’appels et cliquez sur l’un des événements onScroll pour obtenir plus d’informations dans l’onglet Summary (Résumé).
    Volet Summary (Résumé) avec les détails de l’événement mis en surbrillance et un lien vers la fonction dans le code.
    Vous remarquerez que cela vient de notre code : cela concerne la méthode onScroll dans le fichier example2_ScrollList.js, à la ligne 87, plus précisément.
  6. Dans le volet Summary (Résumé), cliquez sur le lien vers exemple2_ScrollList.js pour accéder au volet Sources avec le code affiché.
    Volet Sources affichant le fichier example2_ScrollList.js avec des horodatages à côté des numéros de ligne.
    Regardez la ligne 82 : li.style.background = ‘#edede’;.

    Nous ajoutons du style avec le code à chaque défilement. Il s’agit d’un aspect qui devrait être traité d’une manière différente. Cela fait consommer beaucoup de ressources supplémentaires à l’événement. Il existe des pseudo-classes de feuilles CSS (Cascading Style Sheets) comme tr:nth-child(even) et tr:nth-child(odd) qui permettent exactement d’accomplir cela. Avoir recours à une approche CSS sera toujours plus rapide que d’utiliser du JavaScript.

    Un autre problème ici est l’absence d’un anti-rebond pour empêcher l’événement de se déclencher trop souvent. L’ajout d’un écouteur à un événement de défilement provoquera de nombreux déclenchements de celui-ci. Si cet événement entraîne des opérations coûteuses en ressources, c’est encore pire. Pour plus d’informations, reportez-vous à la section Resources (Ressources).
Remarque

Dans Chrome, l’événement de défilement se déclenche une fois par frame pendant le défilement, c’est-à-dire une fois toutes les 16,7 ms sur un écran à 60 FPS. Dans Safari, il se déclenche encore plus rapidement (ce qui est d’ailleurs contraire aux spécifications).

Rendu des styles recalculés

  1. Avec l’application Bad Bunch ouverte, sélectionnez Example 3: Input Fields (Exemple 3 : champs de saisie).
    Dans le cadre de cet exemple, vous devrez peut-être limiter le processeur.
  2. Dans Capture Settings (Paramètres de capture) (), pour CPU (Processeur) sélectionnez 4x slowdown (Ralentissement x 4) pour simuler un navigateur plus lent.
    Volet Performance (Performances) montrant CPU (Processeur) réglé sur 4x slowdown (Ralentissement x 4) avec un indicateur d’avertissement à côté de l’onglet des Performance (Performances) et une icône Capture settings (Paramètres de capture) rouge.
    Notez la présence de l’icône d’avertissement figurant à côté de Performance (Performances) et l’icône Capture settings (Paramètres de capture) rouge, qui indiquent que l’écran est limité. La limitation se rapporte aux capacités de votre ordinateur. Par exemple, l’option 4x slowdown (Ralentissement x 4) fait fonctionner votre processeur 4 fois plus lentement que sa capacité habituelle.
  3. Dans le volet Performance (Performances) de DevTools, cliquez sur Enregistrement.
  4. Commencez à saisir du texte dans Input #1 (Entrée n° 1).
    Exemple 3 : Input Fields (Champs de saisie) avec du texte saisi dans Input #1 (Entrée n° 1).
    L’expérience est saccadée, tout sauf fluide.
  5. Commencez à saisir du texte dans Input #2 (Entrée n° 2). Cela est nettement plus fluide.
  6. Dans le volet Performance (Performances), cliquez sur Stop (Arrêter) pour mettre fin à l’enregistrement et laisser le volet compiler les données.
    Volet Performance (Performances) affichant plusieurs événements appelés, avec beaucoup de violet affiché dans la section du graphique CPU (Processeur).
    Le graphique CPU (Processeur) est très violet. En consultant l’onglet Summary (Résumé), on peut voir que le violet correspond à la catégorie Rendering (Rendu). La majorité du temps est consacrée au rendu. Il y a également beaucoup de triangles rouges.
    Faisons un zoom sur une petite section seulement. D’abord, désactivons la limitation du processeur.
  7. Dans Capture Settings (Paramètres de capture) (), désactivez la limitation du processeur.
    Nous vous recommandons de désactiver toute limitation dès que vous avez fini de l’utiliser, car elle continue de s’appliquer même lorsque l’enregistrement est terminé.
  8. Cliquez sur une petite section du graphique CPU (Processeur) et faites-y glisser votre souris.
    Volet Performance (Performances) montrant une section agrandie des événements et affichant un grand bloc violet intitulé Recalculate Style (Recalculer le style).
    Regardez le grand bloc Recalculate Style (Recalculer le style). Quelque chose provoque un recalcul des styles CSS coûteux en ressources.
  9. Cliquez sur l’un des événements onSlowInput pour obtenir les informations dans le volet Summary (Résumé).
    Volet Summary (Résumé) avec un lien vers example3_InputFields.js.
  10. Dans le volet Summary (Résumé), cliquez sur le lien example3_InputFields.js pour l’ouvrir dans le volet Sources.
    Volet Sources affichant example3_InputFields.js avec les méthodes onSlowInput onFastInput et block.
    La méthode onSlowInput appelle la méthode block. La méthode block affiche beaucoup de divs avec des tailles aléatoires, ce qui entraîne le recalcul des styles. Cela est problématique.
    La méthode onFastInput, située à la ligne 166, est appelée à partir du champ Input #2 (Entrée n° 2). Elle effectue également un appel à l’appel block, mais seulement après son rebond. Cela montre à quel point l’anti-rebond est utile. Nous vous recommandons d’utiliser la méthode anti-rebond et de mettre à jour la méthode de blocage de sorte qu’elle ne provoque pas de recalcul.

Explosion des nœuds DOM

L’exemple suivant peut provoquer le blocage de votre navigateur. Vous pouvez dans ce cas utiliser le gestionnaire de tâches mentionné dans la première unité pour recommencer.

  1. Avec l’application Bad Bunch ouverte, sélectionnez l’onglet Example 4: Table (Exemple 4 : tableau).
    Si votre navigateur se bloque, utilisez le gestionnaire de tâches de Chrome pour mettre fin au processus et recommencer.
    Exemple 4 : tableau affiché avec beaucoup de données.
    Il y a beaucoup de données, mais elles devraient se charger plus rapidement. Enregistrons un profil au cours du chargement de la page.
  2. Cliquez sur Example 3 : Input Fields (Exemple 3 : champs de saisie) pour basculer vers cet onglet.
  3. Dans le volet Performance (Performances) de DevTools, cliquez sur Enregistrement.
  4. Cliquez maintenant sur Example 4: Table (Exemple 4 : tableau).
    Attendez que l’onglet se charge.
  5. Dans le volet Performance (Performances), cliquez sur Stop (Arrêter) pour mettre fin à l’enregistrement et laisser le volet compiler les données.
    Volet Performance (Performances) affichant l’enregistrement du profil.
    Si vous effectuez plusieurs enregistrements de profil, vous pouvez basculer entre ceux-ci dans le menu Performance (Performances).
    Menu du volet Performance (Performances) affichant plusieurs enregistrements.
    Faire défiler la page vers le bas dans la pile d’appels de la section principale vous mènera à un événement renderCallback qui semble s’être exécuté plusieurs fois, mais qui s’est en réalité exécuté une seule fois.
  6. Cliquez sur l’événement renderedCallback pour obtenir des informations dans le volet Summary (Résumé).
    L’événement renderedCallback est mis en surbrillance et ses informations sont affichées dans l’onglet Summary (Résumé).
  7. Dans le volet Summary (Résumé), cliquez sur le lien example4_Table.js pour l’ouvrir dans le volet Sources.
    Volet Sources affichant exemple4_Table.js avec la méthode renderCallback.
    Il se passe beaucoup de choses dans cette méthode. En l’analysant plus en détail, on découvre que de nombreux divs sont en cours de création. Examinons une autre manière de visualiser ceci.
  8. De retour sur l’onglet Example 4: Table (Exemple 4 : tableau), faites un clic droit dans l’une des cellules du tableau et sélectionnez Inspect (Inspecter).
    Le volet Elements (Éléments) de DevTools s’ouvre pour afficher le balisage HTML de la cellule du tableau.
    Volet Elements (Éléments) de DevTools affichant une importante arborescence de balises div.
    Il y a vraiment beaucoup de balises div. De plus, ce n’est là qu’une des cellules du tableau.
    Utilisons le panneau Performance monitor (Surveillance des performances) pour nous faire une meilleure idée de la situation.
  9. Dans DevTools, cliquez sur Menu Customize and control DevTools (Personnaliser et contrôler les Outils de développement) pour développer le menu. Ensuite, cliquez sur More tools (Autres outils), puis sur Performance monitor (Surveillance des performances).
    Arborescence de menus depuis Customize and control DevTools (Personnaliser et contrôler les Outils de développement), affichant les liens More tools (Autres outils) et Performance monitor (Surveillance des performances).
    Le panneau Performance monitor (Surveillance des performances) apparaît au bas de DevTools. Le panneau Performance monitor (Surveillance des performances) présente une vue en temps réel de divers aspects des performances de chargement ou d’exécution d’une page, tels que l’utilisation du processeur, la taille du segment de mémoire JavaScript, le nombre total de nœuds DOM, etc.
    DevTools avec le panneau Performance monitor (Surveillance des performances) ouvert.
    Regardez les nœuds DOM ! Il y en a plus de 400 000. Voyons ce que cela donne dans le cadre du chargement de la page.
  10. Dans le panneau Performance monitor (Surveillance des performances), désélectionnez JS heap size (Taille du segment de mémoire JS et JS event listeners (Écouteurs d’événements JS).
  11. Rechargez la page et regardez le nombre de nœuds DOM augmenter.

Il s’agit d’un problème pouvant concerner les pages contenant beaucoup d’informations, pas seulement les tableaux de données. Cela peut poser un problème se rapportant à la manière dont laquelle les composants Web Lightning sont construits et associés. Les composants situés dans des composants figurant eux-mêmes au sein d’autres composants, ou bien les composants qui génèrent dynamiquement d’autres composants ou un grand nombre de balises HTML, peuvent ajouter de nombreux nœuds DOM à la mise en page.

Nous avons exploré plusieurs manières de rechercher des problèmes de performances relatifs aux composants Web Lightning, et même plus simplement aux pages Lightning en général. Vous avez désormais de nouveaux outils à votre disposition et êtes mieux armé pour résoudre les problèmes de performances.

Ressources

Partagez vos commentaires sur Trailhead dans l'aide Salesforce.

Nous aimerions connaître votre expérience avec Trailhead. Vous pouvez désormais accéder au nouveau formulaire de commentaires à tout moment depuis le site d'aide Salesforce.

En savoir plus Continuer à partager vos commentaires