Der DOM-Flaschenhals, über den niemand spricht

Stellen Sie sich ein Support-Dashboard vor, das zehntausend Log-Einträge lädt. Oder ein CRM, das versucht, jeden Kontakt in einer einzigen scrollbaren Tabelle anzuzeigen. In React sieht der Code dafür harmlos genug aus. Man mappt über ein Array, gibt etwas JSX zurück und überlässt dem Framework die Arbeit. In der Entwicklung mit hundert Zeilen funktioniert alles einwandfrei. Doch sobald die Produktionsdaten eintreffen, wird die Seite extrem träge.

Der Browser ist nicht faul. Er tut genau das, was Sie verlangt haben, und genau das ist das Problem. Jede Zeile wird zu einem DOM-Knoten. Jeder Knoten wird gestylt, gelayoutet, gemalt und im Speicher verfolgt. Wenn Sie scrollen, berechnet der Browser die Positionen für den gesamten Baum neu, nicht nur für den Ausschnitt, den Sie gerade sehen. Event-Listener häufen sich an. Der Speicherverbrauch schießt in die Höhe. Schließlich erstickt der Main-Thread so lange, dass die Benutzeroberfläche nicht mehr auf Klicks, Tastatureingaben oder auch nur das Scrollen selbst reagiert. Die Anwendung ist technisch gesehen nicht abgestürzt, aber für den Benutzer, der davor sitzt, ist das Erlebnis dennoch unterbrochen.

Das passiert, weil der Browser versucht, jedes einzelne Element gleichzeitig im aktiven Speicher zu halten. React mag effizient darin sein, virtuelle Beschreibungen Ihrer UI zu erstellen, aber sobald diese Beschreibungen zu echten Knoten im Dokument werden, kosten sie genauso viel wie handgeschriebenes HTML. Es gibt im Framework selbst keinen Ausweg. Sie benötigen eine strukturelle Änderung in der Art und Weise, wie Sie die Liste an das DOM übergeben.

Was Virtualisierung eigentlich bedeutet

Virtualisierung ist genau diese strukturelle Änderung. Anstatt React anzuweisen, das gesamte Array zu rendern, rendern Sie nur die Elemente, die in den Viewport passen, plus einen kleinen Puffer oberhalb und unterhalb. Während der Benutzer scrollt, verwirft die Anwendung Knoten, die aus dem Sichtfeld verschwinden, und instanziiert neue, die vom gegenüberliegenden Rand ins Bild kommen. Für den Benutzer fühlt es sich immer noch wie eine kontinuierliche Liste an, da die gesamte scrollbare Höhe erhalten bleibt – meist durch ein einzelnes, hohes Containerelement oder einen sorgfältig berechneten Spacer. Die sichtbaren Elemente sind lediglich ein Fenster, das über den Datensatz gleitet.

Stellen Sie es sich wie einen Filmstreifen vor, der durch einen Projektor läuft. Das Publikum sieht eine flüssige Bewegung, aber die Mechanik beleuchtet nur den Rahmen, der sich gerade in Position befindet. Der Rest der Rolle befindet sich auf den Ein- und Aufwickelspulen, nicht im Lichtweg. Virtualisierte Listen funktionieren auf die gleiche Weise. Der Datensatz ist die Filmrolle. Der Viewport ist der Projektorschlitz.

Dies ist kein Lazy Loading im herkömmlichen Sinne. Lazy Loading verzögert das Abrufen von Daten, bis der Benutzer in die Nähe kommt. Virtualisierung setzt voraus, dass Sie die Daten bereits haben, aber Sie entscheiden selektiv, welche Teile zu echten DOM-Elementen befördert werden. Beide Techniken können zusammenarbeiten, aber sie lösen unterschiedliche Probleme.

Warum der Unterschied sofort spürbar ist

Die Vorteile zeigen sich an vier Stellen, die alle mit derselben zugrunde liegenden Entlastung verbunden sind: Sie zahlen nicht mehr für das, was der Benutzer nicht sehen kann.

Schnellere initiale Ladezeiten. Wenn der Browser die Seite öffnet, malt er vielleicht fünfzehn Zeilen statt fünfzehntausend. Das erste bedeutsame Rendering erfolgt früher. Die Zeit bis zur Interaktivität sinkt, da die JavaScript-Engine weniger Zeit damit verbringt, Knoten zu erstellen und sie an das Dokument anzuhängen.

Geringerer Speicherverbrauch. Ein DOM-Knoten ist ein teures Objekt. Jeder trägt Referenzen auf Style-Regeln, Layout-Metriken und Event-Bindings in sich. Reduzieren Sie die Anzahl der aktiven Knoten auf ein paar Dutzend, und der Speicherbedarf bricht ein. Bei Low-End-Geräten oder langen Sitzungen kann dies allein verhindern, dass der Tab vom Betriebssystem geschlossen wird.

Flüssige Scroll-Performance. Mit weniger Knoten im Baum verbringt der Browser während der Scroll-Events weniger Zeit in den Layout- und Paint-Phasen. Der Compositor-Thread kann Bewegungen verarbeiten, ohne ständig die Geometrie des verborgenen Inhalts neu berechnen zu müssen. Das Ergebnis ist ein Scrollen, das näher an der Bildwiederholrate des Monitors bleibt.

Stabile Bildraten. Da der Main-Thread nicht mehr in Layout-Arbeiten ertrinkt, gibt es Spielraum für andere Aktivitäten. Animationen bleiben flüssig. Netzwerkantworten können verarbeitet werden. Die UI friert nicht ein, wenn neue Daten eintreffen, da der Render-Pfad nicht länger ein Flaschenhals ist.

Die richtige Implementierung finden

