Next.js ist eine ausgezeichnete Wahl — für eine ganze Klasse von Projekten ist es trotzdem die falsche. Wer das nicht ausspricht, verkauft ein Framework als Religion. Und Entscheider, die schon eine Migration hinter sich haben, riechen die Lücke zwischen Versprechen und Realität auf zehn Meter.
Wir bauen Next.js-Anwendungen, betreiben sie self-hosted und pitchen sie auf Entscheiderebene. Genau deshalb dieser Artikel: Eine Technologie, deren Grenzen man nicht benennen kann, hat man nicht verstanden. Die ehrliche Antwort auf die Frage, wann Next.js falsch ist, macht die Empfehlung in allen anderen Fällen erst glaubwürdig. Es gibt drei Konstellationen, in denen ich abrate — und einen Fall, in dem ich mich selbst widerspreche. Wer die größere Landschaft sucht, in die diese Entscheidung gehört, findet sie in unserer Übersicht zur Frontend-Architektur für den Mittelstand.
Wann Next.js falsch ist: Overengineering für eine Marketing-Website
Die häufigste Fehlentscheidung ist nicht die teuerste, aber die sichtbarste: Next.js für eine reine Marketing-Website. Ein Dutzend Seiten, etwas Redaktion, ein Kontaktformular, kein eingeloggter Bereich, keine serverseitige Geschäftslogik. Für so etwas bringt Next.js Framework-Gewicht mit, das der Nutzer im Browser bezahlt.
Der technische Kern: Next.js ist ein React-Framework. Auch eine weitgehend statische Seite trägt Router- und Hydration-Code mit sich. Vergleichsblogs beziffern eine Next.js-Marketing-Site setup-abhängig auf grob 80–150 KB JavaScript, während Astro per Default 0 KB ausliefert und nur dort JavaScript nachlädt, wo eine Komponente tatsächlich interaktiv ist. Diese KB-Zahlen sind Faustregeln, keine Benchmark-Primärdaten — die Größenordnung stimmt aber. Astro erzeugt statisches HTML, hat keine Hydration-Pflicht und ist für content-lastige Seiten konzeptionell schlanker. Für eine Site, die planbar klein bleibt, ist das die ehrlichere Wahl.
Hier muss ich relativieren, sonst werde ich unfair. Next.js bietet selbst einen SPA- und Static-Modus, und die Server Components reduzieren das an den Browser gesendete JavaScript erheblich — nur mit 'use client' markierte Komponenten samt ihrem Import-Graphen landen überhaupt im Client-Bundle. Wer Next.js diszipliniert einsetzt, kommt deutlich näher an Astro heran, als die Rohzahlen suggerieren. Der Punkt ist nicht, dass Next.js langsam ist. Der Punkt ist, dass Sie für eine Aufgabe, die Astro mit weniger beweglichen Teilen löst, ein größeres Framework lernen, betreiben und über Versionen hinweg pflegen. Komplexität ist ein Kostenposten, auch wenn sie keine Lizenzgebühr hat.
Für redaktionell getriebene Seiten gibt es einen dritten Weg, den Entwickler gern übersehen: ein klassisches oder Headless-CMS, in dem Nicht-Entwickler ohne Deploy-Pipeline Inhalte pflegen. Die Frage, ob Sie eine Plattform oder eine Publikation bauen, entscheidet mehr als jedes Framework-Benchmark. Wer den Unterschied zwischen einem Content-System und einer Experience-Plattform sauber zieht, trifft die Architektur fast von allein — dazu haben wir an anderer Stelle ausführlicher geschrieben, etwa zum Unterschied zwischen CMS und DXP.
Next.js Nachteile: Breaking Changes als realer Kostenposten
Der zweite Grund, abzuraten, steht nirgends im Verkaufsprospekt: Next.js hat einen aktiven Entwicklungszyklus mit echten Breaking Changes. Das ist kein Vorwurf — ein Framework, das sich bewegt, bleibt relevant. Aber Bewegung kostet, und diese Kosten landen in Ihrem Wartungsbudget, nicht im Marketing.
Konkret: Mit Version 15 wurden cookies, headers, params und searchParams asynchron, React 19 wurde Pflicht, und fetch wird nicht mehr standardmäßig gecached. Mit Version 16 wurde der synchrone Zugriff auf diese Request-APIs vollständig entfernt, Node.js 20.9+ wurde Pflicht, Turbopack der Default — ein Build mit eigener webpack-Konfiguration bricht ohne das Flag --webpack schlicht ab. Dazu geänderte next/image-Defaults und weitere Anpassungen. Das ist kein Drama pro Release, aber es summiert sich: Wer eine Next.js-Anwendung über drei, vier Jahre betreibt, fährt regelmäßige Upgrade-Wartung ein, die ein statischer Astro-Build oder ein gehostetes CMS so nicht kennt.
Ein verbreiteter Irrtum gehört hier korrigiert, weil er die Diskussion oft vergiftet: Next.js 16 schafft die Middleware nicht ab. Sie wird zu proxy umbenannt und deprecated, läuft dann auf der Node.js-Runtime. Wer die Edge-Runtime braucht, kann laut Dokumentation weiterhin middleware nutzen. Wer Ihnen erzählt, Middleware sei "weggefallen", hat das Changelog nicht gelesen. Sauberkeit bei solchen Details ist der Unterschied zwischen einer Risikobewertung und einem Stammtisch.
Was kostet die App-Router-Migration wirklich?
Die größte unterschätzte Position ist die App Router Migration. Viele Teams sind 2023 und 2024 mit der Erwartung gestartet, der Wechsel vom Pages Router sei ein Konfigurationsthema. Er ist es nicht.
Next.js empfiehlt selbst eine inkrementelle, seitenweise Migration und spricht in der eigenen Migrationsdoku offen von neuen Konzepten, Mentalmodellen und Verhaltensänderungen, die zu lernen sind. Das ist Herstellersprache für: Das ist Arbeit. Erzwungen werden unter anderem getServerSideProps und getStaticProps zu async Server Components, getStaticPaths zu generateStaticParams, _app und _document zu app/layout.js, next/head zur Metadata-API, pages/api zu Route Handlers und next/router zu next/navigation. Jede dieser Zeilen ist im Vorbeigehen erklärt — in einer gewachsenen Codebase ist jede davon Refactoring mit Testbedarf.
Reale Berichte bestätigen das. Ein Engineering-Team beschrieb den Parallelbetrieb von Pages und App Router als langwierig, musste das Error-Handling komplett auf Error Boundaries umstellen und konnte die zuvor genutzte Runtime-Config nicht mehr verwenden. Das mentale Modell des RSC-Cachings — wann etwas statisch, dynamisch oder revalidiert ist — ist die eigentliche Lernkurve, nicht die Syntax. In einer vielbeachteten GitHub-Diskussion votierte von über 2.000 Teilnehmern eine deutliche Mehrheit für den Pages Router. Diese Umfrage ist selbstselektierend, meinungsstark und teils durch neuere Versionen überholt — als Mehrheitsbeleg taugt sie nicht. Als Signal, dass der Umstieg Reibung erzeugt hat, ist sie ernst zu nehmen.
Für Sie als Entscheider heißt das: Wenn ein Dienstleister eine Next.js-Migration ohne eigenen Posten für die Router-Umstellung kalkuliert, prüfen Sie nach. Eine saubere Erstimplementierung eines self-hosted Next.js-Stacks liegt bei uns einmalig im Bereich 5.000 bis 20.000 Euro; eine Migration mit substanziellem Pages-Router-Bestand kann darüber hinausgehen, weil sie Refactoring statt Neubau ist. Wer in 90 Tagen vom Pitch zum Go-Live will, plant solche Umbauten ein, statt sie zu entdecken — wie das in der Praxis aussieht, haben wir am Weg vom Pitch zum Go-Live beschrieben.
Wann ist Next.js für ein Team die falsche Wahl?
Der dritte Fall ist eine Hiring-Frage, keine Tech-Frage. Next.js ist React. Wer ein Team hat, das in einem anderen Stack zu Hause ist — Vue, klassisches Server-Side-Rendering, eine Java-Welt — zahlt die Lernkurve zweimal: einmal beim Aufbau, einmal dauerhaft im Betrieb.
Die Marktlage spricht zwar für React. In der Stack Overflow Developer Survey 2025 nutzte ein gutes Drittel bis knapp die Hälfte der Befragten React, deutlich mehr als Angular, und bei professionellen Entwicklern liegt React noch klarer vorn. Die Entwicklerverfügbarkeit ist also strategisch auf der React-Seite. Aber Marktdurchschnitt hilft Ihrem konkreten Team nicht, wenn es heute kein React kann. Ein Framework einzuführen, dessen Mentalmodell — Server vs. Client Components, Caching-Verhalten, Hydration — niemand intern trägt, erzeugt einen Vendor-Lock-in beim Dienstleister, den man selten einkalkuliert. Sie kaufen dann nicht nur Code, Sie kaufen die Notwendigkeit, diesen Dienstleister zu behalten.
Und es gibt die Budget-Grenze. Self-hosting auf Hetzner ist DSGVO-konform in Deutschland ab grob 20 bis 50 Euro im Monat möglich, der Betrieb kostet zwei bis fünf Stunden monatlich für Updates, Monitoring und Backups. Das ist günstig — aber es ist Betriebsverantwortung. Für ein Kleinstprojekt mit knappem Budget ist genau das ein schlechter Tausch: Die eingesparten Plattformkosten werden von der Betriebszeit aufgefressen, und der genuin schwierige Teil von Next.js self-hosted — das ISR-Caching über mehrere Instanzen mit einem Custom cacheHandler — wird bei kleinen Setups selten gebraucht, will aber trotzdem verstanden sein, sobald man skaliert. Die ganze Abwägung zwischen Plattform und Eigenbetrieb haben wir im Vergleich Next.js auf Hetzner statt Vercel ausgebreitet.
Der unbequeme Punkt: Manchmal nehme ich Next.js trotzdem
Jetzt widerspreche ich mir, und das absichtlich. In mehreren der Fälle, in denen Next.js nach diesen Kriterien falsch aussieht, würde ich es trotzdem wählen.
Nehmen Sie die "einfache" Marketing-Website. Die wächst erstaunlich oft. Aus den fünf Seiten wird ein Kundenportal, aus dem Kontaktformular ein Login, aus der Publikation eine Plattform. Wer früh den Astro- oder Baukasten-Pfad gewählt hat, zahlt diese Wette dann mit einer Migration nach — und eine Migration nach drei Jahren Wachstum ist teurer als das anfängliche Overengineering je war. Die Wette auf das React- und Next.js-Ökosystem kann bei genau dem Projekt richtig sein, das heute zu klein dafür wirkt.
Dazu kommen Hiring und Anschlussfähigkeit. Für React finden Sie Entwickler, Bibliotheken, Patterns und Antworten. Das ist ein realer Wert, der eine momentane Lernkurve übersteigt. Wenn ich zwischen dem theoretisch passenderen Nischen-Tool und dem Framework wähle, für das ich in zwei Jahren noch Leute finde, gewinnt oft das Ökosystem — auch gegen meine eigene Overengineering-Kritik. Performance ist dabei selten das Gegenargument: Mit Server Components und ISR liefert ein sauber gebautes Next.js gute Core Web Vitals, die am Ende auf Conversion und Umsatz durchschlagen.
Die Grenze ist deshalb keine Formel. Sie ist eine Abwägung von Zeithorizont und Team. Ein Wegwerf-Projekt mit fixem Scope und einem Vue-Team: nicht Next.js. Eine Plattform mit unklarem Wachstum, einem React-affinen Team und einem Horizont von Jahren: fast immer Next.js, auch wenn sie heute klein startet.
Was ich Entscheidern rate
Stellen Sie zwei Fragen, bevor Sie Next.js bestellen oder ablehnen. Erstens: Wächst das hier? Wenn die Antwort ein ehrliches Nein ist — ein Kampagnen-Microsite, eine Broschüre, ein Projekt mit Enddatum — nehmen Sie Astro, Vite oder ein CMS und sparen sich Framework und Migrationsrisiko. Zweitens: Wer trägt das? Wenn niemand im Haus React kann und niemand es lernen soll, kaufen Sie sich mit Next.js einen Vendor-Lock-in, der teurer ist als jede Lizenz.
Sagen alle Beteiligten zu beidem Ja — es wächst, und wir können oder wollen React tragen — dann ist Next.js fast immer richtig, und die Breaking Changes und die Migration sind ein eingepreister Wartungsposten, kein Ausschlussgrund. Misstrauen Sie jedem Dienstleister, der Ihnen Next.js für alles verkauft, und ebenso jedem, der es pauschal verteufelt. Die richtige Antwort hat ein Datum, ein Team und einen Zeithorizont. Wer Ihnen die Grenzen nennt, hat verstanden, was er empfiehlt — und genau dem würde ich glauben.
