Startseite / Artikel / Die Diagnose von React-Leistungsproblemen jenseits der API-Antwortzeit

React Performance JavaScript Frontend Architecture Web Development

Die Diagnose von React-Leistungsproblemen jenseits der API-Antwortzeit

Erfahren Sie, warum schnelle APIs keine zuverlässige Leistung der Benutzeroberfläche garantieren, und wie Rendering, die Größe der Pakete sowie die Dateiorganisation heimlich die tatsächliche Leistung einer React-App beeinflussen.

1764 Wörter

Schnelligkeit und Klarheit in einem React-Projekt versagen oft aus demselben grundlegenden Grund: Was auf den ersten Blick fertig erscheint, ist im Inneren noch unvollständig. Ein Backend, das innerhalb von 200 Millisekunden antwortet, sagt nichts darüber aus, was der Browser noch tun muss, bevor ein Benutzer etwas sehen oder darauf interagieren kann. Ebenso kann ein Projekt, dessen Komponenten alle korrekt funktionieren, dennoch anstrengend in der Nutzung sein, wenn verwandte Dateien über die gesamte Codebasis verstreut sind. Beide Probleme lehren uns eine Lektion: Es ist das, was nach Abschluss des offensichtlichen Teils geschieht – nachdem die API geantwortet hat, nachdem eine Funktion implementiert wurde –, was bestimmt, ob die Anwendung tatsächlich schnell und wartbar wirkt.

Wenn die API nicht das Engpassproblem ist

Stellen Sie sich eine Anfrage vor, die genau so funktioniert, wie beabsichtigt: Die Datenbank ist optimiert, der Server ist in Ordnung und die API antwortet schnell.

API Request
    ↓
    200ms
    ↓
Data received
    ↓
JavaScript processing
    ↓
React rendering
    ↓
Browser painting
    ↓
User sees the result

Diese 200-Millisekunden-Rundreise ist erst die Einleitung. Eine API kann ihre Aufgabe schnell erledigen, während der Browser noch eine lange Liste an Aufgaben zu bewältigen hat – Komponenten rendern, den DOM aktualisieren, Berechnungen durchführen und Pixel zeichnen. Wenn einer dieser Schritte ineffizient ist, erlebt der Benutzer eine Verlangsamung, die nichts mit dem Server zu tun hat.

Komponenten, die mehr rendern, als nötig ist

Eine häufige Ursache für diese versteckten Kosten ist das unnötige Neurendern. Eine einzige Zustandsaktualisierung kann dazu führen, dass eine Komponente erneut gerendert wird, und dieses Neurendern kann sich auf Kinderkomponenten auswirken, die überhaupt nicht geändert werden mussten.

function Dashboard() {
  const [count, setCount] = useState(0);
return (
    <>
      <button onClick={() => setCount(count + 1)}>
        {count}
      </button>
      <LargeComponent />
    </>
  );
}

Falls LargeComponent Hunderte von Elementen enthält oder aufwändige Berechnungen durchführt, könnte jeder Klick dazu führen, dass React weitaus mehr Arbeit leistet, als die Interaktion tatsächlich erfordert. Werkzeuge wie React.memo, useMemo und useCallback dienen dazu, solche überflüssigen Arbeiten zu vermeiden, sollten aber nicht überall angewandt werden. Der bessere Ansatz ist es zunächst herauszufinden, welche Darstellung tatsächlich aufwändig ist, und diese konkrete Situation zu optimieren, anstatt aus Gewohnheit den gesamten Codebase mit Memoisierung zu umhüllen.

Lange Listen bedeuten weiterhin lange DOM-Bäume

Auch wenn die Daten sofort ankommen, stellt ihre vollständige Darstellung einen eigenen Aufwand dar. Angenommen, die API gibt innerhalb weniger Millisekunden 5.000 Benutzer zurück – das ist in Ordnung. Das Problem beginnt, wenn man sie alle auf einmal darstellt:

{users.map(user => (
  <UserCard key={user.id} user={user} />
))}

Zu diesem Zeitpunkt muss der Browser Tausende von DOM-Node erstellen, messen, anordnen und darstellen – und diese Arbeit hat nichts mit der Geschwindigkeit zu tun, mit der die Daten ankommen. Bei großen Datensätzen hilft es, sich auf Paginierung, Virtualisierung, unbegrenztes Scrollen oder einfach das Laden nur dessen zu verlassen, was der Benutzer gerade betrachtet. In vielen Fällen ist die schnellste Schnittstelle jene, die es vermeidet, alles auf einmal darzustellen.

Die im JavaScript-Bundle verborgenen Kosten

Benutzer erleben die Antwortzeit Ihrer API nicht direkt – sie spüren lediglich, wie lange es dauert, bis die Seite nutzbar wird. Wenn der Browser zunächst mehrere Megabyte an JavaScript herunterladen und ausführen muss, wird diese 200-Millisekunden-Antwortzeit von einem viel langsameren Ablauf überschattet: Herunterladen, Parsen, Kompilieren, Ausführen und schließlich Darstellung. All das muss vor einer jeglichen Interaktion stattfinden.

