Enterprise-Frontends fallen in Performance-Reviews oft auf irreführende Weise durch. Das UI wirkt wie der Verursacher, weil dort die Verzögerung sichtbar wird. Tatsächlich liegt das Problem häufig im Vertrag zwischen Browser und Backend.
In einer Produktionsplattform habe ich Views für große Datenmengen rund um React 18, TypeScript und RTK Query neu aufgebaut und Pagination, Sortierung sowie Filterung auf den Server verlagert. In repräsentativen, mit Chrome DevTools gemessenen Views sank der Speicherverbrauch im Browser um rund 70 Prozent.
Der interessante Teil war kein cleverer Memoization-Trick. Wir haben Arbeit entfernt, die der Browser nie hätte bekommen sollen.
Eine Tabelle ist ein verteiltes Feature
Ein ernstzunehmendes Data Grid erstreckt sich mindestens über vier Ebenen:
- Query-Semantik in der API;
- Filterung und Sortierung in der Datenbank;
- Cache-Identität im Client;
- Rendering und Interaktion im UI.
Sobald eine Ebene so tut, als wäre der vollständige Datensatz „nur lokaler State“, zahlt irgendwann der Browser dafür.
Die Form des Problems messen
Bevor Komponenten optimiert werden, erfasse:
- übertragene Payload-Größe;
- gehaltenen Heap nach wiederholter Navigation;
- Anzahl gemounteter Zeilen und Zellen;
- doppelte Requests;
- Query-Zeit der API.
So lassen sich Rendering-Kosten von Kosten der Datenhaltung und Backend-Kosten trennen.
Die praktische Regel
Optimiere nicht zuerst die Komponente, bevor entschieden ist, ob die Komponente diese Daten überhaupt besitzen sollte.
Bei großen operativen Datensätzen ist serverseitige Query-Semantik oft die Frontend-Optimierung mit dem höchsten ROI.