Skip to main content
Rejoignez-nous lors de l'événement TDX à San Francisco ou sur Salesforce+ les 5 et 6 mars pour la conférence des développeurs à l'ère des agents IA. Inscrivez-vous dès maintenant.

Dépannage des problèmes réseau

Objectifs de formation

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

  • Utiliser Chrome DevTools pour examiner des problèmes de réseau concernant des composants Web Lightning
  • Examiner les demandes et les réponses dans le volet Network (Réseau)

Dépannage des problèmes de réseau pour les composants Web Lightning

Les performances, c’est-à-dire la vitesse d’exécution d’un site, dépendent de nombreux facteurs : ressources du serveur, ressources du client, vitesse du navigateur, etc. De nombreux sites s’appuient uniquement sur le temps de chargement des pages pour mesurer leurs performances. Chez Salesforce, lorsque nous mesurons les performances de Lightning, nous nous concentrons sur les performances perçues par l’utilisateur. Le temps d’expérience de la page (EPT) est une métrique de performances définie par Salesforce pour mesurer le temps nécessaire afin qu’une page soit chargée et prête à être utilisée de manière significative par l’utilisateur.

Le dépannage des problèmes de performances des composants Web Lightning peut vous conduire à travailler sur de nombreux aspects différents. L’EPT est un indicateur général des performances des pages. Pour analyser de manière plus approfondie les problèmes en matière de performances, trois principaux domaines sont à considérer.

  • Performances du réseau
  • Performances du navigateur
  • Complexité et personnalisation des pages

Triangle EPT avec, sur chacun de ses côtés respectifs, les mentions Network Performance (Performances du réseau), Browser Performance (Performances du navigateur) et Page Complexity and Customization (Complexité et personnalisation des pages).

Dans ce module, nous examinons les performances du réseau et du navigateur, en nous intéressant particulièrement à la mémoire du navigateur.

Avant de commencer

Les outils de développement de la plupart des navigateurs ont des fonctionnalités similaires. Dans ce module, nous nous intéressons à Chrome DevTools.

Nous partons du principe que votre environnement de développement Salesforce DX est configuré et que vous savez l’utiliser pour créer des composants Web Lightning et les déployer dans une organisation. Si vous ne maîtrisez pas encore ce processus, suivez le projet Prise en main rapide : composants Web Lightning avant de continuer à suivre ce module.

Ce module repose en grande partie sur l’expérience que vous avez eue avec Chrome DevTools dans le cadre des modules précédents du parcours Dépannage des composants Web Lightning. En effet, si vous venez de terminer ces badges, votre Playground devrait déjà comporter le code provenant de GitHub nécessaire pour ce module. Suivez ces étapes pour vérifier que vous disposez du code issu de GitHub le plus récent.

  1. Dans Visual Studio Code, ouvrez le projet troubleshoot-lwc.

    Cliquez sur File (Fichier) | Open (Ouvrir) (macOS) ou File (Fichier) | Open Folder (Ouvrir le dossier) (Windows) et sélectionnez le répertoire troubleshoot-lwc.

  2. Dans Visual Studio Code, ouvrez l’outil Command Palette (Palette de commandes) en appuyant sur Ctrl+Maj+P (Windows) ou sur Cmd+Maj+P (macOS).
  3. Saisissez git.
  4. Sélectionnez Git: Pull (Git : extraire).
  5. Dans le répertoire force-app/main/default, ouvrez le répertoire permissionsets.
  6. Vérifiez que le fichier Bad_Net_Full_Access.permissionset-meta.xml existe.
  7. Faites un clic droit sur le dossier default sous force-app/main.
  8. Sélectionnez SFDX :. déployer la source dans l’organisation.
  9. Cliquez sur View (Afficher) | Terminal.
  10. Associez l’ensemble d’autorisations Bad Net Full Access (Accès complet à Bad Net) à l’utilisateur par défaut en exécutant la commande suivante dans le terminal :
    sf org assign permset --name Bad_Net_Full_Access
  11. Passez à la section Démarrage avec un navigateur exempt de modifications ci-dessous.

Configuration de votre environnement de dépannage

Premièrement, si vous n’avez pas terminé le moduleDépannage des composants Web Lightning, vous devez configurer un Trailhead Playground avec certains composants Web Lightning et le préparer à être utilisé à des fins de dépannage dans ce module.

Prêt à utiliser les composants Web Lightning de manière concrète ?

Nous ne proposons pas de défis pratiques dans ce module, mais vous pouvez mettre les étapes en pratique dans votre Trailhead Playground. Voici comment accéder à votre Playground. Tout d’abord, assurez-vous d’être connecté à Trailhead. Ensuite, cliquez sur votre avatar d’utilisateur situé en haut à droite de la page et sélectionnez Hands-on Orgs (Organisations d’exercice) dans le menu déroulant. Cliquez sur Launch (Lancer) à côté de l’organisation que vous souhaitez ouvrir. Si vous souhaitez créer un Playground, cliquez plutôt sur Create Playground (Créer un Playground).

