DWX hakt nach: Echte Browser statt Node.js-Simulation – Testing und Performance mit Vitest & Next.js
Nils Hartmann, freiberuflicher Software-Entwickler und -Architekt aus Hamburg, erklärt im DWX-Interview zwei Dinge, die im Frontend-Alltag regelmäßig für Frust sorgen: flaky Tests und langsame Web-Apps.
Beim Thema Testing räumt er mit einem verbreiteten Missverständnis auf: Wer mit der React Testing Library arbeitet, testet nicht im Browser, sondern in einer Node.js-Umgebung mit simulierten Browser-APIs. Der Vitest Browser Mode ändert das. Tests laufen dann in echten Browsern, was die Ergebnisse deutlich realistischer macht – ohne dass sich die API radikal von der React Testing Library unterscheidet.
Bei Next.js geht's um Performance-Muster, die wirklich etwas bringen: Server-seitiges Rendering, ausgefeiltes Caching auf Seiten- und Komponentenebene, parallele Datenabfragen.
Nils erklärt auch, warum Next.js selbst interaktive Komponenten erst auf dem Server vorrendert – und welchen Kompromiss das bedeutet.
Nils spricht auf der DWX 2026 in Mannheim.
DWX 2026 | 29. Juni bis 2. Juli 2026 | Mannheim
https://www.developer-world.de/dwx
Der Vitest Browser Mode bietet gegenüber klassischen Testing-Frameworks einen entscheidenden Vorteil: Tests werden nicht mehr nur in einer simulierten Umgebung ausgeführt, sondern direkt in einem echten Browser. Klassische Ansätze wie etwa die React Testing Library laufen in einer Node.js-Umgebung und stellen dort lediglich eine Simulation von Browser-Funktionalitäten bereit, beispielsweise für den DOM. Diese Simulation ist zwar praktisch, bildet aber nicht immer die tatsächlichen Bedingungen im Browser exakt ab.
Der Vitest Browser Mode verfolgt einen anderen Ansatz. Ähnlich wie Tools wie Playwright verlagert er die Tests in den echten Browser. Allerdings liegt der Fokus nicht auf End-to-End-Tests einer fertigen Anwendung, sondern auf dem Testen einzelner Komponenten. Die API ist dabei der React Testing Library sehr ähnlich, sodass der Umstieg leichtfällt. Der große Unterschied liegt jedoch in der Realitätsnähe der Testergebnisse, da die Ausführung direkt im Browser erfolgt.
In Bezug auf die Performance von Next.js-Anwendungen gibt es mehrere bewährte Strategien. Ein zentraler Hebel ist das serverseitige Rendering. Viele Aufgaben können auf dem Server ausgeführt werden, was zu einer sehr schnellen initialen Darstellung führt. Darüber hinaus bietet Next.js ausgefeilte Caching-Mechanismen: Ganze Seiten können gecacht oder sogar bereits im Build-Prozess vorgerendert werden. Zusätzlich ist es möglich, nur Teile von Seiten zu cachen, was besonders bei dynamischen Anwendungen interessant ist.
Ein weiterer wichtiger Aspekt ist die parallele Datenverarbeitung. Wenn eine Seite Daten aus mehreren Quellen benötigt, können diese Anfragen parallel ausgeführt werden, anstatt sie nacheinander abzuarbeiten. Das reduziert die Ladezeit erheblich. Insgesamt bietet Next.js eine hohe Flexibilität, sodass je nach Anwendungsfall unterschiedliche Muster sinnvoll kombiniert werden können.
Die Balance zwischen Client- und Server-seitigem Rendering ist in Next.js einerseits einfach, andererseits erfordert sie ein gewisses Gespür. Standardmäßig rendert Next.js alles zunächst auf dem Server vor – auch Komponenten, die später im Client interaktiv werden. Dadurch erhält der Nutzer sofort eine sichtbare Seite, ohne auf JavaScript-Ausführung warten zu müssen.
Die eigentliche Herausforderung liegt darin zu entscheiden, welche Teile wirklich im Client laufen müssen. Technisch ist das einfach: Mit der Kennzeichnung „use client“ wird eine Komponente als Client-Komponente definiert. Inhaltlich erfordert diese Entscheidung jedoch Erfahrung. Als Faustregel gilt: Je statischer der Inhalt, desto eher sollte er serverseitig gerendert werden. Je mehr Interaktivität benötigt wird, desto sinnvoller ist eine Ausführung im Client.
Dabei geht Next.js bewusst Kompromisse ein. Das Ziel ist eine möglichst schnelle erste Darstellung der Anwendung. Um dies zu erreichen, werden selbst Client-Komponenten zunächst serverseitig vorgerendert und als fertiges HTML ausgeliefert – oft sogar aus einem Cache. Das führt zu einer extrem schnellen initialen Anzeige. Anschließend rendert der Browser die Komponenten erneut, um sie interaktiv zu machen. Diese doppelte Verarbeitung ist ein Trade-off, bleibt für den Nutzer jedoch meist unsichtbar, da das visuelle Ergebnis identisch ist. Auf diese Weise entsteht eine Anwendung, die sofort sichtbar und kurz darauf vollständig interaktiv ist.