Schnelle Dashboard‑Listen mit 100.000 Zeilen: was zuerst tun

Warum Listenansichten langsamer werden, wenn die Daten wachsen

Eine Listenansicht fühlt sich meist in Ordnung an — bis sie es nicht mehr tut. Nutzer bemerken kleine Stockungen, die sich summieren: Ruckeln beim Scrollen, die Seite bleibt nach jeder Aktualisierung kurz hängen, Filter reagieren erst nach Sekunden, und nach jedem Klick erscheint ein Spinner. Manchmal sieht der Browser‑Tab eingefroren aus, weil der UI‑Thread beschäftigt ist.

100k Zeilen sind ein häufiger Wendepunkt, weil sie alle Teile des Systems gleichzeitig belasten. Die Datenmenge ist für eine Datenbank noch normal, aber groß genug, um kleine Ineffizienzen im Browser und im Netzwerk sichtbar zu machen. Wenn du versuchst, alles gleichzeitig anzuzeigen, wird aus einem einfachen Bildschirm schnell eine schwere Pipeline.

Das Ziel ist nicht, alle Zeilen zu rendern. Das Ziel ist, jemandem zu helfen, schnell zu finden, was er braucht: die richtigen 50 Zeilen, die nächste Seite oder einen engen Ausschnitt per Filter.

Es hilft, die Arbeit in vier Bereiche zu unterteilen:

• Netzwerk: wie viele Bytes du sendest und wie häufig.
• Datenbank: wie viele Daten du pro Anfrage scannst, sortierst und aggregierst.
• Browser‑Rendering: wie viele DOM‑Knoten du erstellst, misst und zeichnest.
• JavaScript‑Arbeit: wie oft du neu renderst, Spalten neu berechnest oder Ergebnisse rekombinierst.

Wenn ein Teil teuer ist, wirkt sich das auf den ganzen Bildschirm aus. Eine einfache Suche kann eine Anfrage auslösen, die 100k Zeilen sortiert, tausende Datensätze zurückliefert und dann den Browser zwingt, sie alle zu rendern. So wird Tippen träge.

Wenn Teams interne Tools schnell bauen (auch mit chat‑gestützten Plattformen wie Koder.ai), sind Listenbildschirme oft der erste Ort, an dem echtes Datenwachstum die Lücke zwischen „funktioniert mit Demodaten“ und „fühlt sich jeden Tag sofort an“ offenbart.

Das richtige Performance‑Ziel wählen

Bevor du optimierst, entscheide, was „schnell“ für diesen Bildschirm bedeutet. Viele Teams jagen Durchsatz (alles laden), obwohl Nutzer meist niedrige Latenz brauchen (etwas schnell sehen). Eine Liste kann sich sofort anfühlen, auch wenn nie alle 100k Zeilen geladen werden, solange Scrollen, Sortieren und Filtern schnell reagieren.

Ein praktisches Ziel ist die Zeit bis zur ersten Zeile, nicht bis zur Voll‑Ladung. Nutzer vertrauen der Seite, wenn sie die ersten 20–50 Zeilen schnell sehen und Interaktionen flüssig bleiben.

Was du messen solltest (und warum)

Wähle eine kleine Menge Zahlen, die du bei jeder Änderung nachverfolgen kannst:

• Zeit bis zur ersten Zeile nach dem Öffnen der Seite oder einer Filteränderung
• Zeit, bis ein Filter oder Sortieraktion aktualisierte Ergebnisse zeigt
• Antwortgröße (ungefähre JSON‑Payload‑Größe)
• Langsame Abfragen (besonders COUNT(*) und breite SELECTs)
• Main‑Thread‑Spitzen im Browser (Ruckeln beim Scrollen, Tipplag)

