Next.js 15.1+ ist außerhalb von Vercel faktisch nicht nutzbar

• Seit Next.js 15.1.8 wurde die Art der Metadatenverarbeitung geändert, was in Deployment-Umgebungen außerhalb von Vercel zu schwerwiegenden Problemen führt
  • Metadaten werden nicht mehr direkt im HTML-head gerendert, sondern separat über sogenanntes „Metadata Streaming“ übertragen
• Wenn Suchmaschinen kein JavaScript ausführen, werden Metadaten überhaupt nicht sichtbar, wodurch SEO massiv beschädigt wird
  • Es gibt zwar eine Ausnahmebehandlung über Crawler-Erkennung (htmlLimitedBots), diese ist aber nicht perfekt
• Nicht-Vercel-Anbieter wie Netlify, Cloudflare und AWS versuchen mit OpenNext Kompatibilität herzustellen, tatsächlich ist Next.js aber so stark an die Vercel-Infrastruktur gebunden, dass das Portieren selbst schwierig ist und viele Bugs auftreten
• Selbst bei statischen Builds werden Metadaten nicht im HTML-head enthalten, wodurch alle Deployment-Umgebungen zu komplexer Crawler-Erkennung bzw. JavaScript-Ausführung gezwungen werden
• Sicherheitsproblem (kritische Schwachstelle, im März 2025 veröffentlicht)
  • Wer an älteren Versionen festhält, um Metadata Streaming zu vermeiden, setzt sich schweren Sicherheitslücken aus (ein Patch wurde erst in 15.2.3 bereitgestellt)
• Metadata Streaming verdeckt in der Praxis Performance-Probleme und wirkt sich zusätzlich negativ auf SEO aus
• Fazit:
  Next.js wirkt wie Open Source, ist aber faktisch zu einem Framework mit starker Vercel-Abhängigkeit geworden; für neue Projekte ist es sinnvoll, andere Optionen in Betracht zu ziehen

---

Überblick

• Seit Version 15.1.8 von Next.js gibt es in Umgebungen außerhalb von Vercel schwerwiegende Probleme bei der Verarbeitung von Metadata
• Das führt letztlich zu einer vertieften Abhängigkeit von der Vercel-Infrastruktur, zu einer Verschlechterung der Suchmaschinenoptimierung (SEO) und sogar zu Sicherheitsrisiken

Der Beginn des Problems: die Einführung von Metadata Streaming

• 2024 führte Vercel die experimentelle Funktion Metadata Streaming ein
• Anders als bisher werden Metadata (Tags wie title, description, Open Graph usw.) nicht direkt im HTML `` gerendert, sondern erst nach dem initialen Laden der Seite separat übertragen
• Diese Funktion setzt die Ausführung von JavaScript voraus

Vercels technische Erklärung und die praktischen Probleme

• Hintergrund der Einführung: Beseitigung eines Rechen-Bottlenecks bei der Erzeugung von Metadata
• In der Praxis sind Metadata jedoch meist statisch und klein (unter 1 KB)
• Die Kosten eines Server-Round-Trips sind höher als eine Inline-Verarbeitung
• Dynamische Metadata sind nur in sehr wenigen Ausnahmefällen relevant
• Die Implementierung von Metadata Streaming erhöht Komplexität und Verwirrung

Hintergrund der Performance-Probleme

• Einige Entwickler stießen etwa bei der Anbindung externer APIs auf Performance-Probleme durch verzögerte Metadata-Erzeugung
• Um dieses Problem zu lösen, entwickelte Vercel den Streaming-Ansatz

Suchmaschinen-Crawler und die Auswirkungen auf SEO

• Suchmaschinen, die kein JavaScript ausführen, können die Metadata nicht lesen
• Das hat erhebliche negative Auswirkungen auf SEO
• Als Gegenmaßnahme bietet Vercel die Funktion htmlLimitedBots, bei der der Server bei erkannten Crawlern das Streaming überspringt und Metadata im HEAD einfügt

Grenzen anderer Cloud-Anbieter

• Netlify, Cloudflare, AWS und andere haben zur Kompatibilität mit Next.js ein Adapter-Projekt namens OpenNext geschaffen
• Da Next.js jedoch zu eng an Vercel gebunden ist, erfordert die Portierung Reverse Engineering
• Wegen Qualitätsproblemen bei OpenNext funktioniert das in der Praxis nicht zuverlässig

Selbst statische Builds sind unvollständig

• Selbst bei statischen Site-Builds (Static Build) werden Metadata nicht mehr in den HTML-head aufgenommen
• Da sie zusammen mit React Server Components gebündelt werden, ist die Ausführung von JavaScript erforderlich
• Für grundlegende HTML-Metadaten muss man sogar selbst Crawler-Erkennungslogik implementieren, was eine unzumutbare Situation schafft

