Zehn Jahre lang tendierte das React-Ökosystem in Richtung „Client-Side Everything“. Wir haben umfangreiche Single Page Applications (SPAs) erstellt. Wir haben Daten in „useEffect“ abgerufen. Wir haben 10 Spinner gezeigt, während sich die Wasserfälle auflösten. Und wir haben 500 KB JavaScript an einen Benutzer über eine 3G-Verbindung in Brasilien gesendet und uns gefragt, warum „Conversion“ niedrig war.

React Server Components (RSC) ist die Korrektur. Es ist nicht nur eine Funktion. Es ist ein grundlegender architektonischer Wandel, der den Schwerpunkt dorthin zurückverlagert, wo er hingehört: Das Rechenzentrum.

Bei Maison Code Paris haben wir umfangreiche E-Commerce-Plattformen auf Next.js App Router migriert. Das Ergebnis? 40 % weniger JavaScript, 2x schnelleres Largest Contentful Paint (LCP) und ein Entwicklererlebnis, das sich wie Schummeln anfühlt.

Warum Maison Code darüber spricht

Bei Maison Code Paris fungieren wir als das architektonische Gewissen unserer Kunden. Wir übernehmen oft „moderne“ Stacks, die ohne grundlegendes Verständnis für Skalierung gebaut wurden.

Wir diskutieren dieses Thema, weil es einen kritischen Wendepunkt in der technischen Reife darstellt. Die korrekte Implementierung unterscheidet ein fragiles MVP von einer widerstandsfähigen Plattform auf Unternehmensniveau.

Warum Maison Code auf RSC setzt

Wir jagen nicht jedem neuen Framework hinterher. Wir jagen Kunden-LTV. RSC ist die erste Architektur, die technische Leistung mit Geschäftszielen in Einklang bringt:

SEO: Perfekte HTML-Bereitstellung für Crawler (Google Bot liebt RSC).
Konvertierung: Schnellere „In den Warenkorb“-Interaktionen über die Optimistic-Benutzeroberfläche.
Nachhaltigkeit: Geringerer Batterieverbrauch auf Benutzergeräten durch Verlagerung der Berechnung in die Cloud. Wir schulen alle unsere Agenturpartner auf diesem Stack, denn darin liegt die Zukunft des High-Performance Commerce.

Das mentale Modell: Der Server als Komponentenbaum

In der alten Welt (Pages Directory oder Create-React-App) sendete der Server HTML und der Client „hydrierte“ Schlüsselfunktionen. In der RSC-Welt läuft React auf dem Server.

Wenn ein Benutzer „/product/123“ anfordert:

Der Server rendert „ProductPage“.
Es führt „await db.query()“ aus.
Es löst die Daten auf.
Es serialisiert das Ergebnis in ein spezielles Format (Flight Protocol).
Es streamt dies an den Browser.
Der Browser rendert die Benutzeroberfläche.

Entscheidend: Der Code für die Serverkomponente verlässt niemals den Server. Wenn Sie „moment.js“ (200 KB) in eine Serverkomponente importieren, um ein Datum zu formatieren, lädt der Benutzer 0 KB davon herunter. Sie sehen lediglich den Text „23. November 2025“.

Datenabruf: Tod von „useEffect“.

Die Ära der durch clientseitige Logik verursachten „Loading Spinners“ ist vorbei. Wir erstellen keine API-Routen mehr, nur um unser eigenes Frontend zu versorgen.

Das alte Muster (Client Fetch): „tsx // Client-Komponente Funktion Produkt() { const [data, setData] = useState(null); useEffect(() => { fetch(‘/api/product’).then(res => res.json()).then(setData); }, []);

if (!data) return ; return

{data.name}

; } „

Das neue Muster (RSC): „tsx // Serverkomponente import { db } aus ’@/lib/db’;

Exportieren Sie die standardmäßige asynchrone Funktion ProductPage() { // Direkter DB-Zugriff. Sicher. Schnell. const data = Warten auf db.product.findFirst();

return

{data.name}

; } „ Dies läuft im Backend. Die Daten warten auf den Benutzer, nicht umgekehrt.

Interaktivität: Die „Use Client“-Direktive

Aber statisches HTML ist langweilig. Wir benötigen Schaltflächen zum „In den Warenkorb“. Wir führen die Interaktivität mithilfe von Client-Komponenten wieder ein. Sie markieren eine Datei mit „Client verwenden“. Dadurch wird Next.js mitgeteilt: „Diese Datei in das JavaScript-Bundle aufnehmen.“

Kompositionsmuster: Die „Punkt“-Strategie. Machen Sie nicht die gesamte Seite zu einer Clientkomponente. Erstellen Sie die Blätter-Client-Komponenten.

„tsx // Serverkomponente (Layout) Exportieren Sie die standardmäßige asynchrone Funktion Page() { const product = waiting db.product.findFirst();

zurück (

{product.title}

{/* Null-Bundle-Größe /} {/ Null-Bundle-Größe /} {/ Client-Komponente (interaktiv) */}

); } „

Serveraktionen: Typsichere Mutationen

Wie reichen wir Formulare ein? „API-Routen“? „Axios“? „RUHE“? Nr. Serveraktionen. Wir schreiben eine Funktion, die auf dem Server läuft, und übergeben sie als Requisite an das Formular.

„tsx // Aktionen.ts ‘Server verwenden’

