Canvas app performance

What it does

Canvas app performance work is mostly about three things: how much data you pull before the first screen is usable, how much calculation you force to happen up front, and how many resources the app has to fetch to start. Microsoft's own framing is load data fast, calculate efficiently, minimise required resources.

Key facts

App.Formulas (named formulas) lets Power Fx decide when to evaluate. OnStart forces everything to run at app start, before anything else. Named formulas are the documented alternative for the two main OnStart uses — caching data and setting globals.
If you use App.StartScreen, make the first screen in the Studio tree a blank one. The first logical screen is bundled with the app init logic and gets initialised whether or not you ever navigate to it.
There's roughly a 0.6-second cost to instantiate Power Automate from an app, paid on every call. A couple of calls is fine; a pattern of calling flows to fetch data is not.
Explicit column selection is on by default and works out which columns to retrieve based on control usage. Column lineage can be lost when data passes through collections and variables — force it back with ShowColumns.
Since December 2022, new apps don't render controls that aren't initially visible.
App preload is on by default and can be turned off.
Publishing repackages the app on the current platform version. An app that hasn't been published in months usually gets a free speed improvement from a republish alone.
Monitor in the maker portal reports Time to interactive and Time to full load for canvas apps at the 75th percentile, recalculated every 24 hours, alongside data request success rate and latency. Recommendations attached to those metrics only appear in Managed Environments.

When to use / skip

Do the performance work when the app is genuinely slow, and measure before you change anything — Monitor and the browser network tab will tell you whether you're waiting on data, on calculation, or on the client. Skip the micro-optimisation on a five-screen app over one SharePoint list; you'll spend a day to save 200ms nobody notices. The exception is OnStart: keep it thin from day one, because unpicking a hundred-line OnStart later is genuinely painful and it's the first thing to go wrong on every slow app you'll ever be handed.

Configuration decisions

Named formulas versus OnStart, decided at the start of the build.
Which data is read-only and should be queried natively, versus which is genuinely being edited in the app and earns a collection.
Whether the first screen is a low-dependency welcome or launch screen, or goes straight into a data-heavy list.
Whether a large app gets split into separate apps launched with parameters, or stays as one.
Whether Concurrent is used to parallelise start-up calls — it helps, but pile on enough data sources and you'll trade load time for throttling.
Whether offline needs are met with SaveData/LoadData (small, simple only) or with the Dataverse offline feature.

Gotchas

ClearCollect must complete before anything bound to that collection renders. This is the single biggest cause of slow app and slow screen transitions, and it's usually there as a workaround for a delegation warning.
Turning off explicit column selection to "fix" a missing column pulls every column of every table. On a hundred-column table that's ten times the payload you need.
Cross-screen references drag other screens into the load path. Centralise shared references on one screen if you can't remove them.
Embedded media is invisible in the tree until you go looking. Unused embedded images stay in the package.
SaveData/LoadData used as a general offline store makes the app slower, because it still has to build the collection first.

Consultant notes

Measure first and show the client the numbers. "The app feels slow" is not a defect you can close; "time to interactive was 9 seconds, now it's 3" is.
Republish every canvas app in the estate as a first, free intervention when you inherit a slow one. It costs an hour and sometimes solves the complaint outright.
Push back on flow-as-data-fetch patterns early. They're common in apps built by citizen makers and they're expensive per call, not just once.
If the client wants recommendations from Monitor, that needs Managed Environments — a licensing and governance conversation, not a toggle. Confirm the position before you promise the tooling.
Set a performance budget with the client in seconds-to-usable, not in vague adjectives, and test it on the slowest device in the estate.

Worth revisiting when the Monitor metrics change or when Microsoft ships the next batch of OnStart alternatives.