React-zu-Next.js-Migration

Eine Single-Page-Anwendung und eine Next.js-Anwendung haben nicht dieselbe Form. Die SPA rendert ein leeres div und füllt es aus dem Browser; Next.js rendert auf dem Server und schickt HTML. Alles, was diese Migration interessant macht, folgt aus diesem einen Unterschied - und nichts davon ist ein Verschieben von Dateien.

Das ist die Migration für Teams auf Create React App, Vite oder einem selbst gebauten React-Setup - nicht für Teams, die schon auf dem Pages Router sind; das ist ein anderes Problem mit einem anderen Weg.

Was sich tatsächlich ändert

Routing. Die komponentenbasierten Routen des React Routers werden ein Dateibaum. Aus <Route path="/products/:id"> wird app/products/[id]/page.tsx. Verschachtelte Routen mit gemeinsamem Rahmen werden verschachtelte Layouts, was meist einfacher ist als das, was da war.

Datenholen. Hier steckt der Großteil der Arbeit. Eine SPA holt in useEffect nach dem Mount - das heißt Spinner, Wasserfall und nichts, was ein Crawler lesen könnte. In Next.js läuft derselbe Fetch auf dem Server, bevor die Antwort rausgeht. Die Komponente hört auf, Ladezustände zu verwalten, und wird eine async-Funktion.

Das Bundle. In einer SPA ist per Definition alles Client-Code. Nach der Migration muss das Meiste davon keiner mehr sein - die Routen, die wir umziehen, verlieren typischerweise 40-60 % ihres JavaScripts, weil der Baum nur noch ausliefern muss, was wirklich interaktiv ist.

Browser-Annahmen. window, localStorage und document auf Modulebene stürzen auf dem Server ab. Sie zu finden ist mechanisch; zu entscheiden, welche in eine Client-Komponente gehören und welche nie nötig waren, ist die Urteilsfrage.

Die Reihenfolge, in der wir arbeiten

Next.js und Ihre SPA können während der Migration von derselben Domain ausliefern, es muss also nichts auf einmal passieren.

1. Die Hülle und eine Blattroute. Etabliert Layout, Metadaten-Helfer und Datenkonventionen an etwas mit wenig Risiko.
2. Die Routen, die Suchmaschinen interessieren. Marketingseiten, Produktseiten, alles Öffentliche. Hier liegt der Ertrag, denn genau diese Seiten hatten überhaupt kein serverseitig gerendertes HTML.
3. Authentifizierte Routen. Dashboards und Einstellungen. Oft bleiben die weitgehend clientseitig, und das ist richtig - hinter einem Login gibt es keinen SEO-Wert, und der App Router lässt sie gern interaktiv.
4. Der alte Build, gelöscht. Nicht vorher.

Was Sie erwarten dürfen

Die ehrliche Fassung: Der Performance-Gewinn ist real, aber ungleich verteilt, und der SEO-Gewinn ist meist der größere.

Der erste Paint einer SPA wartet darauf, dass das Bundle geladen, geparst und ausgeführt ist, bevor irgendetwas erscheint. Server-Rendering nimmt das vollständig aus dem kritischen Pfad, weshalb der LCP bei Erstbesuchen und kalten Caches am meisten springt und bei wiederkehrenden Nutzern mit warmem Cache am wenigsten.

Die SEO-Änderung ist kategorischer. Ein Crawler, der ein leeres div und ein Script-Tag bekommt, hat nichts zu indexieren. Nach der Migration bekommt er den Inhalt. Für Anwendungen, deren öffentliche Seiten unsichtbar waren, ist das keine Optimierung - es ist der Unterschied zwischen Existieren in den Suchergebnissen und nicht.

Was wir zuerst sehen müssen

Das Repository, oder eine Liste der Routen und dessen, was jede holt. Der Großteil der Schätzung steckt in der Datenschicht, nicht in der Zahl der Komponenten: Hundert präsentationale Komponenten konvertieren in einer Woche, und ein verhedderter globaler Store kann länger dauern als sie alle zusammen.