Kritische Sicherheitslücke und Update-Probleme

• Am 21. März 2025 wurde eine kritische Schwachstelle (Sicherheitsgrad 9.1, GHSA-f82v-jwr5-mffw/CVE-2025-29927) veröffentlicht
• Über die Manipulation bestimmter Header kann damit die Authentifizierungsabsicherung der Middleware umgangen werden
• Der Patch wurde in Next.js 15.2.3 eingespielt; wer jedoch auf 15.1.8 bleibt, um Metadata Streaming zu vermeiden, ist sicherheitstechnisch stark gefährdet

Negative Folgen der Einführung von Streaming

• Metadata Streaming verdeckt verborgene Performance-Probleme noch stärker
• Verzögerungen bei der Verarbeitung von Seiten-Metadaten werden von realen Nutzern nicht unmittelbar wahrgenommen
• Suchmaschinen-Crawler vergeben bei langsamen Antworten SEO-Punktabzüge

Fazit

• Next.js hat sich zu einem als Open-Source-Framework getarnten Vercel-Vendor-Lock-in entwickelt
• Bei der Wahl des Tech-Stacks für das nächste Projekt ist es klüger, andere Frameworks statt Next.js in Betracht zu ziehen

[kansm]

Dann wäre Remix die Alternative, oder?

[bth15923]

Wie im Text erwähnt: übermäßiger Vendor Lock-in, ein Verhalten, das zu sehr einer Blackbox gleicht, und APIs, die nicht intuitiv sind. Dazu kommt, dass auch React diese Art der serverseitigen Entwicklung ganz offen so vermarktet, als wäre sie der Standardweg der Entwicklung mit React. Für die meisten Apps reicht meiner Meinung nach eine Vite-basierte SPA völlig aus.

[pcj9024]

Dass es zu einem gewissen Grad zu Vendor Lock-in kommt, kann man durchaus anerkennen, aber die Meinungen zur Next.js-Technologie selbst wirken, wenn man sie einfach liest, kaum mehr als ein "Ich habe keine Lust, den Artikel zu lesen".

[ndrgrd]

Sie taten schon lange so, als wären sie offen, während sie in Wahrheit einen verschlossenen Kurs verfolgten — und jetzt haben sie die Tür am Ende fast komplett verriegelt.

[GN⁺]

Hacker-News-Meinungen

• Ich würde die Nutzung von Next absolut nicht empfehlen. Die Developer Experience ist furchtbar, der Vendor Lock-in stark, und wegen seltsamer, undokumentierter Konventionen fühlt es sich so an, als lägen überall Minen, wenn es nicht gerade ein simples, CRUD-lastiges B2B-SaaS ist. Besonders erinnere ich mich an einen Fall, in dem das Next-<Image />-Tag die FPS einer WebGL-Szene auf derselben Seite auf 2 gedrückt hat

  • Ich frage mich, wie Vercel normale React-Nutzer so langsam in den Vendor Lock-in gekocht hat. React war ein Projekt von Meta, das Open Source betont hat, und ich hatte gehofft, dass Open Source vor Vendor Lock-in schützt. Dass das in der Praxis nicht so ist, ist enttäuschend

  • Stimme voll zu. Ich habe vor Kurzem nach langer Zeit wieder Next benutzt, und die Entwicklungserfahrung war sehr enttäuschend. Die Dokumentation war vage und schwer zu finden, und die App selbst fühlte sich standardmäßig langsam an. Als ich mit Docker auf AWS deployen wollte, bin ich wegen des von Vercel bereitgestellten Beispiel-Dockerfiles auf unzählige Probleme gestoßen

  • Mich würde interessieren, ob du das <Image />-Problem selbst analysiert hast oder nur vermutest, dass es ein NextJs-Problem ist. Ich arbeite mit der Kombination aus NextJs, <Image> und RTF, habe so ein Problem aber noch nie erlebt

• Ich nutze Next.js seit drei Jahren beruflich und es ist wirklich schmerzhaft. Gehostet wurde auf Vercel, und die Firma hat fast alle Vercel-Services eingeführt, also ein vollwertiges Vendor-Lock-in-Erlebnis. Ich hatte schon früher in einem HN-Post von Dan zu RSC meine schlechten Erfahrungen geteilt, und seine Einschätzung traf aus meiner Sicht genau zu. So etwas wie „RSC selbst ist inzwischen ziemlich solide, aber Frameworks wie Next.js sind noch recht rau“ passt gut. Insgesamt wirkt selbst React inzwischen nur noch unterdurchschnittlich, und Next.js beschleunigt den schlechten Ruf eher noch. Am besten hält man Abstand

