Here are the tips I use to optimise Power Apps performance.  Because Power Apps is so flexible and often has several ways of achieving the same result, I know from experience that it’s easy to inadvertantly slip into bad coding practice or even use the wrong tool for the job.  One of my early apps reformatted a couple of hundred text strings to write to a Data Source.  The output was spot on, but using on a mobile was so slow!  No problem I thought, I’ll run it on a PC, but it was hardly any faster.  The issue wasn’t the hardware, it was the fact that Power Apps just isn’t designed for number crunching (or text crunching) on that scale

That was a valuable lesson to learn – and since then I’ve learned quite a few more do’s and don’ts and other ways to optimise Power Apps performace.  The important points are summarised below

Optimise Power Apps Performance

Don’t worry unduly about making an App performant right from the start of the build.  Many apps will work just fine as they are, but complex apps need more thinking through.  The best piece of advice I can give is don’t try and memorise everything below, just go ahead and build your app and learn from the experience.  If you notice performance issues or want to make certain your app is performing at its best, then check how individual commands respond by using the Power Apps Monitor or Google Developer Tools. Then you can dive in and fix anything that is dragging its feet, performance wise

I’ve categorised everything into sections starting with the greatest impact, Data Sources.  If you have any more tips then please let me know!

Optimise Power Apps Performance

Data Sources

  • Where data rarely changes or if data is accessed by a single user, then load the data from the Data Source into a Collection.  The App can make changes to the local Collection, rather than working with the network Data Source direct.  Once complete, the changes to the Collection can be written to the Data Source in the background.  Saving data to a Collection is a great way to avoid frequent time consuming Filter or Lookup requests.  With mutiple users and data that frequently changes, data integrity may trump performance so accessing the Data Source directly may be the only viable option
  • Limit your use of the Refresh function to situations where it is really needed.  For example, if a Form is used to submit a new record to a Data Source displayed in a Gallery, once the new Record is added to the Data Source then the Gallery is automatically refreshed.  There is no need to do this manually a second time
  • There is often no need to load a full dataset.  Use the DropColumns function to just load the columns actually needed
  • Avoid loading all network Data Sources using App OnStart as all data will be loaded at once.  This is unlikely to be necessary and will slow the App loading as OnStart requires all the data to load successfully before the App runs.  Instead consider using the OnVisible property of the particular screen requiring the data.  This spreads the overall data load across all the screens.  Though bear in mind that using OnVisible has the downside that the data will be re-loaded every time your user leaves and returns to the screen
  • If possible, pre-load data before it is required.  For example, load data in the background once the user has already started using the app but before the user requires access to the data
  • If multiple Data Sources have to be loaded at the same time, use the Concurrent function so the data from all sources is loaded in parallel rather than sequentially
  • Use functions that delegate to the data source.  As well as ensuring you get the correct data, this is also way more efficient that loading all the records and then invoking the functions locally in Power Apps
  • If there is static data that doesn’t change, it can be hard coded into the app, though this practice is not ideal.  Better to save locally on the device and build the capability into the App to refresh the data periodically. Bear in mind though that saving data locally using the SaveData and LoadData functions only works on devices running Andriod and IOS
  • If Dataverse is your Data Source, using server-side functions such as Business Rules, Calculated Fields and Rolled-Up Fields is significantly faster than loading the data and doing the equivalent calculations on the client device.  This one of the many benefits of using Dataverse as a Data Source
  • Consider the locations of the user base when defining the Azure region to host your app.  Avoid sending your users half way around the world to access their data!
  • Although most Data Sources are located in the cloud, sometimes it’s necessary to use on-premise data.  Where this is the case, accessing the data requires the Microsoft On-Premise Gateway.  Installing the Gateway and accessing the on-premise data can present a number of challenges that are often outside the control of the Power App builder.  Consult the local technical teams who will be in the best position to advise and help with the following:
    1. Installing and configuring the Gateway
    2. Optimising the data source to serve the needs of the Power Apps users and the other users in the wider enterprise
    3. Ensuring the network bandwidth between the Data Source and the On-Premise Gateway is sufficent to avoid being a bottleneck
    4. Ensuring the bandwidth to the Internet is sufficient for the volume of data required for the App
    5. Firewall configurations are fully optimised

Good Coding Practice

  • Power Apps isn’t designed for complex data manipulation or calculations.  This is particularly noticable when running complex formulas, particularly on a phone or tablet.  Much better to use a Power Automate Flow and access the processing power of the Microsoft Cloud.  Set a scheduled, automated or instant Cloud Flow instead.  Alternatively, the server side capabilities of Dataverse can also be employed for this purpose
  • Updating large datasets is also problematic.  Limit the use of the ForAll funcition to when it is strictly needed.  It works fine but can be painfully slow for complex changes.  Poor use of the ForAll function is a primary cause of slow running Apps
  • Avoid building Apps with many screens.  Instead consider building more than one App built on the same Data Source.  A seperate App can be deployed for different user personas.  This also has the advantage or reducing complexity so new functionality can be more easily introduced.  As a guide, if an App has more than ten screens then it’s a candidate to seperate out into more than one App
  • Watch out for screen dependencies.  If you have a screen that is dependant on a formula on another screen, then the first screen will have to load in the background and action the formula before the second screen can complete
  • Don’t run the same formula for many controls.  Calculate once and save as a variable.  Alternatively, the Parent property can often be used to quickly access the reference data you require
  • Rather than create lots of controls that do the same thing, use a single Component and reuse it throughout the App
  • Component displays can also be displayed while individual screens are loading. This won’t speed the load up but will improve the user experience

Images

  • If large images are used in the App,  consider creating a second image file of reduced size.  The lower quality image can be loaded first and then the higher resolution image can be overlaid above the initial image once it has been loaded into the App
  • Generally speaking, the use of PNG images are the most optimal, so use these where possible
  • Images can be stored in many locations including SharePoint and Azure SQL, but for larger images, Azure BLOb Store is the quickest to serve and load
  • Bear in mind that images can be pre-loaded and hidden on a screen or Gallery. They can then be very quickly made visible when required
  • Use SVGs instead of images where possible.  Learn more about using SVGs in Power Apps

Preview Features

  • Explicit Column Selection is a preview feature that works with Dataverse and SQL Server. It enforces downloading of just the columns that are required for the app to run and not the whole dataset
  • Delayed Load is also a preview feature.  When this is switched on, data is only loaded when needed for an individual screen.  However, when this is switched on, avoid unnecessary dependencies between screens as this negates the benefits of this feature

Further Reading & References

Power Apps Reference: Optomize Performance in Power Apps

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top