Power Apps Performance Issues - Common Problems and How to Fix Them

If you're reading this, your Power App is slow. Probably it was fine when you built it and now it isn't. Probably users have started complaining. Probably someone on the leadership team has muttered something about "rebuilding it in proper code." Let's see if we can avoid that.

We get called in to fix slow Power Apps about twice a month. Most of the time the problems are the same five or six issues. Most of the time they're fixable without a rebuild. Sometimes they aren't, and we'll be honest about when that's the case.

This post is the field guide we'd hand someone who has a working app that has degraded over time, or a new app that never quite hit the performance the business expected. If you're earlier in the process and trying to choose a platform, our Power Apps consultants page covers when Power Apps is the right fit and when it isn't.

How to know whether the problem is really Power Apps

Before changing anything, find out where the slowness lives. We've seen teams spend weeks optimising formulas when the actual problem was the Dataverse environment, the SharePoint list size, or a flaky on-premises data gateway.

Open Monitor in the maker portal while a user reproduces the issue. Look at the timeline. Slow screen navigation is usually formula or rendering. Slow data loads are usually data source issues or delegation problems. Slow save operations are usually patch logic or downstream Power Automate flows running synchronously when they should be running in the background.

If Monitor shows network calls taking three or four seconds individually, the app isn't the problem. The data source is. Fixing the formulas won't help. We had one client convinced their canvas app was the issue. Turned out their SharePoint list had grown to 380,000 items with no indexed columns. The app was fine. The data architecture wasn't.

Problem one - delegation that silently fails

Delegation is the single biggest cause of slow Power Apps that we see. If a function isn't delegable for your data source, Power Apps pulls a maximum of 500 or 2,000 records (depending on your setting) into the app and processes them locally. Your filter, your search, your sort, all running on the client across whatever subset of data made it across.

This works fine with a hundred records. At ten thousand records it falls apart. At a hundred thousand records the app is basically broken even though it doesn't throw an error.

The fix is to identify every non-delegable warning in Power Apps Studio. Those little blue squiggles aren't suggestions. They're warnings that your app will get slower as your data grows. Common culprits include:

• Search() on SharePoint columns that aren't indexed
• Filter() with combined conditions like StartsWith() or nested logic on Dataverse
• CountRows() on large tables (use CountIf() server-side or pre-aggregated values)
• Sort() on calculated or unindexed columns

The shift from non-delegable to delegable usually means restructuring the formula. Sometimes it means adding indexes to your SharePoint columns. Sometimes it means moving the data to Dataverse, where delegation is broader and more predictable. Sometimes it means giving up on doing the work in Power Apps at all and pushing it into a Power Automate flow or a stored procedure.

Problem two - galleries doing too much work

Galleries are where performance problems become visible because users see them scrolling. They're also where most apps waste compute.

The classic mistake is putting Lookup() or Filter() calls inside gallery item templates. Every row in the gallery triggers a call. With 50 visible rows, that's 50 calls every time the gallery refreshes. With virtualisation off, it's a call for every row in the underlying data, regardless of whether the row is visible.

The fix is to denormalise the data at load time. Pull the lookup data into a collection at startup, then reference the collection inside the gallery. Yes, this means more code on App.OnStart. Yes, it means thinking about when collections refresh. It's still worth it.

A few other gallery patterns worth checking:

• Image controls pointing at remote URLs render slowly on scroll. Either pre-cache the images or use base64 stored locally if the count is small.
• Conditional formatting in gallery rows using complex If() statements gets re-evaluated on every scroll. Move the calculation into a column on the underlying collection so it's computed once.
• Nested galleries are expensive. If you have a parent-child layout, consider a master-detail screen pattern instead.

We had a client whose gallery scrolling went from juddery to smooth just by moving a single lookup out of the item template and into a pre-loaded collection. Three lines of code. The user complaints stopped that week.

Problem three - App.OnStart that won't end

App.OnStart is where many apps go to die. Every collection, every lookup, every "set this variable from that source" gets dumped in there until launching the app takes fifteen seconds and users start clicking around before it's finished loading.

A few rules we follow:

• Move anything that isn't needed on the first screen into OnVisible for the screen that actually uses it
• Run independent collections concurrently using Concurrent() rather than sequentially
• Switch the modern App.StartScreen behaviour on so you can route users straight to where they need to go
• Cache reference data (lookup tables, dropdown options) into collections once per session, not on every screen visit

If your app still takes more than three or four seconds to be usable after these changes, the problem is probably the data sources, not the app structure.

Problem four - the data source is wrong for the workload

Sometimes the fix isn't formulas, it's architecture. The data source you chose at the start might not be the right one for where the app has gone.

Data source	Works well for	Falls down at
SharePoint Lists	Under 5,000 records, simple read/write, document attachments	Complex relationships, high write volume, delegation gaps
Dataverse	Most business apps with relational data, security model, audit trail	High write throughput edge cases, very large historical tables
SQL via gateway	Existing on-prem data, large transactional tables	Gateway reliability, latency over long links
SQL Azure	High volume, complex queries, analytical workloads	Cost at scale if not managed
Custom connectors	Anything not in the standard list	Maintenance burden, throttling on the upstream API

