Power Apps performance tuning

A Power App that takes 30 seconds to open and 5 seconds per screen transition gets ignored by users. Performance is the difference between adoption and shelfware. The patterns to make canvas apps and model-driven apps fast are well-known but not obvious to first-time makers.

Canvas app performance.

1. Reduce startup time. Canvas apps run a substantial OnStart sequence loading data, setting variables, initialising. Minimise the OnStart work:

• Move non-critical initialisation to OnVisible of the first screen (deferred until needed).
• Concurrent() function to run multiple operations in parallel rather than sequence.
• Cache only what's needed for the first screen; load deeper data lazily.
• Avoid huge collections on startup; load on demand.

A well-tuned canvas app opens in 2-3 seconds; a poorly-tuned one takes 15-30.

2. Minimise data fetched. Every Dataverse / SharePoint / SQL call has latency. Reduce:

• Use Filter() with proper delegable filters to push work to the server.
• Select specific columns with ShowColumns() rather than fetching all.
• Avoid LookUp() in galleries — it queries per row, devastating for large galleries.
• Page large lists; don't load 10,000 records on screen load.

3. Delegation. Functions like Filter(), Sort(), Lookup(), Search() are delegable — they run server-side on the data source. Non-delegable functions force client-side processing limited to ~2000 rows. The maker portal warns about non-delegable expressions; address them:

• Replace non-delegable string operations with delegable equivalents.
• Move complex calculations to Dataverse formula columns or rollup columns.
• Refactor formulas to be delegable.

4. Limit gallery work. Each gallery item evaluates its formulas. A gallery of 100 items with complex formulas in each item evaluates 100 times the work:

• Hoist computations out of the gallery to a single Pre-computed variable.
• Use With() to compute once and reference repeatedly.
• Limit visible items; lazy-load on scroll.
• Pre-compute formatted strings rather than computing inline.

5. Image optimisation. Images can dominate app load:

• Resize images to display size before uploading; don't load 5MB photos to display as thumbnails.
• Use SVG for icons (small, scalable).
• Lazy-load images that aren't immediately visible.

6. Avoid heavy controls. Some controls (PDF Viewer, deeply-nested containers, large data tables) are heavyweight. Use them sparingly; consider lighter alternatives.

Model-driven app performance.

Model-driven apps are mostly platform-rendered; tuning is different from canvas.

1. Form load time. Each form's load triggers:

• Data fetch for the record.
• Related-record fetches for subgrids, quick views, lookups.
• JavaScript handler execution.
• Business rule evaluation.

Tune by:

• Limit subgrids on the form — 5–10 is typical; more slows load.
• Defer non-critical data — use the Default state properties to load tabs lazily.
• Avoid JavaScript async calls in OnLoad — they block the form render.
• Limit business rules — many overlapping rules slow evaluation.

2. View performance. Lists that load slowly:

• Index the columns used in default filters and sorts.
• Limit columns shown — fewer columns = faster query.
• Limit default rows — don't show 10,000 rows by default; let users filter to a manageable subset.

3. Search performance. Quick Find and Advanced Find:

• Quick Find indexes only configured columns; verify the relevant ones are configured.
• Dataverse Search (the modern global search) is generally faster than Quick Find for cross-table search.

4. Plug-in performance. Plug-ins synchronous to record operations add latency:

• Profile plug-in execution; long-running plug-ins block users.
• Use asynchronous plug-ins for non-critical work.
• Cache lookups within a plug-in execution.

General principles.

• Profile before optimising. Browser dev tools (Network tab), the Power Platform admin centre's analytics, and Application Insights tell you where time is actually spent. Optimise the slow parts, not what you imagine to be slow.
• Test with real data. A 50-record dev environment performs differently from a 5-million-record production. Validate at scale.
• Test on representative devices. Mobile, low-bandwidth, older browsers — the app needs to be usable for all users, not just admins on fast desktops.
• Set performance budgets. "Form must load in under 3 seconds at p95." Measure; fail the budget = refactor.

Telemetry. App Insights configured at the app level captures user interactions and timings. Build dashboards showing:

• Page load times per app per screen.
• Action durations.
• Error rates.
• User counts per app.

The data drives prioritisation — optimise the screens users actually use.

Common pitfalls.

• OnStart bloat — accumulating initialisation logic; app start time grows linearly.
• Non-delegable warnings ignored — the app works in dev with 100 records; production with 100,000 hits the 2000-row delegation cap and is silently wrong.
• Subgrid proliferation — every form has 15 subgrids "in case someone needs them"; loading is glacial.
• Custom HTML web resources doing heavy DOM work; degrade form responsiveness.

Operational reality. Performance is a continuous discipline. Schedule periodic performance reviews; tune as data volume grows; budget refactoring time as part of operations.