Tests, die im Browser laufen, liefern andere Ergebnisse als Tests, die Node.js simuliert. Das klingt selbstverständlich. Ist es aber nicht. Die React Testing Library, das De-facto-Standardwerkzeug für Komponententests in React-Projekten, führt Tests nicht im Browser aus. Sie läuft in Node.js und simuliert dort Browser-APIs wie den DOM. Das funktioniert für viele Szenarien, hat aber einen Haken: Es ist und bleibt eine Simulation. Was genau in einem echten Browser passiert, bleibt außen vor.
Der Vitest Browser Mode geht einen anderen Weg. Tests laufen direkt in echten Browsern – ähnlich wie bei Playwright. Der Unterschied zu Playwright: Dort testet man fertige Anwendungen als Blackbox, End-to-End. Der Vitest Browser Mode testet einzelne Komponenten, also Unit- und Integrationstests, aber im echten Browser-Kontext. Für Nils Hartmann, freiberuflicher Software-Entwickler und -Architekt aus Hamburg, ist das kein akademischer Unterschied. Die Testergebnisse werden schlicht realistischer.
Wer aus der React Testing Library kommt, muss übrigens kein komplett neues API lernen. Die Unterschiede sind überschaubar. Was sich ändert, ist die Laufzeitumgebung – und damit das Vertrauen in die Testergebnisse.
Schneller mit Server Side Rendering
Beim Thema Performance in Next.js hat Nils eine klare Einschätzung: Der größte Hebel ist oft, möglichst viel auf den Server zu verlagern. Server-seitiges Rendering beschleunigt die initiale Ladezeit erheblich, weil der Browser fertiges HTML bekommt statt eine JavaScript-Wüste, die er erst selbst zusammenbauen muss.
Next.js bringt dafür ein ausgefeiltes Caching-System mit. Ganze Seiten lassen sich cachen, einzelne Seitenbereiche ebenfalls. Im Build-Prozess können Seiten sogar vorgerendert werden, sodass der Server bei Anfragen fertige HTML-Dokumente ausliefert. Wer Daten aus mehreren Quellen gleichzeitig braucht, kann die Backend-Requests parallel abfeuern statt sie sequenziell abzuarbeiten.
Eine Frage drängt sich dabei aber auf: Wenn Next.js alles serverseitig vorrendert, auch interaktive Komponenten – ist das nicht doppelte Arbeit? Der Server rendert, der Browser rendert nochmal. Nils bejaht das, erklärt aber auch, warum Next.js diesen Kompromiss bewusst eingeht. Das Ziel ist eine blitzschnelle erste Darstellung. Wenn der Nutzer sofort etwas sieht, ist die oberste Prämisse erfüllt – auch wenn der Browser die Komponente kurz darauf nochmal rendert, um sie interaktiv zu machen. Im Optimalfall merkt der Nutzer davon nichts, weil das Client-seitige Render-Ergebnis dem serverseitigen entsprechen sollte.
Die Grenze zwischen Server- und Client-Komponenten zieht Nils nach einer einfachen Faustregel: Je mehr statischer Inhalt, desto eher ist es eine React Server Component. Je mehr Interaktivität gebraucht wird, desto eher muss die Komponente in den Browser. Technisch ist die Trennung simpel – use client ans Modul schreiben, fertig. Das Gefühl dafür, wann das wirklich sinnvoll ist, kommt mit der Erfahrung.
Du willst mehr von React, Next.js und Nils Hartmann erfahren. Dann komm auf die DWX 2026, 29. Juni bis 2. Juli 2026, Mannheim (https://www.developer-world.de/dwx). Hier spricht er über Moderne React Komponenten-Tests mit dem "Vitest Browser Mode" und High Performance Webapps mit Next.js.
Nils Hartmann ist freiberuflicher Software-Entwickler und -Architekt aus Hamburg. Seine Schwerpunkte sind die Entwicklung von Backend-Services mit Java sowie Frontend-Applikationen mit React. Er gibt Schulungen und Workshops zu diesen Themen und hat ein Buch über React geschrieben. Weitere Informationen und Kontakt: https://nilshartmann.net