Diese Kennzahlen korrespondieren mit typischen Symptomen. Wenn die Browser‑CPU beim Scrollen ansteigt, macht das Frontend pro Zeile zu viel Arbeit. Wenn der Spinner wartet, aber das Scrollen danach in Ordnung ist, liegt das Problem meist im Backend oder im Netzwerk. Wenn die Anfrage schnell ist, die Seite aber trotzdem einfriert, ist fast immer das Rendering oder eine schwere clientseitige Verarbeitung schuld.

Ein schneller Frontend‑gegen‑Backend‑Test

Probiere dieses einfache Experiment: Lass die UI unverändert, aber begrenze das Backend vorübergehend so, dass es nur 20 Zeilen mit denselben Filtern zurückgibt. Wenn es dann schnell ist, ist der Flaschenhals die Ladungsgröße oder Abfragezeit. Bleibt es langsam, schau dir Rendering, Formatierung und komponentenbezogene Arbeit pro Zeile an.

Beispiel: Eine interne Orders‑Ansicht fühlt sich beim Tippen langsam an. Wenn die API 5.000 Zeilen zurückliefert und der Browser bei jedem Tastendruck lokal filtert, wird das Tippen ruckeln. Dauert die API 2 Sekunden wegen eines COUNT auf einem nicht indexierten Filter, wartet der Nutzer, bevor sich überhaupt eine Zeile ändert. Unterschiedliche Ursachen, dieselbe Nutzerbeschwerde.

Frontend‑Basics: Rendering günstig halten

Der Browser ist oft der erste Engpass. Eine Liste kann sich langsam anfühlen, selbst wenn die API schnell ist, nur weil die Seite zu viel malen will. Die erste Regel ist einfach: Render nicht tausende Zeilen im DOM gleichzeitig.

Schon bevor du volle Virtualisierung einsetzt, halte jede Zeile leichtgewichtig. Eine Zeile mit verschachtelten Wrappern, vielen Icons, Tooltips und komplexen bedingten Styles in jeder Zelle kostet bei jedem Scrollen und Update. Bevorzuge einfachen Text, ein paar kleine Badges und nur ein oder zwei interaktive Elemente pro Zeile.

Eine stabile Zeilenhöhe hilft mehr, als es klingt. Wenn jede Zeile gleich hoch ist, kann der Browser das Layout vorhersagen und das Scrollen bleibt flüssig. Variable Höhen (umfließende Beschreibungen, aufklappbare Notizen, große Avatare) verursachen zusätzliche Messungen und Reflows. Brauchst du mehr Details, ziehe ein Seitenpanel oder einen einzelnen aufklappbaren Bereich in Betracht, nicht eine volle mehrzeilige Zeile.

Formatierung ist eine weitere stille Kostenstelle. Datums‑ und Währungsformatierung sowie aufwändige String‑Arbeit summieren sich, wenn sie in vielen Zellen wiederholt werden.

Eine einfache Faustregel

Wenn ein Wert nicht sichtbar ist, berechne ihn noch nicht. Cache teure Formatierungsergebnisse und berechne sie bei Bedarf, z. B. wenn eine Zeile sichtbar wird oder ein Nutzer sie öffnet.

Ein schneller Durchlauf, der oft deutlich hilft:

• Begrenze das Initial‑Rendering auf eine kleine Seite (oder ein virtuelles Fenster) von Zeilen
• Halte Zeilenhöhe fest und vermeide mehrzeilige Zellen
• Schiebe schwere UI‑Elemente (Tooltips, Menüs) auf Hover oder Klick
• Memoisiere oder cache Datums‑ und Geldformatierungen pro Zeile
• Vermeide das Neurendern aller Zeilen, wenn nur ein Filter geändert wird

Beispiel: Eine interne Rechnungs‑Tabelle mit 12 Währungs‑ und Datumsfeldern ruckelt beim Scrollen. Das Cachen formatierter Werte pro Rechnung und das Verzögern von Arbeit für Off‑Screen‑Zeilen kann das Gefühl von Instantaneität liefern, noch bevor tiefere Backend‑Arbeiten erfolgen.