Lazy Loading ist eine Möglichkeit, diese Anfangskosten zu senken, indem Code, der nicht sofort benötigt wird, aufgeschoben wird:

const Settings = lazy(() => import("./Settings"));

Sobald ein Modul wie Settings verspätet geladen wird, muss es nicht mehr Teil des ursprünglichen Pakets sein, auf das der Benutzer wartet.

Kostenintensive Aufgaben nach der Antwort

Ein subtileres Problem tritt auf, wenn die Frontend-Plattform unmittelbar nach dem Empfang der Daten umfangreiche Verarbeitungen durchführt. Etwas Derartiges mag für sich genommen harmlos erscheinen:

const filteredUsers = users
  .filter(...)
  .sort(...)
  .map(...);

Bei einem kleinen Datensatz bemerkt niemand eine Verzögerung. Doch sobald dieselbe Logik auf 50.000 Datensätze angewendet wird, wird die Verlangsamung offensichtlich – und sie hat nichts mit der API zu tun. In solchen Fällen ist der Server überhaupt nicht langsam; der Browser ist einfach damit beschäftigt, Arbeiten zu verarbeiten, die ihm nach Abschluss der Anfrage zugeschickt wurden.

Den wahren Engpass finden statt zu raten

Der einzige zuverlässige Weg, herauszufinden, welches dieser Probleme tatsächlich für die Langsamkeit verantwortlich ist, besteht darin, Messungen durchzuführen anstatt Vermutungen anzustellen. Chrome DevTools und React DevTools können gemeinsam genau aufzeigen, wo die Zeit verbraucht wird:

Tab „Netzwerk“: Wie schnell reagiert die API tatsächlich?
Tab „Leistung“: Wo verbringt der Browser seine Zeit nach Erhalt der Antwort?
React DevTools: Welche Komponenten werden neu gerendert – und wie oft?
Lighthouse: Was beeinträchtigt konkret die Benutzererfahrung?
Paketanalysewerkzeug: Wie viel JavaScript wird tatsächlich an den Browser gesendet?

Ziel ist es nicht, jede Zahl zu reduzieren, die man finden kann – sondern den eigentlichen Engpass ausfindig zu machen, der für das langsame Gefühl verantwortlich ist.

Immer wenn eine React-Anwendung langsam wirkt, widerstehen Sie dem Impuls, zunächst den Backend-Bereich dafür verantwortlich zu machen. Fragen Sie sich, was nach der Antwort der API geschieht, denn diese Frage führt in der Regel direkt zum eigentlichen Problem. Oft hat der Backend-Bereich seine Arbeit bereits vor einer halben Sekunde abgeschlossen, und die Frontend-Anwendung hat einfach noch nicht mitgehalten.

Auch Organisationen haben solche versteckten Kosten

Das gleiche Prinzip – dass das, was nach dem offensichtlichen Schritt geschieht, am wichtigsten ist – gilt genauso stark für die Organisation einer Codebasis. Das Schreiben einzelner Komponenten ist selten der schwierige Teil beim Aufbau einer wachsenden React-Anwendung; vielmehr ist es wichtig, das gesamte Projekt übersichtlich zu halten. Nachdem im Laufe der Zeit verschiedene Ordnungsstrukturen ausprobiert wurden, hat sich eine nach Funktionen organisierte Struktur als am besten geeignet erwiesen – aus einem einfachen Grund: Alles, was mit einer bestimmten Funktion zusammenhängt, befindet sich an einem Ort. Das mag wie eine kleine Einzelheit klingen, doch ihr Wert wird deutlich, je größer die Anwendung wird.

Die Probleme bei der Gruppierung nach Dateityp

Viele Projekte beginnen mit einer Struktur, die Dateien nach ihrer Art unterscheidet:

src/
├── components/
├── hooks/
├── pages/
├── services/
├── utils/
└── types/

Zuerst wirkt das ordentlich. Doch je mehr sich das Projekt ausdehnt, füllen sich diese Ordner mit Hunderten unzusammenhängender Dateien. Angenommen, Sie müssen eine Änderung an einer Benutzerprofil-Funktion vornehmen – dann müssen Sie möglicherweise zwischen components/, hooks/, services/, types/ und utils/ wechseln, nur um alle betroffenen Teile zu erreichen. Alles, was mit dieser einen Funktion zusammenhängt, ist schließlich über das gesamte Projekt verstreut. Technisch funktioniert es zwar weiterhin, wird aber mit zunehmender Größe unintuitiv.

Gruppierung nach Funktion statt nach Typ

Die funktionsbasierte Struktur kehrt die Logik der Gruppierung um: Anstatt die Dateien nach ihrem Inhalt zu organisieren, werden sie danach geordnet, wozu sie gehören.

