The High Cost of Lag
Everyone’s seen it — that spinning wheel that just won’t quit. When your Power App drags, it’s not just annoying. It’s expensive. Slow apps kill productivity, drive users back to spreadsheets, and can quietly erode the return on your Power Platform investment.
In Power Apps, speed isn’t a “nice-to-have.” It’s architecture in motion. Every tap, filter, and data call depends on how efficiently your app moves data between the front end (the device) and the back end (your data sources like Dataverse, SharePoint, or SQL).
If your app is slow, it’s almost always because of one of two root causes:
- Data is being retrieved inefficiently.
- The client device is doing too much of the heavy lifting.
Let’s break down ten practical fixes — starting from big-picture data architecture all the way to screen design and maintenance — that can turn your Power App from sluggish to snappy.

1. Master Delegation or Risk Wrong Data
Delegation determines whether your app pushes operations like filtering and sorting to the server (good) or tries to do them locally on the user’s device (bad).
When Power Apps can’t delegate a function (for example, using Search() on a SharePoint list), it downloads only the first 500–2,000 records and filters them on the device. If your dataset has 10,000 rows, that means 80% of your data isn’t even being looked at — and your app could return the wrong results.
How to fix it:
- Watch for the blue underline in App Checker — it means a formula isn’t delegable.
- Swap out non-delegable functions. For example, StartsWith() is delegable and faster than Search().
- Use Dataverse views for complex filters. They process queries on the server before data ever hits your app.

2. Reduce Data Payloads with ShowColumns()
Even if delegation is working, Power Apps still might be pulling way more data than needed. By default, it grabs every column in a table, even if you only use two of them.
Better approach: Use ShowColumns() to fetch just what you need:
// Slow version
ClearCollect(colAccounts, Accounts);
// Faster version
ClearCollect(colAccounts, ShowColumns(
Filter(Accounts, !IsBlank(‘Address 1: City’)),
“name”, “address1_city”
));
Less data = less load = happier users.

3. Pick the Right Data Source
If you’re still using SharePoint for large or complex apps, it’s probably time to graduate. SharePoint is great for lists and light collaboration but hits a wall fast — delegation limits, the 5,000-item threshold, and general sluggishness with scale.
Dataverse is built for performance. It’s faster, handles relational data natively, and supports full delegation. For enterprise-scale apps, Dataverse (or SQL Server) will outperform SharePoint every time — though it does require more upfront setup and security management.

4. Cache Small Data, but Don’t Hoard It
Caching (using ClearCollect() to store small datasets locally) can make apps feel instant. But if you collect too much data, your app will balloon in memory and eventually crash.
Rule of thumb:
- Cache small, frequently reused data (like configuration values or user profiles).
- Avoid caching large lists or tables. Let delegation handle those.
- Always pair caching with ShowColumns() to reduce payload size.

5. Stop Overloading App.OnStart
Everything in App.OnStart runs before your app’s first screen loads. If it’s packed with data loads or complex formulas, your app won’t even show a screen until all that finishes.
Fix: Move heavy initialization into OnVisible properties of individual screens. Load what you need just in time. That one shift can make an app feel twice as fast to open.

6. Load Data in Parallel with Concurrent()
By default, Power Fx runs operations one after another. That means if you’re loading three tables, you’re waiting for each to finish before starting the next.
Use the Concurrent() function to load them all at once:
Concurrent(
ClearCollect(colUsers, Users),
ClearCollect(colSettings, AppSettings),
ClearCollect(colProducts, Products)
);
This reduces startup time dramatically, especially on slow networks.

7. Eliminate Cross-Screen References
Referencing a control on another screen (e.g., ScreenB.TextInput1.Text from ScreenA) forces Power Apps to load both screens into memory — even if the second isn’t visible. That kills performance.
Fix: Store values in variables instead (Set(gblUserName, TextInput1.Text)) and reference those instead of controls across screens. You’ll get faster transitions and fewer random slowdowns.

8. Cut Down on Controls and Optimize Images
Every label, button, and icon adds rendering time. Screens overloaded with controls take longer to draw and lag more on mobile devices.
Quick wins:
- Use galleries instead of hundreds of individual labels or inputs.
- Split large screens into smaller, focused ones.
- Compress all images before uploading them — never upload raw high-res files.

9. Check Your Back-End, Not Just Your App
Sometimes, your app isn’t the problem — your data source is. SQL databases missing indexes, overloaded Dataverse environments, or slow on-prem gateways can all stall queries.
Work with your IT or database team to:
- Add or rebuild indexes.
- Schedule heavy data jobs during off-peak hours.
- Monitor gateway health if using on-prem connectors.
A well-tuned database often makes a bigger difference than any app-level tweak.

10. Use Power Apps Monitor Early and Often
If you’re not using Power Apps Monitor, you’re guessing. Monitor shows you exactly what’s slowing down your app — every call, every query, every delay.
Use it to catch the “N+1” query problem (where one gallery query triggers dozens of follow-up calls). You’ll see exactly which formulas or components are chewing up load time, letting you fix them before users complain.

The Bottom Line
Power Apps performance problems rarely come from one bug — they come from design habits. The good news? They’re all fixable.
Focus on three fundamentals:
- Keep data operations server-side (delegation).
- Limit what you pull into the app (payload and memory).
- Design with simplicity — fewer controls, fewer moving parts.
Build with performance in mind from day one, and your users will never have to see that spinning wheel again.