Asynchrone Funktion exportieren addToCart(formData: FormData) { const productId = formData.get(‘productId’); Warten Sie auf db.cart.create({ productId }); // Dem lokalen Cache mitteilen, dass er aktualisiert werden soll revalidatePath(‘/cart’); }

// Button.tsx import { addToCart } from ’./actions’;

Exportfunktion AddToCartButton() { zurück (

) } „

Dies funktioniert ohne aktiviertes JavaScript (progressive Verbesserung). Wenn JS geladen wird, fängt Next.js die Übermittlung ab und führt effektiv einen API-Aufruf durch. Aber es fühlt sich an, als würde man eine Funktion aufrufen.

Optimistische Benutzeroberfläche: „useOptimistic“.

Wenn der Benutzer auf „Hinzufügen“ klickt, möchten wir sofortiges Feedback. Wir wollen nicht auf den Server-Roundtrip warten. RSC führt „useOptimistic“ ein.

„tsx ‘Client verwenden’ import { useOptimistic } from ‘react’;

Exportfunktion LikeButton({ likeCount, action }) { const [optimisticLikes, addOptimisticLike] = useOptimistic( likeCount, (state, newLike) => state + 1 );

zurück ( <button onClick={async () => { addOptimisticLike(1); // Sofortiges UI-Update warte auf Aktion(); // Server-Hintergrundsynchronisierung }}> Gefällt mir: {optimisticLikes} ); } „

Die Caching-Hierarchie

Next.js implementiert aggressives Caching, um RSCs schnell zu machen. Das Verstehen dieser Hierarchie ist der schwierigste Teil der Lernkurve.

Memoisierung anfordern: Wenn Sie „getUser()“ im Layout und „getUser()“ auf der Seite aufrufen, dedupliziert Next.js es. Es wird nur einmal pro Anfrage ausgeführt.
Datencache: Das Ergebnis des „Abrufs“ wird auf der Festplatte des Servers gespeichert. Es bleibt über alle Anfragen hinweg bestehen. fetch('...', { next: { tags: ['products'] } })
Vollständiger Routen-Cache: Die gerenderten HTML- und Flugnutzdaten werden zur Erstellungszeit zwischengespeichert (statische Site-Generierung).
Router-Cache: Der Browser speichert besuchte Seiten 30 Sekunden lang im Speicher, um eine sofortige Vor-/Rückwärtsnavigation zu ermöglichen.

Ungültigkeit: Wenn Sie ein Produkt aktualisieren, müssen Sie „revalidateTag(‘products’)“ in Ihrer Serveraktion aufrufen. Dadurch werden Schicht 2 und Schicht 3 sofort gelöscht.

10. Partielles Vorrendering (PPR)

Statisch (SSG) ist schnell, aber veraltet. Dynamic (SSR) ist frisch, aber langsam. Next.js 14 führte PPR ein. Es handelt sich um das „Hole in the Donut“-Muster. Die Shell (Kopfzeile, Fußzeile, Seitenleiste) wird zum Zeitpunkt der Erstellung vorgerendert. Der „Produktpreis“ ist das Loch. Es wird dynamisch geladen. Der Benutzer erhält sofortiges HTML (The Shell) und den dynamischen Teilestream 100 ms später. Dies verhindert den „White Screen of Death“ bei Datenbankabfragen.

11. Streaming- und Spannungsgrenzen

RSC teilt die Seite in Abschnitte auf. return <Suspense fallback={<Skeleton />}><SlowComponent /></Suspense> Der Server sendet den HTTP-Header „Transfer-Encoding: chunked“.

Block 1: „…
… “.
(DB endet)
Block 2: „“. Diese Time To First Byte (TTFB) ist entscheidend für SEO und die wahrgenommene Leistung.

13. RSC vs. Inselarchitektur (Astro)

Astro hat „Inseln“ populär gemacht (statisches HTML + kleine Lücken in der Interaktivität). RSC ist ähnlich, aber anders.

Astro: Standardmäßig 0 JS versenden. Hydratieren Sie explizit „“.
RSC: Standardmäßig 0 JS versenden. Hydratkomponenten mit der Aufschrift „Use Client“. Der Unterschied ist der Router. Next.js verfügt über einen clientseitigen Router (SPA-Feeling). Astro verwendet die mehrseitige Navigation (klassisches Feeling). Für E-Commerce (bei dem es wichtig ist, den Warenkorbstatus über alle Seitenladevorgänge hinweg beizubehalten) ist das Next.js/RSC-Modell im Allgemeinen dem reinen MPA-Modell überlegen.

14. Staatsmanagement in einer RSC-Welt

Wohin geht Redux? Nirgends. Du brauchst es nicht. Wenn der Status „Serverdaten“ (Produkte, Benutzerprofil) lautet, befinden sie sich in der Serverkomponente (wird pro Anfrage abgerufen). Wenn der Status „UI State“ (Modal Open, Accordion Expanded) ist, befindet er sich in „useState“ innerhalb eines Client Component-Blatts. Wir verwenden Global State (Zustand/Context) nur für wirklich globale Kundendaten: Den Cart und Auth Token. Alles andere (90 % der alten Redux-Stores) wird gelöscht.

15. Fazit

React Server-Komponenten sind die größte Änderung in der Frontend-Entwicklung seit der Einführung von AJAX. Sie ermöglichen es uns, „MPAs (Multi-Page Apps) mit der Seele von SPAs“ zu erstellen. Wir erhalten die SEO, Leistung und Einfachheit des Server-Renderings. Wir erhalten die reichhaltige Interaktivität von React.

Für groß angelegten E-Commerce, bei dem jede Millisekunde Latenz mit dem Umsatz korreliert, ist RSC die einzig brauchbare Architektur für die nächsten fünf Jahre.

Migration zu Next.js?

Stecken Sie in einer langsamen Create-React-App fest?

Architect your Migration mit RSC. Beauftragen Sie unsere Architekten.