Partager via

Optimisez le chargement de l’application ou de la page pour des performances optimales

  • Article

L’un des facteurs clés qui façonnent la perception qu’a un utilisateur d’une application est la rapidité avec laquelle elle s’ouvre et devient fonctionnelle. Par conséquent, donner la priorité à cet objectif est crucial pour créer une application performante. Pour obtenir des performances optimales des applications, trois domaines principaux nécessitent une attention particulière :

  1. Charger les données rapidement
  2. Calculs efficaces
  3. Minimiser les ressources requises

Chacun de ces domaines a plusieurs anti-modèles communs.

Charger les données rapidement

Suivez ces directives pour obtenir des applications de chargement de données rapides.

Évitez de remplir directement une collection avec de grandes quantités de données

Parfois, les auteurs utilisent ClearCollect() pour copier des données d’un serveur vers une collection de leur application. Cette pratique constitue une solution de contournement aux limitations de délégation dans la source ou au fait qu’ils envisagent d’utiliser des collections dans l’application à d’autres fins. L’utilisation de ClearCollect() peut potentiellement augmenter la vitesse de l’application lorsque la collection est utilisée ultérieurement. Cependant, il est important de faire preuve de prudence lors de sa mise en œuvre. Utiliser ClearCollect de cette manière peut entraîner des temps de chargement des applications plus lents ou lors de la navigation entre les pages. ClearCollect() doit se terminer avant que vous puissiez voir les données dans une galerie ou un tableau. Cette étape peut prendre beaucoup de temps s’il y a beaucoup de données ou si vous utilisez cette approche pour trop de sources de données. Les collections sont mieux utilisées dans les situations où les données sont petites et où vous devez effectuer de nombreux calculs sur la collection. Par exemple, un panier de commande en ligne constitue une bonne utilisation des collections. Le client peut mettre à jour et supprimer des articles plusieurs fois avant de choisir de valider la commande. De plus, vous pouvez augmenter la collection avec davantage d’éléments de données, tels que des remises potentielles, des faits saillants, etc. Les données en « lecture seule » doivent être accessibles de manière native, sans les intégrer dans une collection.

Pensez à éviter d’appeler Power Automate pour remplir une collection

Ce problème est une légère variation de la section précédente. Parfois, les auteurs utilisent également Power Automate pour alimenter leur collection dans Power Apps. Il y a un coût de performance d’environ 0,6 seconde pour instancier Power Automate. Power Automate doit être lancé indépendamment à chaque appel. Il doit allouer de la mémoire, se situer avec les bons composants et être prêt à fonctionner. Comme pour les conseils ci-dessus, un ou deux appels à Power Automate peuvent ne pas poser de problème en fonction de votre application. Mais, presque universellement, les applications les moins performantes abusent de cette approche. Le coût des performances peut s’accumuler rapidement et ruiner les performances de votre application.

Évitez d’utiliser SaveData() et LoadData() comme scénario entièrement hors ligne

Certains auteurs utilisent ClearCollect() puis SaveData() pour stocker des données à des fins générales d’utilisation hors ligne. Vous pouvez utiliser SaveData() pour enregistrer la collection sur votre appareil et LoadData() pour la charger lorsque vous êtes hors ligne. Toutefois, cette approche n’est pas recommandée dans les cas où il existe une grande quantité de données ou si les données sont complexes. Cela ralentit votre application car elle doit attendre la fin de ClearCollect() avant de pouvoir afficher les données. Vous ne devez utiliser SaveData() et LoadData() que pour des scénarios de données petits et simples tels que les préférences et les listes restreintes. Une meilleure façon de travailler avec de grandes quantités de données hors ligne consiste à utiliser la fonctionnalité Power Apps hors ligne qui fonctionne avec Dataverse. Cette fonctionnalité peut gérer plus efficacement des données plus volumineuses et plus complexes.

Utiliser la sélection explicite de colonnes

La sélection explicite de colonnes est activée par défaut. Cependant, certains créateurs désactivent cette fonctionnalité. Le problème est que lorsque la sélection explicite de colonnes (ECS) est activée, les colonnes ne sont pas parfois récupérées de la source de données si les données sont d’abord récupérées dans une collection. Comme certaines tables peuvent avoir de nombreuses colonnes, ECS calcule automatiquement les colonnes à récupérer en fonction de leur utilisation dans les contrôles (par exemple, les galeries et les formulaires). Comme certaines tables peuvent avoir plusieurs colonnes, la réduction de la taille du téléchargement peut accélérer les performances. Certains tables peuvent avoir une centaine de colonnes ou plus. Si votre application n’a besoin d’utiliser que 10 colonnes et que vous supprimez toutes les colonnes d’une table de 100 colonnes, vous supprimez dix fois plus de données que ce dont vous avez réellement besoin.

La plupart des problèmes surviennent lors de l’importation de données dans des collections. Si une colonne est explicitement référencée dans un contrôle, ECS fonctionne bien. En outre, ECS fonctionne généralement pour les collections. Cependant, la traçabilité des colonnes est parfois perdue lorsque les données passent par des collections et des variables. Ainsi, Power Apps peut perdre la trace de la colonne à récupérer. Pour résoudre ce problème, vous pouvez forcer Power Apps à « mémoriser » la colonne en utilisant la fonction ShowColumns. Par exemple :

    ClearCollect(
        MyColTable, 
        ShowColumns(Filter(BankAccounts, AcountNo = 32),
        "Col1", 
        "Col2", 
        "Col3")
    );

Où Col1, Col2 et Col3 sont les colonnes que vous prévoyez de récupérer de la source de données (par exemple, la source de données Account).