Virtualisierung: wie man 100k Zeilen flüssig scrollt

Virtualisierung bedeutet, dass die Tabelle nur die Zeilen zeichnet, die man tatsächlich sehen kann (plus kleinen Puffer oben und unten). Beim Scrollen werden dieselben DOM‑Elemente wiederverwendet und die Daten darin ausgetauscht. So versucht der Browser nicht, Zehntausende von Zeilenkomponenten gleichzeitig zu zeichnen.

Virtualisierung passt gut bei langen Listen, breiten Tabellen oder „schweren“ Zeilen (Avatare, Status‑Chips, Aktionsmenüs, Tooltips). Sie ist auch nützlich, wenn Nutzer viel scrollen und eine kontinuierliche Ansicht erwarten statt seitenweiser Sprünge.

Wo Virtualisierung knifflig wird

Es ist kein Zauber. Einige Dinge sorgen oft für Überraschungen:

• Variable Zeilenhöhen (umfließender Text, erweiterbare Zeilen) brechen flüssiges Scrollen, sofern du nicht Höhen misst oder Zeilen konsistent hältst.
• Sticky‑Header und sticky Spalten können mit dem virtualisierten Container kollidieren, wenn das Layout komplexes CSS nutzt.
• Tastatur‑Navigation (Pfeil hoch/runter, PageUp/Down, Fokus in Zellen) braucht zusätzliche Behandlung, damit der Fokus nicht zu ungemounteten Zeilen springt.
• Bulk‑Aktionen brauchen klare Regeln: sichtbare Zeilen auswählen, über Filter selektieren oder über das gesamte Dataset?

Der schlichteste Ansatz ist langweilig: feste Zeilenhöhe, vorhersehbare Spalten und nicht zu viele interaktive Widgets pro Zeile.

Virtualisierung plus Paginierung (ohne Nutzer zu verwirren)

Beides lässt sich kombinieren: nutze Paginierung (oder cursor‑basiertes „Load more“), um zu begrenzen, was du vom Server holst, und Virtualisierung, um das Rendering innerhalb dieses Slice günstig zu halten.

Ein praktisches Muster ist, eine normale Seitengröße (oft 100–500 Zeilen) zu laden, innerhalb dieser Seite zu virtualisieren und klare Steuerungen zum Seitenwechsel anzubieten. Bei Infinite Scroll füge einen sichtbaren „Geladen X von Y“‑Indikator hinzu, damit Nutzer verstehen, dass sie nicht alles sehen.

Paginierungsentscheidungen, die schnell bleiben

Wenn du eine Listenansicht brauchst, die mit wachsender Datenmenge nutzbar bleibt, ist Paginierung meist die sicherste Default‑Wahl. Sie ist vorhersehbar, passt gut zu Admin‑Workflows (prüfen, bearbeiten, genehmigen) und unterstützt Bedürfnisse wie „Seite 3 mit diesen Filtern exportieren“ ohne Überraschungen. Viele Teams landen wieder bei Paginierung, nachdem sie fancieres Scrollen getestet haben.

Infinite Scroll kann für entspanntes Browsen schön wirken, hat aber versteckte Kosten. Nutzer verlieren oft die Orientierung, der Zurück‑Button kehrt nicht immer an dieselbe Stelle zurück, und lange Sessions können Speicherprobleme bringen, wenn immer mehr Zeilen geladen werden. Ein Mittelweg ist ein "Load more"‑Button, der trotzdem mit Seiten arbeitet, sodass Nutzer orientiert bleiben.

Offset vs Keyset‑Paginierung

Offset‑Paginierung ist der klassische page=10&size=50‑Ansatz. Er ist simpel, kann aber bei großen Tabellen langsamer werden, weil die DB viele Zeilen überspringen muss, um zu späteren Seiten zu gelangen. Auch kann es merkwürdig wirken, wenn neue Zeilen eintreffen und Elemente zwischen Seiten verschoben werden.