• Vercel wird diesen Bug wohl beheben, aber ich bin Next.js inzwischen wegen all dieser kleinen Probleme leid. Zum Beispiel ist in Middleware die Erkennung von prefetch seit Wochen, vielleicht Monaten, kaputt. Diese Kleinigkeiten häufen sich ständig, und genau das ermüdet mich bei Next.js. Das JS-Ökosystem selbst mag ich aber weiterhin

  • Ich bin von Next.js zu Astro gewechselt. Ich wollte wieder zurück zu den Grundlagen, hatte aber keine Lust, Routing, Templates, statische Assets und Build selbst aufzusetzen. Astro übernimmt all das und ist standardmäßig SSR. Es fühlt sich an, als würde man React/Vue wieder wie ursprünglich gedacht als Interaktionsschicht oben draufsetzen, und man merkt dabei, wie unnötig viele JS-Frameworks eigentlich sind. Next wird immer magischer, Server Actions wirken unbeholfen, und es gibt viel zu viele Implementierungen auf „NextJS-Art“

  • Ich nutze Next.js aktuell für die Arbeit und Side Projects, aber früher war es ein angenehmes und produktives Tool. Seit dem Wechsel von pages zum app router gefällt mir die Richtung deutlich weniger

  • Seit Version 15.1.8 sind einige Bibliotheken1 kaputt, sodass man auf die vom Autor erwähnte verwundbare Version downgraden muss

  • Sehe ich genauso. Künftig werde ich Next.js nur noch für statische Sites oder vorab gebaute SPAs verwenden

• Next ist inzwischen fast ein Witz. Seit Remix sich auf kaum nachvollziehbare Weise in react-router verwandelt hat, gibt es gefühlt nur noch extrem wenige brauchbare React-Frameworks. Ich bin am Ende wieder bei plain vite plus tanstack router gelandet

  • Es überrascht mich, dass so ein kritischer Beitrag auf Hacker News überhaupt stehen bleibt. Ich hatte früher einmal gepostet, dass etwas mit Remix einfacher umzusetzen sei, und bekam dann Nachrichten von mehreren Vercel-Mitarbeitern, die mich baten, den Beitrag zu löschen oder ein Meeting zu machen. Sie haben mich gleichzeitig über mehrere Social-Media-Accounts kontaktiert

  • Meinst du, dass du Remix seit dem Rebranding nicht mehr nutzt, oder dass es kein Framework mehr ist? RR7 (React Router 7) funktioniert auch als Framework ganz normal1. Ich war 15 Jahre lang Backend-Entwickler und bin vor Kurzem zu Full-Stack gewechselt. Ein guter Freund hat mir RR7 empfohlen, und ich bin jeden Tag beeindruckt

  • Ich habe TanStack Router in einem neuen Projekt ausprobiert und fand es so gut, dass ich auch TanStack Query und TanStack Form ergänzt habe

  • Mich würde interessieren, was die beste Alternative ist und warum du Vite verwendest. Ich nutze Next für kleine Projekte und habe immer gehört, dass SEO der größte Vorteil sei. Man erzeugt doch einfach statische Dateien und lädt sie nach S3 hoch – oder ist es doch nicht so einfach?

  • Mich würde konkret interessieren, was genau daran problematisch ist, dass Remix zu react-router geworden ist. Für mich sieht es nur nach einem Rebranding aus

• Ich betone seit Jahren, dass man bei Dingen wie React, Next und Svelte, die von Vercel stark vorangetrieben werden, viel vorsichtiger sein sollte. Ihr Ziel ist etwas wie Heroku, aber deutlich aggressiver: vollständiger Lock-in über den gesamten Stack hinweg, von Sprache über Runtime bis Maschine. Auch andere Firmen sind problematisch. Das CLI-Deployment-Tool von Cloudflare unterstützt zum Beispiel nur macOS 13.5+, also etwas über zwei Jahre alt, ohne dass klar wäre, warum. Es ist traurig, dass ein Betriebssystem von vor zwei Jahren schon als alt behandelt wird. Man kann zwar ältere Versionen von wrangler verwenden, aber Dokumentation und Funktionen passen dann nicht zusammen, und vermutlich wird alles nur noch schlimmer. Irgendwann könnte auch die Kompatibilität ganz wegfallen. Andere Tools wie vim, neovim oder emacs laufen dagegen immer noch auf altem OS X. Ich glaube, solche offenen Tools haben einfach keinen Anreiz für Lock-in

