Das Wichtigste in Kürze
- Bevorzuge fokussierte Screens und ein Navigationsmodell statt eines Mega-Screens, der den ganzen Prozess besitzt.
- Plane zuerst für Delegation; behandle blaue Unterstreichungen als Architekturschuld, nicht als Rauschen im Editor.
- Stoppe N+1-Lookups in Galerien; lade vorab mit passend geformten Dataverse-Views und argumentiere mit Monitor-Traces.
- Leg Berechtigungslogik, Aggregation und Konsistenz in Dataverse; nutze Power Fx nur für die Interaktion.
- Plane ein Budget für gleichzeitiges Öffnen (viele Nutzer im selben Moment), nicht nur für den Kaltstart auf einem Laptop.
- Halte Identität, Dataverse-Berechtigungen und ALM-Paketierung im selben Gespräch.
Canvas ist wunderbar, bis ein einzelner Screen zu einem verteilten System wird: verschachtelte Galerien, Fan-out in OnStart und Geschäftsregeln in Power Fx, weil das schneller ging.
Microsofts eigene Referenzarchitekturen zur Performance geben eine klare Richtung vor. Verlagere schwere Arbeit Richtung Dataverse und halte die Screens fokussiert.
Benanntes Modell: Canvas als Oberfläche, Dataverse als Engine
- Canvas-Oberfläche: fokussierte Screens, Navigation und Power Fx nur für die Interaktion. Schlanke Control-Bäume, die sich in ALM sauber entpacken lassen.
- Dataverse-Engine: Views, berechnete oder Rollup-Spalten, Plugins und Custom APIs verantworten Berechtigungslogik, Aggregation und tabellenübergreifende Konsistenz.
- Plattformvertrag: delegierbare Abfragen, keine vollständigen Tabellen-Collects in OnStart, keine N+1-Lookups, Monitor-Budgets einschließlich gleichzeitigen Öffnens, dazu Grenzen für Identität und Pakete.
- Vertrag: Im Plattformmaßstab ist Canvas die Interaktionsoberfläche. Dataverse übernimmt die schwere Arbeit. Verschachtelte Formeln in der App sind keine gemeinsame Regel-Engine, wenn mehrere Apps übereinstimmen müssen.
Abbildung 1. Canvas als Oberfläche, Dataverse als Engine. Nutze Power Fx für die Interaktion. Leg gemeinsame Regeln dorthin, wo die Daten liegen.
Kontext und Rahmenbedingung
Eine Canvas App kann sich mit einer kleinen Demo-Tabelle flott anfühlen und auseinanderfallen, sobald die Tabelle wächst und viele Nutzer sich ein ausgelastetes Dataverse teilen. Die Formeln waren nicht "falsch". Die Arbeit lag an der falschen Stelle.
Delegation ist keine Warnung, die man stummschaltet. Sie ist der Unterschied zwischen einer Abfrage auf die Tabelle und einer Abfrage auf eine Stichprobe. Microsoft dokumentiert, dass Power Apps einen begrenzten lokalen Batch verarbeitet, wenn eine Abfrage nicht delegiert werden kann (standardmäßig 500, bis zu 2,000, wenn du das Limit erhöhst). Das Limit zu erhöhen, repariert das Design nicht. Es verschiebt unvollständige Ergebnisse nur, bis die Tabelle wächst.
Gleichzeitige Nutzer verstärken gesprächige Muster. N+1-Lookups, Collection-Ladevorgänge in OnStart und untätige Screens, die weiter abfragen, machen aus einer guten Demo einen Plattform-Incident.
Abbildung 2 zeigt Microsofts plattformkonforme Sicht auf die Performance von Canvas Apps. Die Richtung ist klar: weniger Fan-out in der App, mehr Arbeit auf dem Server.