Im React-Ökosystem bieten Bibliotheken wie react-window und die umfangreichere react-virtualized die Mechanik für dieses Muster. Die Kernidee ist konsistent: Sie definieren einen Item-Renderer, übergeben die Gesamtzahl der Elemente, und die Bibliothek übernimmt die Windowing-Berechnungen. Aber die Details bereiten oft Schwierigkeiten.

Erstens benötigt der Container eine definierte Höhe. Wenn die Liste in einem übergeordneten Element liegt, das sich an seine Kinder anpasst, kann die Virtualisierung nicht berechnen, welche Elemente sichtbar sind, da es keine Viewport-Grenze gibt. Sie müssen die Liste auf eine feste Höhe oder einen Flex-Container mit bekannten Einschränkungen festlegen.

Zweitens ist die Größe der Elemente immens wichtig. Zeilen mit fester Höhe sind der einfachste Fall. Die Bibliothek multipliziert die Zeilenhöhe mit dem Index und weiß genau, wo jedes Element positioniert werden muss. Inhalte mit variabler Höhe, wie Chat-Nachrichten mit eingebetteten Bildern oder Kommentar-Threads, zwingen die Bibliothek dazu, nach dem Mounten zu messen und die Positionen laufend anzupassen. Dieser Messschritt kann zu Scroll-Ruckeln führen, wenn er zu spät erfolgt. Wenn Ihre Daten es zulassen, erzwingen Sie einheitliche oder Mindesthöhen. Wenn nicht, verwenden Sie einen Virtualizer für variable Höhen und akzeptieren Sie die zusätzliche Komplexität.

Drittens ist Overscan Ihr Freund. Das Rendern genau dessen, was auf den Bildschirm passt, erzeugt weiße Streifen, wenn der Benutzer schnell scrollt. Die meisten Bibliotheken erlauben es Ihnen, ein paar zusätzliche Elemente oberhalb und unterhalb des sichtbaren Bereichs zu rendern. Zwei oder drei Zeilen Overscan reichen normalerweise aus, um die Übergänge zu kaschieren, ohne den DOM erneut aufzublähen.

Viertens sollten Sie das key-Prop nicht ignorieren. In einer virtualisierten Liste werden DOM-Knoten beim Scrollen wiederverwendet. Stabile Keys verhindern, dass React während der Reconciliation falsch rät und den State innerhalb der Zeilen-Komponenten zerstört. Wenn Ihre Listenzeilen Inputs, Toggles oder ausklappbare Abschnitte enthalten, werden schlechte Keys den UI-State auf eine Weise korrumpieren, die wie Fehler in Ihrer Datenschicht aussieht, aber eigentlich Rendering-Fehler sind.

Eine subtile Falle ist die Suchfunktion des Browsers („Finden auf Seite“). Da die verborgenen Elemente nicht im DOM existieren, wird das Suchfeld des Browsers sie nicht finden. Wenn Ihre Benutzer Ctrl+F verwenden, um Text in einer großen Liste zu finden, müssen Sie eine benutzerdefinierte Suche implementieren, die gegen den Datensatz und nicht gegen das Dokument arbeitet. Auch Screenreader können den Kontext verlieren, wenn die Listen-Semantik nicht sorgfältig gehandhabt wird. Testen Sie daher mit assistiven Technologien und ziehen Sie das Hinzufügen von Live-Region-Ankündigungen für das dynamische Laden in Betracht.

Wann Sie darauf verzichten sollten

Virtualisierung ist nicht umsonst. Sie erhöht das Gewicht der Abhängigkeiten, die mathematische Berechnung der Koordinaten und den Overhead durch Einschränkungen. Wenn Ihre Liste bei fünfzig oder hundert Elementen gedeckelt ist, kann der Browser das ohne Hilfe bewältigen. Rendern Sie einfach alles und machen Sie weiter. Dasselbe gilt, wenn Ihre Listenelemente einzeln extrem komplex sind. Virtualisierung spart Ihnen tausende Knoten, aber sie kann Sie nicht vor einem einzelnen Knoten retten, der ein massives Chart- oder Video-Element enthält. Beheben Sie zuerst das Problem der überladenen Elemente.

Vermeiden Sie Virtualisierung auch dann, wenn die Liste nicht scrollt. Wenn Sie mit „Weiter“- und „Zurück“-Buttons paginieren und nur zwanzig Elemente pro Seite anzeigen, gibt es nichts zu „windowen“. Die Technik lohnt sich nur, wenn der Benutzer erwartet, durch eine große, zusammenhängende Sequenz zu scrollen.

Das eigentliche Fazit

Virtualisierung ist weniger eine Entscheidung für eine Bibliothek als vielmehr eine Denkweise. Sie zwingt Sie dazu, anzuerkennen, dass das DOM eine endliche Ressource ist und keine unendliche Leinwand. Bevor Sie sie hinzufügen, öffnen Sie die Chrome DevTools, nehmen Sie ein Performance-Profil auf und bestätigen Sie, dass die Layout- oder Paint-Zeit tatsächlich die Ursache ist. Sobald Sie wissen, dass das DOM der Flaschenhals ist, akzeptieren Sie die Einschränkungen. Legen Sie Ihre Höhen fest, achten Sie auf Ihre Keys, nutzen Sie moderat Overscan und testen Sie die Barrierefreiheit. Richtig angewendet, verwandelt eine virtualisierte Liste eine unbrauchbare Datenwand in etwas, das sich so leicht anfühlt wie eine native Scroll-Ansicht. Der Browser hört auf zu kämpfen, Ihre Benutzer hören auf zu warten, und die App verhält sich endlich wie die schnelle Schnittstelle, die Sie zu bauen beabsichtigt haben.