• Next und RSC sind das Frustrierendste, womit ich im Frontend je zu tun hatte. Frontend ist ohnehin schon kompliziert genug, und dann kommt noch die „Magie“ von Next dazu – samt Vendor Lock-in zu Vercel. Unser Team will diese Woche auf tanstack router und vite umsteigen und ein ganz normales CSA bauen, worauf ich mich freue

  • Mich würde interessieren, was an RSC so frustrierend sein soll. Meiner Erfahrung nach funktioniert es wirklich gut, und der einzige Grund, warum ich Next.js noch nutze, ist gerade RSC

• Mehr Leute sollten darüber sprechen, dass Next.js im Entwicklungsmodus 10 Sekunden für das Kompilieren von Routen braucht. Der Rust-Compiler wirkt daneben, als würde er gemütlich in der Ecke eine rauchen

  • Völlig unbenutzbar. Die schlechteste DevX, die ich je erlebt habe. Das letzte Mal, dass ich einen Stack so gehasst habe, war, als ich einmal bei einer Sharepoint-Site helfen musste

  • Inzwischen durchläuft selbst JS als simple Skriptsprache mehrfach Build-/Kompilierungsschritte und braucht am Ende länger als ein C++-Compiler. Man kommt fast auf den Gedanken, dass selbst Clang im Browser die bessere Erfahrung wäre. Zur Einordnung: Bei uns in der Firma wird auch PHP verwendet, und dort haben wir ein ähnliches Problem. Ich dachte, als Skriptsprache wäre es simpel, aber wegen der Performance-Grenzen von PHP braucht man zusätzlich Code-Pre-Generation und Composer-Build-Schritte. Und auch dieser von PHP-Entwicklern gebaute Build ist langsam. Vermutlich, weil er nicht von den Leuten hinter GCC gebaut wurde

  • Seltsamerweise ist bei unserer Firmen-Codebasis auch die Option next dev —-turbo nicht schneller

  • Der Rust-Compiler kompiliert tatsächlich. Ich frage mich, ob der Next.js-Compiler wirklich Arbeit von vergleichbarer Komplexität leistet

• Es ist traurig, was aus Next.js geworden ist. Ich nutze es immer noch, aber nur so, dass ich es selbst forke, patche und dann einsetze. next.config.js ist ein mühsamer Fluchtweg, um Standardverhalten zu ändern, und ich finde, solche Optionen hätten als reguläre Erweiterungspunkte angeboten werden sollen, statt sie hinter „feature flags“ zu verstecken. Inzwischen ist es fast schon ein D-Framework mit kompletter Spaghetti-Architektur

• Falls nicht NextJS: Welche Empfehlung gibt es dann für einen Full-Stack-Stack insgesamt? Ich bin Backend-Entwickler mit 15 Jahren Erfahrung, aber Frontend ist für mich das erste Mal seit AngularJS. Wegen eines Side Projects wollte ich kürzlich eine Full-Stack-App bauen, und sowohl Gemini als auch die offizielle Dokumentation haben überall NextJS empfohlen. Ich bin noch ganz am Anfang und würde gern Alternativen lernen. Alles soll per Docker direkt auf einem VPS laufen, deshalb vermeide ich Vercel und Netlify

  • Wenn du kein Server Rendering brauchst, würde ich React ohne Framework zusammen mit Vite1 empfehlen. Während der Entwicklung läuft es über Vite, und im Produktions-Build kommen einfach nur HTML- und JS-Dateien heraus, die du auf statisches Hosting wie S3 hochladen kannst. Ich nutze das seit über zehn Jahren ohne Probleme. Beim Backend nimm einfach, womit du dich wohlfühlst; ich setze in letzter Zeit meist auf PostgREST2. Für API-Aufrufe auf Client-Seite würde ich react-query3 empfehlen

  • Mich würde interessieren, an was für einem Projekt du arbeitest. Ich baue gerade eine typische SaaS-Web-App, und die Kombination aus React/Refine.dev/Vite war sehr gut. Dank Refine.dev konnte ich mich auf die Feature-Entwicklung konzentrieren, ohne über CRUD-Seiten nachdenken zu müssen

• Ich finde, dieses Thema wird übertrieben. Wer weiß, wie Streaming in React funktioniert, dem ist klar, dass man HTML nicht zeilenweise streamen kann. Wegen der Metadaten sollte der First Paint nicht blockiert werden – wohlgemerkt HTML, nicht JS. Dass man für dieses Verhalten bestimmte User Agents ausnimmt, ist vernünftig. Für den Großteil des Traffics ist es wichtiger, so schnell wie möglich etwas anzuzeigen. Falls es Nutzer gibt, bei denen das Laden der Metadaten lange dauert, würde mich interessieren, wie man das lösen sollte