Keyset‑Paginierung (oft Cursor genannt) fragt nach „den nächsten 50 Zeilen nach dem zuletzt gesehenen Element“, typischerweise unter Nutzung einer id oder von created_at. Sie bleibt meist schnell, weil sie nicht so viel zählen und überspringen muss.

Eine praktische Regel:

• Verwende Offset für kleinere Listen, stabile Datensätze und wenn das direkte Springen zu einer Seitenzahl nötig ist.
• Verwende Keyset für sehr große Listen, häufige Inserts und Next/Previous‑Navigation.

Totals anzeigen, ohne den Preis jedes Mal zu zahlen

Nutzer mögen Totals sehen, aber ein volles „count all matching rows“ kann mit schweren Filtern teuer sein. Optionen sind: Counts für populäre Filter cachen, die Zählung im Hintergrund nachladen, oder eine ungefähre Zahl anzeigen (z. B. „10.000+“).

Beispiel: Eine Orders‑Ansicht kann sofort Ergebnisse mit Keyset‑Paginierung zeigen und die exakte Gesamtanzahl erst dann füllen, wenn der Nutzer kurz mit dem Filtern aufgehört hat.

Wenn du das in Koder.ai baust, behandle Paginierungs‑ und Count‑Verhalten früh als Teil der Screen‑Spec, damit generierte Backend‑Queries und UI‑State sich später nicht ins Gehege kommen.

Filter und Suche, die sich sofort anfühlen

Die meisten Listen wirken langsam, weil sie zu offen starten: alles laden und den Nutzer dann einschränken lassen. Dreh das um. Starte mit sinnvollen Defaults, die eine kleine, nützliche Menge zurückgeben (z. B. Letzte 7 Tage, Meine Einträge, Status: Offen), und mache „Alle Zeiten“ zur expliziten Wahl.

Textsuche ist eine weitere Falle. Wenn du bei jedem Tastenanschlag eine Abfrage ausführst, erzeugst du einen Rückstau von Requests und eine flackernde UI. Debounciere die Suche, sodass erst nach einer kurzen Pause eine Abfrage erfolgt, und breche ältere Requests ab, wenn ein neuer startet. Einfache Regel: Wenn der Nutzer noch tippt, frag nicht den Server an.

Filtering fühlt sich nur dann schnell an, wenn es auch klar ist. Zeige Filter‑Chips oben in der Tabelle, damit Nutzer sehen, was aktiv ist und es mit einem Klick entfernen können. Halte Chip‑Labels menschenlesbar, nicht rohe Feldnamen (z. B. Owner: Sam statt owner_id=42). Wenn jemand sagt „meine Ergebnisse sind verschwunden“, liegt es meist an einem unsichtbaren Filter.

Muster, die große Listen reaktionsfähig halten, ohne die UI zu verkomplizieren:

• Standardmäßig enge Filter und kurze Datumsbereiche
• Debounce für Texteingaben und Abbrechen laufender Requests
• Filter‑Chips und eine „Alles löschen“‑Aktion
• Gespeicherte Ansichten für typische Aufgaben
• Teure Filter erst aktivieren, wenn mindestens ein einschränkender Filter gesetzt ist

Gespeicherte Ansichten sind oft die stille Heldin. Statt Nutzern beizubringen, jedes Mal die perfekte Einmal‑Filterkombination zu bauen, gib ihnen einige Presets, die echte Workflows abdecken. Ein Ops‑Team wechselt vielleicht zwischen „Fehlgeschlagene Zahlungen heute“ und „High‑Value Kunden“. Diese sind mit einem Klick verständlich und leichter backend‑freundlich schnell zu halten.

Wenn du ein internes Tool in einem chat‑getriebenen Builder wie Koder.ai baust, betrachte Filter als Teil des Produktflusses, nicht als Anbauteil. Starte mit den häufigsten Fragen und entwirf Default‑ und Saved‑Views darum herum.

Query‑Shaping: weniger anfragen, weniger berechnen

