Power Apps canvas app performance tuning

Power Apps canvas apps are easy to build but easy to build slowly. A handful of patterns separate apps that feel snappy from apps that take 10 seconds to load and 3 seconds to respond to every tap. Performance tuning is a craft, not a mystery.

Causes of slow apps

A non-exhaustive list of the usual suspects:

Too many data fetches at startup

Apps with many OnVisible calls to data sources, or many controls each fetching their own data, take long to render. Worst case: an app that opens with 15 simultaneous SharePoint list queries.

Fix: load common data once into a collection at app start (OnStart), reference the collection from controls. Update the collection when needed.

Non-delegable queries on large data sources

A Filter() against a 100,000-row data source that isn't delegable returns only the first 500 rows. Beyond performance, this is a correctness bug — but it also creates slow client-side processing on the partial result.

Fix: use delegable operators (=, <, >, StartsWith, etc. — the editor warns when delegation breaks). Restructure logic to push filters server-side.

Heavy logic in control properties

Complex expressions in Items, Visible, Text properties recalculate frequently. If a label's Text does a LookUp over 50,000 rows on every render, the app feels sluggish.

Fix: precompute values into context variables or collections. Reference the variables in control properties.

Image-heavy galleries

A gallery of 200 customer records each with a profile image fetched at gallery load is slow — 200 HTTP requests just to render.

Fix: paginate, use a smaller image dimension, lazy-load images, or use blob references rather than embedded images.

`OnStart` is bloated

A long OnStart makes the app slow to open. Users see a blank screen until OnStart completes.

Fix: move non-essential setup to OnVisible of screens that need it. Use Concurrent() to parallelise independent operations. Defer heavy operations until after the first screen is visible.

Connections without caching

Each call to a connector goes over the network. For data that doesn't change often, cache it locally rather than refetching.

Fix: load into a collection on OnStart (or first use); refresh only when necessary.

Tools

The Power Apps Monitor tool — accessible from the app's Advanced menu — records every action in the app at runtime, with timing and source attribution. Pin Monitor on a second window, do an action in the app, see what fired and how long it took. Almost every performance investigation starts here.

The `Concurrent()` function

For independent operations at startup, Concurrent() runs them in parallel:

Concurrent(
  ClearCollect(colCustomers, Customers),
  ClearCollect(colProducts, Products),
  ClearCollect(colOrders, Orders)
)

Without Concurrent, they run sequentially. With it, they run in parallel — 3x faster for three independent data loads.

Best practices summary

Load shared data once, into collections, on OnStart or first use.
Verify delegation — fix any non-delegable warnings.
Keep control properties simple — precompute, don't recompute.
Minimise OnStart — first-screen visibility before everything else.
Paginate galleries — gallery with 5,000 records is slow no matter how good your data layer is.
Use Concurrent for parallel independent operations.
Measure with Monitor — guesswork is unreliable.

When to rebuild instead of tune

Some apps are slow because of architectural choices that no amount of tuning will fix:

Wrong data source — SharePoint list with 200,000 items where Dataverse would be appropriate.
Overly complex single-screen design — too many controls, too much logic.
Should be a model-driven app — for many-table CRUD scenarios, canvas isn't the right tool.

If tuning yields marginal improvements after honest effort, consider whether you're optimising the wrong shape.

For most canvas apps that feel slow, applying the patterns above takes them from "annoyingly sluggish" to "responsive enough." The hard part is having the discipline to measure rather than guess.