src/
└── features/
    ├── auth/
    │   ├── api/
    │   ├── components/
    │   ├── hooks/
    │   ├── types/
    │   └── index.ts
    │
    ├── profile/
    │   ├── api/
    │   ├── components/
    │   ├── hooks/
    │   ├── types/
    │   └── index.ts
    │
    └── dashboard/

Durch diese Struktur befindet sich alles, was mit einer Profilfunktion zusammenhängt – ihre Komponenten, Hooks, API-Aufrufe, Typen und Hilfsfunktionen – in einem einzigen Verzeichnis. Beim Arbeiten an dieser Funktion ist es fast nie notwendig, das Verzeichnis überhaupt zu verlassen.

Warum das in der Praxis klarer wirkt

Der eigentliche Vorteil liegt hier nicht in Skalierbarkeit oder architektonischer Reinheit – sondern in Klarheit. Das Öffnen des Verzeichnisses einer Funktion zeigt sofort, wo alles zu finden ist, ohne dass man innehalten und darüber nachdenken muss, wo ein bestimmter Hook platziert wurde, in welchem Verzeichnis sich ein bestimmter API-Aufruf befindet oder wo die Validierungslogik liegt. Alles befindet sich genau dort, wo man es erwarten würde, und diese kleine Vorhersehbarkeit führt täglich zu echter Zeitersparnis.

Die App erweitern, ohne Chaos zu verursachen

Die Hinzufügung eines neuen Moduls, wie z. B. Benachrichtigungen, wird dadurch einfach. Anstatt mehrere unzusammenhängende Verzeichnisse zu bearbeiten, erstellt man ein eigenständiges Ordnerpaket:

features/
└── notifications/
    ├── api/
    ├── components/
    ├── hooks/
    ├── types/
    └── index.ts

Dadurch bleibt die neue Funktion vollständig von den übrigen Teilen der Anwendung getrennt, sodass sich nichts verflicht. Wenn ein Projekt wächst, erweist sich diese Trennung als äußerst wertvoll.

Bessere Zusammenarbeit im Team

Auch bei der Arbeit mehrerer Personen am selben Codebasis-System eignet sich diese Struktur hervorragend. Ein Entwickler kann sich auf die Authentifizierung konzentrieren, ein anderer auf das Dashboard und wieder ein anderer auf Benachrichtigungen. Da jede Funktion ihre eigenen Dateien hat, ist es viel weniger wahrscheinlich, dass die Änderungen der einen Gruppe die der anderen überschreiben. Zudem wird die Code-Review vereinfacht, da Pull Requests in der Regel auf eine einzige Funktion beschränkt bleiben und nicht auf verstreute Dateien im gesamten Projekt eingreifen.

Eine Codebasis, die sich selbst erklärt

Beim Beitreten zu einem unbekannten Projekt ist die Ordnerstruktur oft das Erste, was es wert ist, genauer zu betrachten. Eine gut organisierte Struktur schafft schnell Vertrauen, und mit einem auf Funktionen basierenden Ansatz kann man bereits durch das Durchsehen der obersten Verzeichnisse erkennen, was eine Anwendung tatsächlich tut – die Struktur des Projekts erzählt somit im Grunde ihre eigene Geschichte.

Wann die Gruppierung nach Dateitypen noch sinnvoll ist

Das bedeutet keineswegs, dass eine auf Funktionen basierende Struktur in jeder Situation die richtige Wahl ist. Bei einem kleinen Projekt mit nur wenigen Seiten funktioniert die Gruppierung nach Dateitypen hervorragend, und das Hinzufügen einer weiteren Ordnerebene könnte lediglich Komplexität ohne wirklichen Nutzen verursachen. Die Vorteile einer auf Funktionen basierenden Organisation werden erst dann deutlich, wenn eine Anwendung größer wird, ihre Funktionen unabhängiger werden und mehr als ein Entwickler daran mitwirkt.

Zusammenfassung

Eine auf Funktionen basierende Ordnerstruktur ist nicht deshalb attraktiv, weil sie gerade im Trend liegt – sie ist attraktiv, weil sie ein wachsendes Projekt organisiert hält. Jede Funktion erhält ihren eigenen Platz, verwandte Dateien bleiben zusammen, und das Auffinden von Code ist nicht mehr eine lästige Aufgabe. Genau wie das Erkennen eines echten Leistungsengpasses bedeutet, über die schnelle Antwortzeit der API hinauszuschauen, bedeutet das Aufrechterhalten der Wartbarkeit eines Projekts, darüber hinauszuschauen, ob einzelne Komponenten funktionieren, und zu prüfen, ob die Gesamtstruktur im Laufe des Wachstums der Anwendung noch sinnvoll ist. Eine gute Ordnerstruktur, ähnlich wie ein gut diagnostiziertes Leistungsproblem, geht nicht nur um das Aussehen – sie dient dazu, weniger Zeit mit der Suche zu verbringen und mehr Zeit mit dem Entwickeln.