Eine Listenansicht braucht selten dieselben Daten wie eine Detailseite. Wenn deine API alles über alles zurückgibt, zahlst du doppelt: die DB macht mehr Arbeit und der Browser empfängt und rendert mehr als nötig. Query‑Shaping heißt, nur das zu fordern, was die Liste gerade braucht.

Gib zuerst nur die Spalten zurück, die jede Zeile rendert. Für die meisten Dashboards sind das id, einige Labels, Status, Besitzer und Zeitstempel. Große Texte, JSON‑Blobs und berechnete Felder können warten, bis der Nutzer eine Zeile öffnet.

Vermeide schwere Joins für den ersten Paint. Joins sind in Ordnung, wenn sie Indexe nutzen und kleine Ergebnisse liefern, aber teuer, wenn du mehrere Tabellen joinst und dann auf den verbundenen Daten sortierst oder filterst. Ein einfaches Muster: Liste schnell aus einer Tabelle holen, verwandte Details on‑demand laden (oder für sichtbare Zeilen batchen).

Begrenze die Sortieroptionen auf indexierte Spalten. „Nach allem sortieren“ klingt hilfreich, führt aber oft zu langsamen Sorts auf großen Datensätzen. Bevorzuge einige vorhersehbare Optionen wie created_at, updated_at oder status und stelle sicher, dass diese Spalten indexiert sind.

Sei vorsichtig bei serverseitiger Aggregation. COUNT(*) auf einer großen gefilterten Menge, DISTINCT auf einer breiten Spalte oder Berechnungen für Gesamtseiten können die Antwortzeit dominieren.

Praktischer Ansatz:

• Forme die List‑Antwort auf 5–10 Felder
• Hole Zeilendetails nur, wenn eine Zeile geöffnet wird
• Erlaube 2–4 Sortoptionen, alle durch Indexe gedeckt
• Behandle COUNT und DISTINCT als optional, cache oder approximier sie wenn möglich

Wenn du interne Tools auf Koder.ai baust, definiere eine leichte Listenquery separat von der Details‑Query in der Planungsphase, damit die UI snappy bleibt, wenn die Daten wachsen.

Datenbanktaktiken für große Tabellen

Wenn du eine Listenansicht willst, die bei 100k Zeilen schnell bleibt, muss die Datenbank pro Anfrage weniger Arbeit machen. Die meisten langsamen Listen sind kein Problem der Datenmenge, sondern des falschen Datenzugriffs.

Starte mit Indizes, die dem entsprechen, was Nutzer tatsächlich tun. Filterst du meist nach status und sortierst nach created_at, dann brauchst du einen Index, der beides in dieser Reihenfolge unterstützt. Ansonsten scannt die DB unter Umständen viel mehr Zeilen und sortiert sie, was schnell teuer wird.

Fixes mit größtem Effekt:

• Füge Composite‑Indizes hinzu, die gängige Filter + Sort widerspiegeln (z. B. tenant_id, status, created_at).
• Bevorzuge Keyset (Cursor)‑Paginierung gegenüber tiefen OFFSET‑Seiten. OFFSET lässt die DB viele Zeilen überspringen.
• Behandle Totals als optional. Exakte Zählungen können teuer sein. Cache Counts, berechne sie vor oder zeige „10.000+“ wenn genau nicht nötig.
• Halte Zeilen schlank. Selektiere keine großen Textfelder, JSON‑Blobs oder verschachtelten Objekte in der Listansicht.
• Formen die Queries so, dass nur das zurückkommt, was die UI rendert: wenige Spalten plus Next‑Page Cursor.

Einfaches Beispiel: Eine Orders‑Tabelle zeigt Kundenname, Status, Betrag und Datum. Joine nicht jede verwandte Tabelle und ziehe nicht die gesamten Bestell‑Notes für die Listensicht. Gib nur die für die Tabelle genutzten Spalten zurück und lade den Rest separat, wenn der Nutzer eine Bestellung anklickt.