The classic upgrade path is SharePoint to Dataverse when a list grows past around 20,000 records or when you start needing real relational structure. The migration isn't trivial. You're rebuilding forms, retesting flows, and probably re-permissioning everything. But it's almost always cheaper than fighting SharePoint at the wrong scale.

Dataverse pricing in AUD is the bit that surprises people. Per-app plans start around fifteen dollars per user per month at list price. Per-user plans run around thirty dollars per user per month. Storage is metered separately at around seven dollars per gigabyte per month, with file and log storage at lower rates. If you have 500 users and 50GB of data, the monthly bill works out around eighteen thousand dollars plus storage. That's not a small line item, and it needs to be in the business case before you migrate.

Problem five - Power Automate flows blocking the UI

Patching a record and waiting for a flow to finish is one of the more common reasons apps feel slow even when the app itself is fast. The Patch() returns quickly. The flow runs after, doing whatever post-processing the business wanted. If the app is waiting on the flow before continuing, users feel every second of the flow execution.

The fix is usually to fire the flow asynchronously, return the user to whatever they were doing, and handle the result via notification when it completes. Most flows that block the UI don't need to. Some do (where the result of the flow drives the next screen) but those should be the exception.

A related issue is flows that grew over time. The flow that started as "send a notification email" now has nine branches, three approval steps and a Dataverse update at the end. We've seen flows take 45 seconds to run that the app is waiting on. If a flow is doing real work, the app shouldn't be waiting synchronously.

Problem six - container layouts and modern controls

If your app was built before late 2024 and is still using the absolute positioning model, you're paying a performance cost on resize and orientation changes that you don't need to pay. Container-based layouts using horizontal and vertical containers render faster, scale better, and are less expensive on screen transitions.

Migrating an existing app to containers is a chunk of work. If the app is otherwise healthy, it might not be worth doing. If the app is slow and you're already rebuilding screens, do it as part of the same project.

The modern controls (the rebuilt suite Microsoft has been rolling out) generally render faster than the classic ones for the same job. Where they're available and feature-complete for your use case, switch.

When your app has outgrown Power Apps

We have to say this, because not every slow Power App is fixable.

Power Apps is a low-code platform with a defined performance envelope. If your app has fifty screens, complex offline requirements, three thousand concurrent users, sophisticated calculations that can't be pushed to the server, or a UX that needs precise interaction control, you might have outgrown the platform. We've worked on apps that were rebuilt in React or as .NET applications and the rebuild was the right call. They became faster, cheaper to run, and easier to evolve.

The signs that this conversation is on the table:

• The app has more than 25 screens
• App.OnStart is unavoidably long because the data model is genuinely complex
• You're hitting Dataverse storage costs north of three thousand dollars a month and the data is still growing
• You've spent more than three hundred thousand dollars in licence and consulting fees on optimisation in the last twelve months
• The performance still isn't acceptable after a proper optimisation pass

If two or three of these are true, get a second opinion before you spend more on tuning. Sometimes the answer is a hybrid (Power Apps for the admin side, custom code for the customer-facing side) rather than a full rebuild.

A realistic cost guide for fixing performance

If you're bringing in outside help, here are the ranges we see in the Australian market.

A targeted performance review on a small to medium app: around eight thousand to twenty thousand dollars depending on complexity. Output is usually a written report with prioritised fixes and effort estimates.

Implementing the recommended fixes: thirty to one hundred and twenty hours of consulting, so roughly six thousand to thirty thousand dollars at typical Sydney or Melbourne rates.

Migration from SharePoint to Dataverse: starts around twenty-five thousand for a simple app, climbs quickly with complexity. Six figures isn't unusual for apps with significant business logic, dozens of integrations, or strict cutover requirements.

A full rebuild on a different platform: anywhere from sixty thousand for a focused replacement to several hundred thousand for a strategic redesign.

These ranges are indicative. The actual numbers depend on data complexity, integration footprint, and how much the business processes have shifted since the original build.

Where to start tomorrow

If you only have a few hours, run Monitor against the slowest user journey and identify whether the time is being spent in network calls, formula evaluation, or rendering. Fix the worst one first. Then come back to the rest.

If you have a week, do a proper sweep: check every delegation warning, audit App.OnStart, profile the slowest gallery, and time-box the longest synchronous Power Automate flow. Most apps can claw back fifty to seventy per cent of their slowness through these four areas alone.

If you're looking at a serious rebuild or a Dataverse migration, talk to someone who has done the same migration recently. The platform changes constantly and what was true even a year ago isn't always true now. Our Power Apps team does both the targeted performance work and the strategic platform decisions, and our data and modernisation practice handles the data-layer side when SharePoint or legacy SQL is the actual bottleneck.

If you'd like a conversation about a specific app, get in touch. We'll usually do a free 30-minute scoping call to work out whether the problem is fixable in-place or whether it's bigger than that.