Performance optimization

  • 8 minutes

To determine how to optimize your app's performance, let's first cover what happens when your app starts. Then we'll discuss some common sources of slow performance.

App execution phases and data call flow

Before your user even begins to interact with your app, there are some phases of execution that the app goes through. After that, your app conducts a data call flow that varies depending on the data source.

Execution phases in canvas apps

Canvas apps progress through the following execution phases before showing the interface to a user:

  1. Authenticate the user: prompts first-time users to sign in with their credentials for the app's connection. Depending on the organization's security policies, the same user may be prompted again whenever they reopen the app.
  2. Get metadata: retrieves metadata (such as the Power Apps platform version the app runs and the app's data sources).
  3. Initialize the app: performs the tasks in the app's OnStart property.
  4. Render the screens: renders the first screen of the app, including the controls and data. The app goes through the same process to render any subsequent screens the user opens.

Data call flows in canvas apps

OData protocol is used to send and receive data for canvas apps data calls. For most data sources, the data call goes from the app to Azure API management, from API management to the data source, and then back to the app through the same steps in reverse order. If there's an on-premises data source (such as SQL server), then the call must also proceed through the on-premises data gateway. All of these call flow gates can impact performance and offer potential opportunities for optimization.

Using Microsoft Dataverse as the data source significantly changes the data call flow. When your data call goes to Dataverse, the OData request goes directly to Dataverse without going through Azure API Management, connectors, or data gateways. In other words, there are fewer gates to get through when you're using Dataverse.

Common sources of slow performance for canvas apps

Now that you have a basic understanding of execution phases and flow of data calls, let's cover some of the most common sources of poor performance in canvas apps.

App design

App design is a broad area because there are many ways that an app can be designed. However, some design aspects that can affect app performance include:

  • The app is client-heavy meaning it gets large sets of data into data collections, initially. Then it uses the data (maybe many times) in functions that process on the client's device, like JSON, Sort, AddColumns, and GroupBy.
  • The app has a long formula in OnStart where it triggers many data calls for other screens, and these data calls return large data records.

You can review app design as a possible source of slow app performance using Monitor. Check which data calls are taking a long time and how many data calls are in the app.

Also, try to balance the workload between the client and server. Delegate workload to the server whenever possible. It's important to make the client app lightweight in terms of client memory consumption.

Bottleneck in the data source

There are many possible causes of bottlenecks in the data source. But the most common is that tables in the data source are at the center of activity, when many (transactional or non-transactional) queries are directed to the same table or record from different users.

OData calls might slow down if:

  • The back-end machine hosting the data source is low on resources.
  • The back-end SQL instance has blockings, deadlocks, or resource contention.
  • The on-premises data gateway is unhealthy.

When these problems occur, tune the back-end data source to avoid slowing the app's performance.

Client browsers, devices, and locations

Canvas apps can be used on different devices and browsers and in different locations with varying network conditions. Encourage your users to use modern, updated, and supported browsers.

Geographical location of the on-premises data gateway and environment

Users can access canvas apps globally. We recommend that you locate the data source near your largest user base. For example, when your app accesses your on-premises data source, the location of on-premises data gateway should be close to the data source to minimize any extra overhead between the data gateway and the data source.

Temporary throttling of high-volume requests at the back end

Depending its design, a canvas app may generate many data calls within a short time. When data calls exceed a connector's throttling limits, the app is temporarily throttled. So choosing the right data source and connector is important from many perspectives, and it's important to understand connector-specific limits. You can check the documentation on connectors to learn about any limitations they may have.

Debug published app setting enabled

Enabling the setting Debug published app will cause your apps to perform more slowly. You can republish your app with this setting disabled as soon as you determine that you no longer need to view source expressions while debugging your published app.

To summarize, we've now discussed what happens when a user begins using the app for the execution phases and the data call flow. We've also covered some of the common ways that your app performance can be degraded. Though we won't cover any more in this unit, you can learn about practical tips and best practices to improve performance of canvas apps and considerations for optimized performance in Power Apps.