Wenn du mit einer Plattform wie Koder.ai baust, behalte dieses Mindset, auch wenn die UI aus Chat generiert wird. Sorge dafür, dass die generierten API‑Endpoints Cursor‑Paginierung und selektive Felder unterstützen, damit die DB‑Arbeit bei wachsendem Table‑Size vorhersehbar bleibt.

Schritt‑für‑Schritt‑Plan, um eine bestehende Liste zu beschleunigen

Wenn eine Listen‑Seite heute langsam wirkt, fang nicht mit einem vollständigen Rewrite an. Bestimme zuerst, wie normale Nutzung aussieht, und optimiere diesen Pfad.

Ein praktischer Fünf‑Schritte‑Plan

1. Default‑View definieren. Wähle Standardfilter, Sortierung und sichtbare Spalten. Listen werden langsam, wenn sie standardmäßig versuchen, alles zu zeigen.

2. Paging‑Stil wählen, der zur Nutzung passt. Wenn Nutzer meist die ersten Seiten scannen, ist klassische Paginierung okay. Springen sie weit (Seite 200+) oder brauchst du konstante Performance, nutze Keyset‑Paginierung (z. B. created_at plus id).

3. Virtualisierung für den Tabellenkörper hinzufügen. Selbst bei schnellem Backend kann der Browser bei zu vielen Zeilen choke‑n.

4. Suche und Filter reaktionsschnell machen. Debounce beim Tippen, damit nicht bei jedem Keypress eine Anfrage losgeht. Halte Filterstate in der URL oder in einem gemeinsamen State‑Store, damit Refresh, Back‑Button und Teilen zuverlässig funktionieren. Cache das letzte erfolgreiche Ergebnis, damit die Tabelle nicht leer aufblinkt.

5. Messen, dann Queries und Indizes tunen. Logge Server‑Zeit, DB‑Zeit, Payload‑Größe und Render‑Zeit. Dann straffe die Query: wähle nur die Spalten, die du zeigst, filtere früh und füge Indizes passend zum Default‑Filter+Sort hinzu.

Beispiel: Ein internes Support‑Dashboard mit 100k Tickets. Default: Offen, meinem Team zugewiesen, nach Neueste sortiert, sechs Spalten anzeigen und nur Ticket‑id, Betreff, Bearbeiter, Status und Zeitstempel holen. Mit Keyset‑Paginierung und Virtualisierung bleiben DB und UI vorhersehbar.

Wenn du in Koder.ai baust, passt dieser Plan gut zu einem Iterate‑and‑Check‑Workflow: Ansicht anpassen, Scroll‑ und Suchverhalten testen, dann die Query optimieren, bis die Seite snappy bleibt.

Häufige Fehler, die Listen ausbremsen

Der schnellste Weg, eine Listenansicht zu ruinieren, ist, 100k Zeilen wie eine normale Seite zu behandeln. Die meisten langsamen Dashboards folgen ein paar typischen Fallen.

Eine große ist, alles zu rendern und mit CSS zu verstecken. Auch wenn nur 50 Zeilen sichtbar scheinen, bezahlt der Browser trotzdem für das Erstellen von 100k DOM‑Knoten, das Messen und Repainten beim Scrollen. Wenn du lange Listen brauchst, rendere nur das, was sichtbar ist (Virtualisierung) und halte Zeilenkomponenten einfach.

Suche kann Performance still sabotieren, wenn jeder Tastendruck einen Full‑Table‑Scan auslöst. Das passiert, wenn Filter nicht indexiert sind, wenn du über zu viele Spalten suchst oder Contains‑Queries auf großen Textfeldern ohne Plan ausführst. Gute Regel: Der erste Filter, zu dem Nutzer greifen, sollte in der DB günstig sein, nicht nur in der UI bequem.