Abbildung 2. Canvas Apps mit plattformkonformer Architektur optimieren. Quelle: Microsoft Learn: optimize canvas app performance.
Design
1. Teile Mega-Screens auf
Ein Screen, der den ganzen Geschäftsprozess besitzt, lädt schwer, lässt sich schwer mit PAC entpacken und schwer in ALM reviewen. Getrennte Screens entpacken sich sauber, laden weniger ungenutzten Control-Baum und geben dir Navigationsgrenzen, über die du nachdenken kannst. Bevorzuge fokussierte Screens statt eines einzigen scrollenden Meisterwerks.
2. Plane zuerst für Delegation
Schreib Filter und Sortierungen, die die Datenquelle ausführen kann. Bevorzuge bei Dataverse einfache Vergleiche, StartsWith und indizierte Spalten. Behandle blaue Unterstreichungen als Architekturschuld, nicht als Rauschen im Editor. Wenn sich eine Anforderung nicht als delegierbare Abfrage ausdrücken lässt, verlagere die Logik: Dataverse-Views, berechnete oder Rollup-Spalten, Plugins oder ein eingegrenzter erster Filter mit lokalem Feinschliff danach. Lade nicht beim Start "alle Zeilen" in eine Collection und tu so, als wäre das eine Datenbank.
3. Stoppe N+1-Datenzugriffe
Lookups pro Zelle und verschachtelte Galerien, die jeweils Dataverse treffen, erzeugen bei gleichzeitiger Nutzung Fan-out. Lade vorab, was der Screen braucht, nutze Views, die das Rowset schon formen, und filtere auf dem Server. Miss mit Monitor: Argumentiere mit Traces, nicht mit Gefühlen zu einem Ladekreisel.
Abbildung 3 zeigt den Vertrag für den Datenzugriff, der verhindert, dass Produktion bis Zeile 501 vollständig aussieht.
Abbildung 3. Delegation zuerst. Geformte Views und Vorabladen schlagen Collections, die als Warehouse dienen. Ein höheres Zeilenlimit verschiebt unvollständige Ergebnisse nur.
4. Leg Regeln dorthin, wo die Daten liegen
Komplexe Berechtigungslogik, Aggregation und tabellenübergreifende Konsistenz gehören näher an Dataverse als in verschachteltes ForAll in der App. Power Fx ist hervorragend für Interaktion. Als gemeinsame Regel-Engine taugt es wenig, wenn mehrere Apps übereinstimmen müssen. Logik auf dem Server gibt dir eine einzige Definition und weniger Daten, die an die App gehen.
5. Plane ein Budget für gleichzeitiges Verhalten, nicht nur für den Kaltstart
Fan-out in OnStart, das für eine einzelne Makerin gut aussieht, wird schmerzhaft, wenn viele Nutzer die App im selben Zeitfenster öffnen. Untätige Screens, die Timer und Abfragen am Leben halten, verschwenden Kapazität. Gleichzeitige Nutzer brauchen weniger Roundtrips pro Aktion und weniger Arbeit vor der ersten Interaktion. Performance-Budgets sollten "viele Leute haben gleichzeitig den Startscreen geöffnet" einschließen, nicht nur "mein Laptop nach einem Rebuild".
Abbildung 4 zeigt, warum Screen-Aufteilung und Gleichzeitigkeit ins selbe Designgespräch gehören.
Abbildung 4. Fokussierte Screens entpacken sich sauber und laden weniger ungenutzten Baum. Plane ein Budget für gleichzeitiges Öffnen des Startscreens, nicht nur für einen Kaltstart auf einem Laptop.
6. Halte Identität und ALM im selben Gespräch
Auch Canvas Apps stehen in einem größeren Zusammenhang aus Identität und ALM. Wer die App ausführen darf, welche Dataverse-Berechtigungen diese Personen haben und wie das Paket zwischen Umgebungen wandert, sind keine Nebensachen. Ein schneller Screen mit der falschen Sicherheitsrolle ist trotzdem falsch.
Abbildung 5 zeigt die Learn-Darstellung von Rollen und Berechtigungen. Tempo ohne das richtige Zugriffsmodell ist trotzdem falsch.