Activer le mode de débogage

Cette étape facilite grandement le dépannage du code. Lorsque le mode de débogage est activé dans l’organisation, le code n’est pas compressé. Ainsi, les noms de variables restent les mêmes et la structure générale du code reste inchangée, ce qui facilite grandement le dépannage.

  1. Dans Setup (Configuration), saisissez Debug Mode (Mode de débogage) dans la zone Quick Find (Recherche rapide), puis sélectionnez Debug Mode (Mode de débogage).
  2. Cochez la case en regard de votre utilisateur.
  3. Cliquez sur Enable (Activer).

Récupérer les composants Web Lightning à partir de GitHub

  1. Suivez les instructions du référentiel GitHub readme.
  2. Dans Visual Studio Code, associez l’ensemble d’autorisations Bad Net Full Access (Accès complet à Bad Net) à l’utilisateur par défaut en exécutant la commande suivante dans le terminal.
    sf org assign permset --name Bad_Net_Full_Access

Votre environnement est maintenant prêt à effectuer un dépannage à l’aide de Chrome DevTools.

Démarrage avec un navigateur exempt de modifications

  1. Ouvrez un navigateur Chrome.
  2. Cliquez sur l’icône Customize and control Google Chrome (Personnaliser et contrôler Google Chrome) (), puis sélectionnez New Incognito Window (Nouvelle fenêtre de navigation privée). Cela garantit que Chrome fonctionne dans son état d’origine, sans extensions installées. Les extensions peuvent venir fausser vos mesures de performances.
  3. Ouvrez votre Trailhead Playground.
  4. Assurez-vous que le mode de débogage est activé pour votre utilisateur et que l’EPT s’affiche sous la bannière Debug Mode (Mode de débogage).
    EPT affiché dans la fenêtre du navigateur.
    Remarque

    Vous pouvez également afficher l’EPT en utilisant le suffixe d’URL suivant : ?eptVisible=1.

Dépannage d’un composant à réponse lente

  1. Depuis l’outil App Launcher (Lanceur d’application) () dans votre Trailhead Playground, cherchez et ouvrez Bad Network.
  2. Dans l’application Bad Network, cliquez sur 1 pour essayer d’augmenter le nombre plusieurs fois.
    L’incrémentation du nombre prend beaucoup trop de temps. Utilisons l’onglet Performance (Performances) de DevTools pour commencer le dépannage.
  3. Faites un clic droit sur la fenêtre du navigateur et sélectionnez Inspect (Inspecter), ou cliquez sur F12, pour ouvrir DevTools.
  4. Cliquez sur l’icône Customize and control DevTools (Personnaliser et contrôler les Outils de développement) ( ) et sélectionnez le côté d’épinglage que vous souhaitez utiliser : Undock into separate window (Détacher dans une fenêtre distincte), Dock to left (Épingler à gauche), Dock to bottom (Épingler en bas) ou Dock to right (Épingler à droite). (Les images de ce module présentent DevTools détaché dans une fenêtre distincte.)

    Placer DevTools dans une fenêtre distincte vous donne un meilleur accès à toutes les données lors du dépannage.

  5. Dans le menu de DevTools, sélectionnez l’onglet Performance (Performances).
  6. Dans le menu Performance (Performances), cliquez sur l’icône Record (Enregistrer) () pour commencer à enregistrer un profil.
  7. Dans l’application Bad Network, cliquez sur 1 pour augmenter à nouveau le nombre.
    Attendez que le nombre soit mis à jour.
  8. Dans le volet Performance (Performances), cliquez sur Stop (Arrêter) pour mettre fin à l’enregistrement et laisser le volet compiler et afficher les données sur une chronologie.

Observation des données de performances

  1. Notez la longue ligne bleue dans le graphique chronologique NET (RÉSEAU) sous les graphiques FPS et CPU (Processeur).
  2. Développez la section Network (Réseau), à gauche. Remarquez l’appel aura commençant entre 2 000 ms et 2 500 ms, aligné avec la ligne bleue dans la section Network (Réseau) du graphique.
  3. Passez la souris sur l’appel aura pour afficher les informations relatives à la requête.
    La zone Network (Réseau) du volet Performance (Performances) affiche un appel aura de 2,9 secondes, mis en évidence par la souris.

    Notez l’horodatage (ici, 2,90 secondes) et le nom de la requête.

Le volet Performance (Performances) nous a permis d’avancer jusqu’à ce point, en nous présentant la demande réseau à exécution longue. Pour obtenir plus d’informations, nous allons utiliser le volet Network (Réseau).

Volet Network (Réseau)

