Warum langsame Formulare in Microsoft D365 entstehen

Ein Formular, das 4 Sekunden zum Öffnen braucht, kostet bei 50 Öffnungen am Tag pro Person ein paar Minuten, auf eine ganze Organisation gerechnet können es Stunden pro Woche sein. Die Ursachen sind selten exotisch. Meistens sind es dieselben Bremsen und die meisten davon stehen in der Formulardefinition, wo man sie zählen und sehen kann.

Jedes Unterraster ist eine Abfrage

Der größte Einzelposten sind Subgrids. Jedes davon feuert beim Laden eine eigene Abfrage, dazu kommen Icons und Formatierung. Ein Formular mit 4 Untergittern startet also mit 4 Abfragen zusätzlich zum eigentlichen Datensatz. Und wenn die zugrunde liegenden Ansichten breit gebaut sind, mit entsprechend langsamen.

Nicht jedes Untergitter muss weg. Aber jedes sollte die Frage beantworten: Wird das beim Öffnen wirklich sofort gebraucht, oder reicht es auf einem zweiten Tab wo es erst bei Bedarf geladen wird? Denn hier greift eine freundliche Eigenschaft der Plattform: Inhalte auf eingeklappten oder nicht aktiven Tabs werden erst beim Aufklappen geladen. Die billigste Formularbeschleunigung ist deshalb oft reine Umsortierung.

Die Skript-Kette beim Laden

Der zweite Posten sind die OnLoad-Ereignisse. Problematisch sind weniger viele kleine Handler als einzelne teure: Skripte, die beim Laden Serverdaten nachholen, womöglich mehrere nacheinander oder synchron. Ein synchroner Aufruf blockiert das Formular komplett, bis die Antwort da ist und zwei davon in Folge addieren sich sichtbar.

Welche Funktionen beim Laden hängen steht in der Formulardefinition. Die Kette einmal aufzuschreiben und jede Position zu hinterfragen ist mühsamer als das Subgrid-Zählen findet aber die zähen Fälle.

Die stillen Beiträge

Dazu kommen Posten, die einzeln klein sind und sich summieren: sehr viele Felder auf dem ersten Tab, Schnellansichtsformulare (jedes lädt seinen verknüpften Datensatz mit), eine aufwendig konfigurierte Zeitachse, Business Rules in großer Zahl oder bei Auswahlfeldern mit Hunderten Optionen auch diese.

Einen Sonderfall bilden Rollup- und berechnete Felder: Sie machen das Formular selten langsam, wecken aber den Eindruck weil ihre Werte verzögert erscheinen. Das ist ein anderes Problem mit anderer Lösung.

Bei der Bewertung hilft noch eine Unterscheidung: Die erste Öffnung nach einem Deployment oder Browserwechsel ist immer langsamer, weil Ressourcen frisch vom Server und in den Cache geladen werden. Wer Ladezeiten vergleicht sollte deshalb die erste Öffnung messen.

Messen statt raten

Bevor umgebaut wird, lohnt eine Messung, und die Plattform bringt sie mit: Der Performance-Bereich im Formular (über die Diagnostik erreichbar) zeigt, welche Bestandteile wie lange gebraucht haben. Damit wird aus der Vermutung, die Skripte seien schuld, eine Zahl, und nicht selten zeigt die Zahl auf etwas anderes als vermutet.

Die Zielgröße ist unspektakulär: unter zwei Sekunden fühlt sich ein Formular normal an. Dahin kommt man fast immer mit Umsortieren, Ausdünnen und dem Entschärfen von ein, zwei teuren Skripten. Ein Neubau ist selten nötig.