Vous pouvez également ajouter un contrôle masqué à votre formulaire qui fait référence à la colonne. Cela oblige Power Apps à « mémoriser » la colonne.

Calculs rapides

Les calculs rapides (ou efficaces) constituent un objectif de performance à part entière. Pour en savoir plus, consultez Calculs rapides (efficaces). Cependant, il existe certains anti-modèles courants qui peuvent également affecter la charge des applications et nous en discutons donc ici. Vous trouverez ci-dessous une liste d’optimisations que vous devriez considérer et qui pourraient affecter le lancement de l’application ou la navigation dans les pages.

Utiliser App.Formulas

Historiquement, de nombreux auteurs ont mis un grand nombre de calculs dans OnStart. Lorsque vous placez une expression dans OnStart, cela oblige Power Apps à exécuter cette expression précisément au démarrage de l’application et avant tout le reste. Cependant, avec l’introduction d’App.Formulas, vous pouvez laisser Power Apps décider quand exécuter une expression. Power Apps peut exécuter la formule juste à temps avant que cela ne soit nécessaire. Pour en savoir plus, consultez App.Formulas. Utilisez App.Formulas pour diviser votre formule en éléments que Power Apps peut organiser plus efficacement pour l’exécution.

Utiliser Concurrent

Utilisez la fonction Concurrent pour permettre aux formules d’être exécutées en même temps. Il est courant d’utiliser cette fonction pour remplir des collections car elle permet une exécution parallèle. Bien que cela puisse fournir quelques accélérations modestes, l’ajout de nombreuses sources de données peut entraîner des problèmes de synchronisation et de limitation.

Utiliser les performances améliorées pour les contrôles masqués

Lorsqu’il est activé par défaut dans toutes les nouvelles applications créées depuis décembre 2022, Power Apps n’affiche aucun contrôle qui n’est pas initialement visible.

Minimiser les ressources requises

Réduisez les ressources requises pour lancer votre application ou votre écran. Cet effort implique de définir ou de partitionner soigneusement les ressources dont votre application ou votre écran a besoin. Vous trouverez ci-dessous plusieurs approches pour vous aider.

Utilisez un écran de démarrage à faible dépendance et éliminez les écrans inutilisés.

Utilisez un premier écran peu dépendant tel qu’un message de bienvenue sur votre application. Créez un écran qui ne charge pas de galerie, de tableau ou de données de référence. Ceci gère la perception de la vitesse de l’utilisateur et permet à Power Fx de retarder correctement certains calculs. Si vous avez des écrans inutilisés, supprimez-les.

Maintenez les dépendances croisées entre les écrans à un niveau faible

Les références de pages croisées forcent le chargement de pages supplémentaires via des références, par exemple en référençant des contrôles sur des pages et en les plaçant dans des collections. Certaines références pourraient être inévitables. Centralisez si possible les références communes sur une seule page afin que seule la page soit chargée.

Pensez aux médias intégrés

Les auteurs intègrent parfois des médias dans leurs applications pour garantir un chargement rapide. Si vous avez un média intégré, déterminez si vous l’utilisez ou non. Si tel n’est pas le cas, supprimez-le. Si vous avez intégré un fichier .png, envisagez de le remplacer par un fichier .svg qui est plus petit. Notez que si vous utilisez un .svg, la police du .svg doit se trouver sur la machine client. Considérez la résolution multimédia intégrée. Est-elle trop élevée pour l’appareil sur lequel elle sera utilisée ?

N’oubliez pas App.StartScreen

Si vous utilisez App.StartScreen, assurez-vous que le premier écran est un écran vide. En raison du packaging actuel de l’application, le premier écran logique est toujours fourni avec la logique d’initialisation de l’application et sera initialisé, que nous y accédions ou non.

Pensez à diviser l’application

Si votre application est volumineuse, envisagez de la diviser en applications plus petites. Si les fonctionnalités sont suffisamment distinctes dans les différentes parties de votre application, cette approche peut fonctionner. Dans ce scénario, vous créez une application distincte réelle que vous lancez avec des paramètres qui incluent le contexte de la première application ou de l’application parent.

Suggestions

Pour atteindre l’objectif d’un démarrage rapide de l’application et de la page, considérez les questions et suggestions suivantes :

  1. Chargez-vous beaucoup de données dans un premier écran ? Pouvez-vous utiliser un premier écran différent ?
  2. Exécutez-vous de nombreuses commandes ou expressions Power Fx au début du chargement de l’application ? Pouvez-vous reporter ces commandes et expressions à un stade ultérieur de l’application ? Extrayez-vous uniquement les données dont vous avez vraiment besoin pour démarrer l’application ? 1 Pouvez-vous convertir des expressions dans App.OnStart en formules nommées avec App.Formulas ? Ceci permet à Power Fx de décider quand exécuter réellement la formule plutôt que de la forcer à se produire lors d’événements de chargement ou de navigation.
  3. Pouvez-vous utiliser un flux Power Automate pour créer une table temporaire dans un magasin de données local tel que Dataverse qui combine des données provenant de différentes sources ? Puis accédez-vous à ces données dans votre Power App ?
  4. Pour le lancement des processus métier, pouvez-vous utiliser des actions déclenchées par le serveur plutôt que d’appeler un flux Power Automate ?
  5. Pouvez-vous créer une vue sur le serveur qui joint les données pour vous ?
  6. Si vous souhaitez utiliser des données hors ligne dans votre application, pouvez-vous utiliser la fonctionnalité Power Apps hors ligne qui fonctionne avec Dataverse ? Si vos données ne sont pas dans Dataverse, pouvez-vous les y déplacer ?