Tout comme le volet Performance (Performances), le volet Network (Réseau) propose de nombreuses options d’analyse et de dépannage. Nous n’en présenterons que quelques-unes ici. Pour en savoir plus sur ce qu’offre le volet Network (Réseau), consultez la section Ressources.

Network Log (Journal réseau)

Le volet Network (Réseau) enregistre toute activité réseau dans le Network Log (Journal réseau).

Le panneau Network (Réseau) correspondant à la description qui suit


Chaque ligne du Network Log (Journal réseau) représente une ressource. Par défaut, les ressources sont classées chronologiquement de la première à la dernière. DevTools enregistre l’activité du réseau uniquement lorsqu’il est ouvert.

Chaque colonne contient des informations sur une ressource.

  • Nom : cliquer sur le nom de la ressource permet d’afficher des informations la concernant
  • État : code de réponse HTTP
  • Type : Le type de la ressource
  • Initiator (Initiateur) : ce qui a provoqué la demande de ressources
    Cliquer sur l’initiateur ouvre le code source correspondant.
  • Date et heure : temps nécessaire à l’exécution de la requête
  • Waterfall (Cascade) : graphique des différentes étapes de la demande
    Survoler le graphique affiche les détails de la demande.
Remarque

Faites un clic droit sur les colonnes pour en ajouter ou en supprimer. Il est utile d’afficher la colonne Method (Méthode).

Inspection des détails de la réponse

  1. Sélectionnez l’onglet Network (Réseau).
    Le volet Network (Réseau) affichant la chronologie et les champs Name (Nom), Status (État), Type, Initiator (Initiateur), Size (Taille), Time (Durée) et Waterfall (Cascade).

    Sélectionnez le filtre Fetch/XHR pour afficher uniquement les demandes XMLHttpRequest (XHR).

  2. Cliquez sur le nom de ressource aura.ApexAction.execute=1 pour ouvrir les détails de la ressource.
    Les détails de la ressource s’ouvrent en affichant l’onglet précédemment sélectionné.
  3. Cliquez sur l’onglet Response (Réponse) pour voir la réponse reçue du serveur.
    Le volet Network (Réseau) affiche les détails de la réponse, cette fois-ci au format JSON.

    La réponse peut se présenter sous différents formats. Ici, il s’agit d’une réponse JSON (JavaScriptObjectNotation) volumineuse.

  4. Cliquez sur l’onglet Timing (Délai) pour voir une décomposition de l’activité réseau.
    Volet Network (Réseau) se rapportant à la description qui suit.

    Notez la longue barre verte correspondant à Waiting for server response (En attente de la réponse du serveur). Elle représente le délai d’attente pour que le serveur réponde : il s’agit du temps s’écoulant entre la demande de page par le navigateur et la réception du premier octet d’information à partir du serveur. Ici, l’attente de la réponse du serveur est de 3,83 secondes.

  5. Cliquez sur l’onglet Iniator (Initiateur) pour afficher la pile d’appels de requête.
    DevTools filtre la vue initiale pour afficher uniquement les éléments (frames) les plus significatifs, tels que les appels les plus longs. Cliquez sur le lien Show more frames (Afficher plus de frames) pour afficher tous les éléments de la pile d’appels.

    En regardant la pile, nous pouvons voir que increaseNum a appelé longAsyncFetch dans le fichier example1_IncreaseNumber.js.
  6. Dans le volet Initiator (Initiateur), cliquez sur le lien example1_IncreaseNumber.js pour ouvrir le fichier example1_IncreaseNumber.js dans le volet Sources.
    DevTools avec le volet Sources ouvert affichant le fichier example1_IncreaseNumber.js.
    Remarque

    Les numéros de ligne font référence à ceux figurant dans les captures d’écran. Il se peut que votre code soit compilé avec des numéros de ligne différents.

    Les durées mises en surbrillance dans la colonne du numéro de ligne de code représentent uniquement le temps nécessaire au navigateur pour répondre à l’appel, et non la durée de l’appel. Vous devrez peut-être faire défiler la fenêtre de code pour afficher la méthode async longAsyncFetch.

    À la ligne 84, la méthode increaseNum(event) appelle longAsyncFetch() avec un opérateur await. Cela oblige le JavaScript à attendre la réponse longue. De même, dans la méthode longAsyncFetch(), un appel est effectué à la méthode apex_generateJSONRecords_default en utilisant un opérateur await pour attendre la réponse avant de continuer.

Nous savons maintenant que la raison pour laquelle l’incrémentation du nombre prend autant de temps est que l’un des opérateurs await (ou les deux) oblige(nt) le code à attendre une réponse. Nous devons soit supprimer l’opérateur await pour que le processus puisse s’exécuter en arrière-plan, soit modifier le code Apex pour qu’il s’exécute plus rapidement.

Dans le module suivant, nous examinerons un problème de mémoire du navigateur côté client.

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