Abbildung 5. Auch Canvas Apps stehen in einem größeren Zusammenhang aus Identität und ALM. Quelle: Microsoft Learn: security roles and privileges.
Häufige Fehler
Ein Screen besitzt den Prozess. Die YAML-Oberfläche lässt sich nicht mehr reviewen. PAC-Diffs sind Rauschen. Die Ladekosten wachsen mit jedem Control, von dem du vergessen hast, dass es da ist.
Nicht delegierbare Formeln in Produktion. Die Ergebnisse sehen bis Zeile 501 vollständig aus. Das Zeilenlimit auf 2,000 zu erhöhen, verschiebt denselben Bug nur auf später.
Collections als Warehouse. OnStart lädt "für das Tempo" Tausende Zeilen. Gleichzeitiges Öffnen hämmert auf Dataverse ein und verpasst trotzdem Zeilen, die der Filter nie gesehen hat.
Geschäftsregeln nur in Power Fx. Die nächste App implementiert dieselbe Berechtigungslogik neu. Die Zahlen weichen voneinander ab. Niemand weiß, welche Formel maßgeblich ist.
Abfragen im Leerlauf. Screens lassen Verbindungen und Timer laufen. Gleichzeitige Nutzer bezahlen für Arbeit, um die niemand gebeten hat.
Monitor nie geöffnet. Teams diskutieren über Gallery-Eigenschaften, während der Trace einen Wasserfall aus Lookups zeigt. Ohne Monitor optimierst du die falsche Schicht.
So übernehmen oder anpassen
So übernehmen
- Screen-Grenzen und Navigationsmodell (kein Mega-Screen als Standard).
- Welche Logik in Dataverse liegt (Views, berechnete oder Rollup-Spalten, Plugins) und welche in Power Fx (nur Interaktion).
- Für Produktion freigegebene Datenzugriffsmuster: delegierbare Abfragen, keine vollständigen Tabellen-Collects in OnStart, keine N+1-Lookups in Galerien.
- Mit Monitor geprüfte Performance-Budgets, einschließlich Szenarien mit gleichzeitigem Öffnen.
- Richtlinie zum Zeilenlimit: Eine Erhöhung über den Standard braucht eine schriftliche Ausnahme und einen Plan, die Delegation wiederherzustellen.
- Erwartungen an die ALM-Paketierung: Grenzen von Screens und Komponenten, die sich mit PAC sauber entpacken lassen.
Vor dem Einsatz anpassen
Arbeit nach Dataverse zu verlagern, bedeutet mehr Modellierung und manchmal mehr Hilfe von Pro-Entwicklern (Plugins, sorgfältige Views). Maker verlieren etwas von der Freiheit, "heute Nachmittag in der Formelleiste etwas zu ändern". Du gewinnst Korrektheit bei großen Mengen und weniger Überraschungen unter gleichzeitiger Last.
Screens aufzuteilen, erfordert Navigationsdesign. Nutzer klicken mehr. Die Alternative ist ein einziger Screen, der an einem vollen Tag nie fertig lädt.
Strenge Delegationsregeln bremsen die Auslieferung von Features, wenn ein raffinierter Filter in der App heute Abend live gehen könnte. Liefere den raffinierten Filter nur auf einer nachweislich kleinen Menge aus, oder ändere das Design so, dass der Server antworten kann. Unvollständige Ergebnisse in Produktion sind schlimmer als eine verschobene Story.
ALM-Disziplin (kleinere Apps, klarere Grenzen) kostet Prozesszeit. Riesige Pakete mit einer einzigen App kosten Zeit für Incidents.
Wichtigste Quellen: Microsoft Learn: optimize canvas app performance, How to create performant Power Apps und Understand delegation in canvas apps.
So bleibt Canvas wunderbar, auch wenn die Demo-Daten erwachsen werden.