Ein weiterer häufiger Fehler ist, ganze Datensätze zu holen, obwohl die Liste nur Zusammenfassungen braucht. Eine Zeile braucht meist 5–12 Felder, nicht das ganze Objekt, keine langen Beschreibungen und keine verwandten Daten. Extra Daten zu ziehen erhöht DB‑Arbeit, Netzwerkzeit und Frontend‑Parsing.

Export und Totals können die UI einfrieren, wenn du sie im Main‑Thread berechnest oder auf eine schwere Anfrage wartest. Halte die UI interaktiv: Starte Exporte im Hintergrund, zeige Fortschritt und vermeide Totals bei jeder Filteränderung neu zu berechnen.

Zu viele Sortoptionen schaden ebenfalls. Wenn Nutzer nach jeder Spalte sortieren können, wirst du große Resultsets in Memory sortieren müssen oder die DB in langsame Pläne zwingen. Beschränke Sorts auf wenige indexierte Spalten und sorge dafür, dass die Default‑Sortierung zu einem realen Index passt.

Schnelle Orientierungshilfe:

• Wenn du endlos scrollen kannst, ohne nachzuladen, hast du wahrscheinlich zu viel gerendert.
• Wenn Tippen in der Suche ruckelt, scannt deine Query vermutlich zu viel.
• Wenn die List‑API riesiges JSON zurückgibt, overfetchst du.
• Wenn Export die Seite aufhängt, passiert die Arbeit am falschen Ort.
• Wenn jeder Sort langsam ist, müssen Indizes und Sortoptionen überdacht werden.

Schnellcheckliste und nächste Schritte

Behandle Listen‑Performance wie ein Produktfeature, nicht als einmalige Schrauberei. Eine Listenansicht ist nur dann schnell, wenn sie sich beim echten Scrollen, Filtern und Sortieren mit echten Nutzern schnell anfühlt.

Nutze diese Checkliste, um zu bestätigen, dass du die richtigen Dinge gefixt hast:

• First paint ist schnell: die Seite lädt eine kleine Payload und zeigt die ersten Zeilen sofort.
• Scrollen bleibt flüssig: Virtualisierung ist aktiv, Browser‑CPU bleibt niedrig und Zeilenhöhen sind vorhersagbar.
• Filter fühlen sich reaktionsschnell an: Tippen oder Auswählen aktualisiert Ergebnisse schnell und Filter gehen beim Paginieren oder Refresh nicht verloren.
• Sortierung ist sinnvoll: erlaube nur Sorts, die durch einen Index oder ein vorberechnetes Feld gedeckt sind, und halte die Sortierung konsistent über Seiten.
• Requests sind geformt: die API liefert nur die Spalten, die du anzeigst, plus stabile IDs und Cursor, nicht komplette Objekte „für alle Fälle".

Ein einfacher Reality‑Check: Öffne die Liste, scrolle 10 Sekunden, dann wende einen häufigen Filter an (z. B. Status: Offen). Friert die UI ein, liegt das Problem meist am Rendering (zu viele DOM‑Zeilen) oder an einer schweren clientseitigen Transformation (Sortieren, Gruppieren, Formatieren), die bei jedem Update läuft.

Nächste Schritte, in Reihenfolge, damit du nicht zwischen Fixes hin‑und‑her springst:

1. Messe einen Nutzerfluss End‑to‑End (Laden, Scroll, Filter, Sort) und definiere Zielzeiten.
2. Schalte Virtualisierung ein und kappe teure Formatierung in Zellen (Datum, Währung, Avatare).
3. Verlager Filterung und Sortierung auf den Server und begrenze Optionen auf das, was schnell möglich ist.
4. Straffe Queries und Payloads, dann neu messen.

Wenn du das mit Koder.ai (koder.ai) baust, beginne im Planning Mode: definiere erst die exakten Listen‑Spalten, Filterfelder und die API‑Antwortstruktur. Iteriere dann mit Snapshots und rolle zurück, wenn ein Experiment die Seite verlangsamt.