Alle paar Monate taucht dieselbe Diskussion auf Hacker News, X oder LinkedIn auf: „Next.js skaliert nicht." „Next.js ist schlecht für SEO." „Wir haben unser Next.js-Produkt neu geschrieben, weil die Performance eingebrochen ist." In den meisten dieser Post-mortems ist die Schlussfolgerung falsch. Next.js ist selten die Ursache — es ist die Oberfläche, an der ein Architekturproblem endlich sichtbar wird. Das Framework hat das System nicht langsam gemacht; es hat nur aufgehört zu verbergen, dass es das immer war. Dieser Leitfaden zeigt, wo Next.js-Projekte tatsächlich scheitern, warum ein Framework-Rewrite denselben Schmerz meist reproduziert, und wie eine Next.js-Architektur aussieht, die Wachstum überlebt.
Die wichtigsten Punkte
| Punkt | Details |
|---|---|
| Das Framework ist der Bote | Next.js bricht keine Produkte — es verstärkt die Entscheidungen darunter. Gute Architektur → außergewöhnliche Ergebnisse; schlechte → spektakuläres, sichtbares Scheitern. |
| „Next.js ist langsam" = meist Daten-Orchestrierung | Hoher TTFB lässt sich fast immer auf synchrones, unbegrenztes Dependency-Fetching im Render zurückführen — nicht auf SSR selbst. |
| Frontend-als-Backend ist der stille Killer | Pricing, Permissions und Workflows in Components erzeugen untestbare, nicht wiederverwendbare Systeme, die beim zweiten Client zusammenbrechen. |
| Rewrites reparieren selten Architektur | Ein Framework-Wechsel ändert Syntax, nicht Grenzen. Sechs Monate später sind dieselben Probleme zurück — abzüglich Kontext und Velocity. |
| Next.js belohnt System-Denken | Klare Grenzen, explizites Caching und bewusstes Rendering machen es vom Risiko zum Multiplikator. |
Das Framework ist der Bote — nicht die Ursache
Next.js bekommt die Schuld, weil es sichtbar ist. Architekturfehler sind es nicht. Wenn Performance leidet, Kosten explodieren oder SEO stagniert, sind die einfachen Ziele: „SSR ist zu langsam", „React ist zu schwer", „Edge ist overhyped", „der App Router ist instabil". Aber Frameworks brechen Produkte nicht automatisch — sie verstärken die Konsequenzen der Entscheidungen darunter.
Das ist das Modell, das sich lohnt: Next.js wirkt wie ein Multiplikator. Gute Architektur produziert außergewöhnliche Ergebnisse; schlechte Architektur produziert spektakuläres, sichtbares Scheitern. Deshalb lieben oder hassen Teams es, mit wenig dazwischen — das Framework spiegelt dir einfach das System zurück, das du tatsächlich gebaut hast.
Die echten Gründe, warum Next.js-Projekte scheitern
1. Next.js wie einen statischen Website-Builder behandeln
Der häufigste Fehler: Next.js als Page-Renderer statt als System-Framework zu benutzen — Business-Logik in React-Components, Data Fetching über alle Pages verteilt, keine Domänentrennung, keine Backend-Grenze. Das funktioniert für Marketing-Websites, Demos und Wegwerf-MVPs. Es bricht, sobald du Berechtigungen, Workflows, Integrationen, nicht-trivialen State oder verlässliche Analytics brauchst. Dann wird das Frontend leise zum Backend — und kollabiert unter seinem eigenen Gewicht. Next.js setzt Architektur voraus; wenn du keine hast, zeigt es das deutlich.
2. Server-Side Rendering ohne Server-Side-Denken
SSR ist keine Magie — es ist Code, der auf einem Server läuft. Trotzdem sieht man oft 5–10 API-Calls pro Request, schwere Transformationen im Render-Pfad, Blockieren auf Third-Party-Services und eine chaotische Mischung aus sync und async Logik. Das Ergebnis: hoher TTFB, instabile Performance und zufällige Latenz-Spikes, die unter „Next.js ist langsam" verbucht werden.
Das Problem ist fast nie SSR. Es ist synchrone Orchestrierung unbegrenzter Abhängigkeiten. Die Lösungen sind architektonisch: klare Data Contracts, explizite Caching-Layer, Async-Grenzen und progressives Rendering. Modernes Next.js liefert die Werkzeuge — Streaming mit Suspense schickt die statische Shell sofort, während langsame Daten im Hintergrund auflösen, sodass Nutzer schnell sinnvollen Inhalt sehen, selbst wenn ein Query Sekunden braucht. Ohne diese Disziplin würde jedes SSR-Framework kämpfen. Next.js macht die Kosten nur sichtbar.
3. Keine Trennung zwischen Produktlogik und Delivery-Layer
Ein weiterer stiller Killer ist frontend-getriebene Produktlogik: Pricing-Regeln in Components, Permission-Checks in Hooks, Workflows als UI-State, „temporäre" Logik, die bleibt. Das macht Testen nahezu unmöglich, zerstört Analytics, dupliziert Regeln und erzeugt permanenten Rewrite-Druck. An dem Tag, an dem eine Mobile App, eine Partner-API, Background Jobs oder AI-Workflows dazukommen, bricht alles — nicht wegen Next.js, sondern weil es nie einen wiederverwendbaren Produktkern gab. Dasselbe Coupling macht aus Technical Debt ein Business-Problem statt eines Dev-Problems.
4. Edge und App Router ohne Strategie einsetzen
Edge und der App Router sind beide mächtig — und beide werden zur Falle, wenn man sie blind einsetzt. DB-Queries am Edge, Edge dort, wo starke Konsistenz zählt, eine unklare Mischung aus static, dynamic und streaming, falsch verstandene Caching-Semantik: all das führt zu unvorhersehbaren Daten, Debugging-Albträumen und Infra-Kosten, die Finance nervös machen. Edge ist kein „schnelleres Serverless"; es ist ein anderes Execution-Modell mit anderen Trade-offs. Bewusst eingesetzt ist es ein echter Hebel — Logik am Edge kann den TTFB für internationale Zielgruppen um bis zu 50 % senken — aber nur, wenn du dafür designst.
5. SEO beschuldigen, obwohl die Content-Architektur kaputt ist
Next.js wird regelmäßig als „SEO-Problem" dargestellt. In der Praxis sehen wir fehlende Informationshierarchie, dünne Pages, duplizierte Templates, JS-lastige Navigation ohne semantische Struktur und Pages, die für Code-Reuse statt für Search Intent existieren. Google rankt keine Frameworks — Google rankt Systeme. Wenn SEO scheitert, liegt es meist daran, dass Rendering-Strategie und Content-Strategie nie aufeinander abgestimmt wurden. Das ist ein Architekturproblem im SEO-Kostüm, und genau deshalb sind die „SEO-Kosten von JavaScript-Frameworks" größtenteils ein Mythos, sobald die Struktur darunter stimmt.
Pro-Tipp: Bevor du das Framework beschuldigst, instrumentiere es. Setz einen Server-Timing-Header, der TTFB in „Data Fetch" vs „Render" vs „Third-Party-Wait" zerlegt. In neun von zehn Fällen ist die Zahl, die dich umbringt, ein Dependency-Call, den du cachen, parallelisieren oder hinter eine Suspense-Grenze schieben kannst — nicht die Render-Kosten des Frameworks.
Die Rewrite-Falle: „Lasst uns das Framework wechseln"
An diesem Punkt greifen viele Teams zur teuersten verfügbaren Option: einem Rewrite. React → Vue. Next.js → Astro. SSR → SSG. Monolith → Microservices, viel zu früh. Sechs Monate später sind dieselben Probleme zurück, die Velocity ist gesunken, Kontext ist verloren und die Moral am Boden — weil sich die Architektur nie geändert hat, nur die Syntax.
Framework-Rewrites sind oft architektonische Vermeidung, die wie Fortschritt aussieht. Der ehrliche Schritt ist, zuerst die Grenzen im bestehenden Stack zu reparieren; ein Rewrite, der die Struktur des Systems nicht ändert, verschiebt den Schmerz nur. Das ist genau die Dynamik hinter warum Rewrites Startups töten — und warum Geschwindigkeit ohne Architektur eine Falle ist.
Was in der Praxis wirklich funktioniert
High-performende Next.js-Produkte teilen meist dieselben Eigenschaften, und keine davon hat mit der Framework-Wahl zu tun:
- Klare Systemgrenzen — Frontend ≠ Backend, UI ≠ Domain-Logik, Rendering ≠ Orchestrierung.
- Modulare Architektur — domänengetriebene APIs, vorhersehbare Datenflüsse, austauschbare Komponenten. Ein gut strukturierter modularer Monolith schlägt verfrühte Microservices fast immer.
- Performance by Design — explizites Caching, bewusste Async-Grenzen, SSR nur dort, wo es Wert schafft. Nicht-interaktive Komponenten auf dem Server zu lassen kann Client-seitiges JavaScript um bis zu 70 % reduzieren — und genau da entstehen die meisten schlechten Time-to-Interactive-Werte.
- Analytics als First-Class-System — server-seitiges Tracking, sauberes Event-Modell, keine UI-gekoppelten Metriken.
- Growth-fähige Foundations — Auth, Permissions, Integrationen, CI/CD und Monitoring eingeplant, nicht nachgerüstet.
Das ist kein Overengineering. Das ist Engineering, das Erfolg überlebt — derselbe Übergang, den jedes Produkt auf dem Weg vom MVP zu 100k Usern durchläuft.
Warum Next.js schlechte Architektur schneller entlarvt als andere Stacks
Der unbequeme Teil: Next.js ist ehrlich. Es versteckt Latenz, Coupling, schlechte Datenzugriffe und unklare Verantwortlichkeiten nicht. Ältere client-lastige Stacks maskieren diese Probleme — alles passiert client-seitig, Performance-Probleme werden verschoben, SEO-Fehler werden Marketing zugeschoben. Next.js zwingt dich, die Realität früh zu sehen, solange sie noch billig zu beheben ist. Das ist ein Feature, kein Bug — vorausgesetzt, du behandelst das, was es aufdeckt, als Signal statt als Beleidigung.
Meine Sicht: Das Framework ist selten die entscheidende Entscheidung
Über die Jahre habe ich denselben Zyklus immer wieder gesehen: ein „schnell" gebautes MVP, echte Traktion, das System beginnt zu brechen, und dann eine Rewrite-Diskussion, die das Framework zum Schuldigen macht. Fast jedes Mal ist das Framework der einzige Teil des Stacks, der seinen Job tut. Kaputt ist die Grenze zwischen Delivery und Domäne — und ein neues Framework erbt diese kaputte Grenze ab Tag 1.
Die Teams, die Next.js ohne Reue skalieren, sind nicht die mit dem angesagtesten Stack. Es sind die, die Next.js als Delivery-Layer über einem auf Wachstum ausgelegten System behandelt haben und die bei einem Performance-Einbruch fragten „Was sagt uns das über unsere Architektur?" statt „Worauf sollten wir wechseln?". Dieser eine Reframe ist mehr wert als jede Framework-Migration.
— Anna
Architektur bauen, die Wachstum überlebt
Wenn du Next.js-Performance-Probleme, Skalierungsschmerz oder einen verlockenden Rewrite hast, liegt das Problem meist an der Architektur — nicht am Framework. Bei H-Studio nutzen wir Next.js als Delivery-Layer über einem auf Wachstum ausgelegten System, mit klaren Grenzen zwischen Frontend und Backend, explizitem Caching und DevOps-Fundamenten von Tag 1.
Sieh dir an, wie wir EventStripe bei High-Load-SSR und Skalierung geholfen haben, oder wie Modelplace.ai einen Architektur-first-Ansatz gewählt hat. Wenn der Schmerz als Sichtbarkeit auftaucht, ist es meist Content-Architektur und Technical SEO, nicht das Framework. Ein Architecture Sprint ist ein schneller, strukturierter Weg herauszufinden, was es ist, bevor du dich auf einen Rewrite festlegst.
FAQ
Ist Next.js schlecht für Skalierung?
Nein. Next.js skaliert gut, wenn das System darunter klare Grenzen und explizite Daten- und Caching-Strategien hat. Skalierungsprobleme lassen sich fast immer auf Architektur zurückführen — frontend-getriebene Produktlogik, synchrone Dependency-Orchestrierung, fehlendes Caching — nicht auf das Framework selbst.
Warum ist mein Next.js-SSR langsam?
Die übliche Ursache ist synchrone Orchestrierung unbegrenzter Abhängigkeiten: viele sequenzielle API- oder DB-Calls und schwere Transformationen im Render. Behebe es mit klaren Data Contracts, Caching, parallelisiertem Fetching und Streaming mit Suspense, sodass die statische Shell sofort ausgeliefert wird, während langsame Daten auflösen.
Sollten wir auf ein anderes Framework umschreiben, um Performance zu fixen?
Selten. Ein Rewrite ändert Syntax, nicht Architektur, also tauchen dieselben Probleme nach Monaten verlorener Velocity wieder auf. Repariere zuerst die Grenzen — trenne Domain-Logik von Delivery, mach Caching explizit — in deinem aktuellen Stack.
Schadet Next.js dem SEO?
Nicht von sich aus. Google rankt Systeme, nicht Frameworks. SEO-Probleme kommen meist von dünnen Pages, fehlender Informationshierarchie, duplizierten Templates und Rendering, das nicht zur Content-Strategie passt — alles architektonisch, alles ohne Framework-Wechsel behebbar.
Wann ist Next.js die falsche Wahl?
Wenn du wirklich etwas brauchst, wofür Next.js nicht gebaut ist — aber das ist viel seltener als behauptet. Die meisten Teams, die Next.js „entwachsen", sind in Wahrheit ihrer Architektur entwachsen und würden dieselben Einschränkungen in jedes Framework mitnehmen, zu dem sie wechseln.
Weiterführende Artikel
- Warum Rewrites Startups töten — der Failure-Mode, zu dem der Framework-Wechsel-Instinkt führt
- Warum Geschwindigkeit ohne Architektur eine Falle ist — wie „schnelle" MVPs die Schuld anhäufen, die später dem Stack gegeben wird
- Monolith vs. Microservices: was wirklich funktioniert — Grenzen wählen, bevor du eine Topologie wählst
- Die SEO-Kosten von JavaScript-Frameworks: Mythos vs. Realität — warum „schlecht für SEO" meist ein Content-Architektur-Problem ist
Lektoriert und faktengeprüft von Anna Hartung