Astro vs. Next.js: Welches Framework passt zu deinem Projekt?

„Nehmen wir Astro oder Next.js?“ – die Frage stellt sich, sobald eine neue Website oder ein Relaunch ansteht und beide Namen im Raum stehen, etwa durch eine Agentur-Empfehlung, einen Entwickler im Team oder einen Artikel, der eines davon zum Standard erklärt.

Wir bauen unsere eigene Website mit Astro und bieten Astro-Projekte an. Das macht uns nicht neutral, deshalb vorab die Kurzfassung: Für Unternehmenswebsites, Magazine und Dokumentationen halten wir Astro für die einfachere Wahl. Für Anwendungen mit eingeloggten Bereichen, Dashboards und viel Interaktion ist Next.js die bessere. Dieser Artikel zeigt, woran du das erkennst.

Diese Einteilung ist nicht unsere Erfindung, beide Projekte beschreiben sich selbst so. Astro nennt sich „das Web-Framework für inhaltsgetriebene Websites“ und zählt dazu Marketing-Seiten, Publikationen, Dokumentationen, Blogs, Portfolios, Landingpages, Community-Seiten und E-Commerce. Andere Frameworks, so die Astro-Dokumentation, seien für Webanwendungen gebaut worden, etwa eingeloggte Admin-Dashboards, Postfächer, soziale Netzwerke oder To-do-Listen. Next.js beschreibt sich als React-Framework für „Full-Stack-Webanwendungen“. Wichtig dabei: „inhaltsgetrieben“ heißt nicht „nur statisch“. Astro kann auch auf dem Server rendern, Formulare verarbeiten und Sitzungen halten. Es ist nur nicht darauf ausgelegt, dass fast jede Seite eine Anwendung ist.

Wenn du erst klären willst, ob es überhaupt ein Framework sein soll, hilft der Entscheidungs-Überblick zu WordPress, Astro, Headless oder Laravel. Wer zwischen Astro und WordPress schwankt, findet das im Vergleich Astro und WordPress.

Der Stand im Oktober 2026

Damit klar ist, worüber wir reden:

• Astro ist in Version 7 aktuell (seit Juni 2026; die jüngste Version im Astro-Blog ist Astro 7.3 vom 3. September 2026).
• Next.js steht bei Version 16.4, veröffentlicht am 6. Oktober 2026 (Quelle: Next.js-Blog).

Beide sind unter MIT-Lizenz frei nutzbar. Next.js wird von Vercel entwickelt. Astro gehört seit dem 16. Januar 2026 zu Cloudflare: Laut der Ankündigung im Astro-Blog hat Cloudflare die Astro Technology Company übernommen, das Framework bleibt Open Source und MIT-lizenziert, mit offener Governance und Unterstützung für viele Hosting-Ziele, nicht nur Cloudflare.

Zur Eigentümerfrage ehrlich: Beide Frameworks hängen am Interesse eines Unternehmens, das Infrastruktur verkauft. Das ist kein Ausschlusskriterium, aber ein Grund, nicht zu tief in plattformspezifische Funktionen zu bauen. Bei Next.js zeigt sich das daran, dass laut Dokumentation Vercel und Bun die „verifizierten” Adapter sind; für Cloudflare und Netlify nennt die Doku Adapter als in Arbeit und verweist bis dahin auf deren eigene Integrationen.

Wie die beiden rendern

Astro rendert auf dem Server, die Astro-Dokumentation nennt das „server-first“. In der Grundeinstellung passiert das einmal beim Build: Komponenten werden zu HTML und CSS, und laut Astro-Dokumentation wird dabei alles clientseitige JavaScript entfernt, sofern du es nicht ausdrücklich zulässt. Interaktive Teile sind „Islands”: kleine Inseln, die du mit Anweisungen wie client:load, client:idle oder client:visible markierst und die nur dann JavaScript laden. Diese Inseln dürfen in React, Preact, Svelte, Vue oder Solid geschrieben sein, auch gemischt. Für einzelne dynamische Bereiche gibt es zusätzlich „Server Islands” (server:defer), und einzelne Seiten lassen sich mit einem Adapter bei Bedarf auf dem Server rendern.

Next.js baut auf React und dem App Router. Seiten und Layouts sind standardmäßig Server Components: Sie laufen auf dem Server, ihr Ergebnis wird als HTML und als sogenannte RSC-Payload ausgeliefert. Interaktive Teile markierst du mit "use client"; sie werden im Browser „hydriert”, also mit Event-Handlern versehen. Die Dokumentation weist darauf hin, dass mit "use client" auch alles, was diese Datei importiert, im Client-Bundle landet. Seit den 16er-Versionen kommt ein neues Modell dazu, die „Cache Components”: Teile einer Seite lassen sich als zwischenspeicherbar markieren, andere bleiben zur Anfragezeit dynamisch, alles in einer Antwort. Next.js empfiehlt das laut Blog ab 16.4 für alle neuen Apps und kündigt es als Standard für Next.js 17 an.

Der Unterschied in einem Satz: Astro geht von „keine Interaktivität” aus und holt sie punktuell dazu. Next.js geht von einer React-Anwendung aus und versucht, möglichst viel davon auf dem Server zu halten.

JavaScript im Browser und Core Web Vitals

Ein Vorurteil vorweg: Das Framework allein entscheidet nicht über Core Web Vitals. Große Bilder, nicht ladende Schriften und Werbe- oder Tracking-Skripte können die Ladezeit stärker belasten als die Wahl des Frameworks. Wie wir bei der eigenen Seite vorgegangen sind, steht in Core Web Vitals mit Astro.

Trotzdem gibt es einen strukturellen Unterschied. Bei Astro ist „kein JavaScript” der Normalfall; jede Insel kostet bewusst etwas. Bei Next.js lässt sich der Umfang dank Server Components ebenfalls klein halten, die Dokumentation nennt „reduce the amount of JavaScript sent to the browser” selbst als Vorteil. Aber sobald Client Components im Spiel sind, braucht es React und Hydration im Browser, und die Navigation zwischen Seiten läuft clientseitig über die RSC-Payload. Wie groß das Ergebnis ist, hängt davon ab, wie diszipliniert gebaut wird. Zur Kontrolle verweist die Next.js-Dokumentation auf einen Bundle Analyzer.

Wir nennen hier bewusst keine Benchmark-Zahlen. Ein Vergleich zweier Beispielseiten sagt wenig darüber, was bei deiner Website mit Tracking, Cookie-Banner und Formularen herauskommt. Wenn Ladezeit für dich geschäftskritisch ist: Miss deine konkrete Seite mit echten Daten, nicht mit dem Framework-Namen. Für die SEO-Seite beider Ansätze ist Astro und SEO ein guter Einstieg.

Inhaltsseite oder Anwendung?

Das ist die Frage, die die Entscheidung am häufigsten trägt.

Eine Inhaltsseite liefert Texte, Bilder und Formulare aus. Die meisten Besucher lesen, wenige klicken sich durch. Das sind Unternehmensauftritte, Landingpages, Blogs, Dokumentationen, Katalogseiten. Hier passt Astros Ausgangslage, weil du nur die Interaktivität bezahlst, die du wirklich brauchst.

Eine Anwendung hat angemeldete Nutzer, personalisierte Ansichten, Zustand, der zwischen Aktionen erhalten bleibt, und viele Datenabfragen zur Laufzeit: Kundenportale, Dashboards, Buchungsstrecken, interne Werkzeuge. Hier ist Next.js im Vorteil: Routing, Datenabruf auf dem Server, Server Actions für Mutationen, ein durchdachtes Caching-Modell und eine große React-Welt dahinter. Astro hat ebenfalls Server-Bausteine: Seiten lassen sich pro Anfrage rendern, Actions sind typsichere Server-Funktionen, etwa für Formulare, Sessions speichern etwa einen Warenkorb serverseitig. Für einen Login-Bereich oder einen Warenkorb auf einer Inhaltsseite reicht das. Den Mittelpunkt einer durchgehend interaktiven Anwendung zu bilden, ist aber nicht das, wofür Astro gebaut ist.

Dazwischen liegt ein breiter Streifen: eine Website mit einem Konfigurator, einem Kundenbereich oder einer Suche. Dort lohnt die Frage, wie viel Prozent der Seiten wirklich Anwendung sind. Ist es ein kleiner Teil, lässt er sich bei Astro als Insel oder als server-gerenderte Route lösen. Ist es der größere Teil, fang mit Next.js an und hol die Inhaltsseiten dort hinein.

Umgekehrt gilt auch: Next.js kann reine Inhaltsseiten ohne Weiteres ausliefern, etwa vorab gerendert oder als statischen Export. Es bringt dafür nur mehr Technik mit, als eine Inhaltsseite braucht.

Hosting und Betrieb

Hier liegt für viele Mittelständler der praktischste Unterschied.

Astro erzeugt standardmäßig statische Dateien, die jeder Webspace ausliefern kann. Unsere Website läuft so auf klassischem Hosting. Für Server-Rendering gibt es offizielle Adapter für Node.js, Netlify, Vercel und Cloudflare; du aktivierst es pro Seite mit export const prerender = false, der Rest bleibt statisch.

Next.js läuft laut Dokumentation mit vollem Funktionsumfang auf einem Node.js-Server oder in einem Docker-Container. Dazu kommen Adapter für Plattformen. Einen statischen Export gibt es auch (output: 'export'), er läuft auf jedem Webserver, ist laut Dokumentation aber ausdrücklich eingeschränkt: Nicht unterstützt sind unter anderem Server Actions, Cookies, Rewrites, Redirects und Header aus der Konfiguration, Incremental Static Regeneration, Draft Mode und die Standard-Bildoptimierung.

Was das praktisch heißt: Wenn Next.js alles können soll, brauchst du eine Laufzeitumgebung, um die sich jemand kümmert, die aktuell gehalten und überwacht wird. Bei Vercel ist das bequem, aber du bindest dich an einen Anbieter. Selbst betrieben ist es ein Server mehr in deiner Verantwortung. Bei einer statischen Seite fällt dieser Teil weg, und damit eine ganze Klasse von Betriebsproblemen.

Ökosystem und Team

Next.js bringt das React-Ökosystem mit: viele Komponenten-Bibliotheken, viele Entwickler auf dem Markt, viele Beispiele. Wenn dein Team ohnehin React schreibt und Komponenten zwischen Produkt und Website teilen will, ist das ein echtes Argument für Next.js.

Astro ist näher an HTML, CSS und Markdown und hat eine flache Lernkurve für alle, die Websites bauen. Es kann gleichzeitig React-Komponenten einbinden, du musst vorhandenen Code also nicht wegwerfen. Es ist die kleinere Welt: weniger Entscheidungen, dafür weniger fertige Bausteine für Anwendungslogik.

Eine Faustregel: Wer die Seite später pflegen soll, entscheidet mit. Eine Technik, die dein Team nicht lesen kann, wird zur Abhängigkeit vom Dienstleister.

CMS-Anbindung

Beide Frameworks sprechen mit Headless-CMS über Schnittstellen. Laut Astro-Dokumentation lässt sich Astro mit über 50 Headless-CMS verbinden, darunter Sanity, Contentful, Storyblok, Strapi und WordPress; ohne CMS genügen Markdown-Dateien. Wie das mit einem Redaktionssystem aussieht, beschreiben wir in Headless WordPress mit Astro und Storyblok mit Astro.

Bei Next.js ist die Anbindung eines Headless-CMS ebenso üblich. Ein Punkt, der in die Auswahl gehört, ist die Vorschau: Next.js hat einen Draft Mode für Entwürfe, der laut Dokumentation im statischen Export nicht verfügbar ist, also Server-Betrieb voraussetzt. Bei Astro kommt die Vorschau aus dem CMS selbst oder aus einer Seite, die bei Bedarf auf dem Server gerendert wird; auch das braucht dann einen Adapter. Wenn Redakteure vor dem Veröffentlichen die echte Seite sehen müssen, klär das früh, egal für welches Framework.

Mehrsprachigkeit

Astro bringt Routing für mehrere Sprachen mit: Sprachen, Standardsprache, Pfad-Präfixe und Fallbacks sind konfigurierbar. Eigene Domains pro Sprache gibt es laut Doku nur bei Server-Ausgabe; für rein statische Seiten haben wir dafür eine eigene Lösung gebaut, siehe Astro mehrsprachig: zwei Domains, zwei Sprachen, ein Build.

Next.js liefert im App Router keine fertige Sprachlogik, sondern ein Muster: Sprache als Routen-Segment (app/[lang]), Weiterleitung nach Browsersprache über den Proxy, Übersetzungen als Wörterbuch. Sprachen als Unterpfad oder als Domain sind möglich. Für Komfort wie übersetzte Routen greifen viele Projekte zu Bibliotheken wie next-intl, die auch die Next.js-Doku auflistet.

Keines von beiden nimmt dir die eigentliche Arbeit ab: gepflegte Übersetzungen, sauberes hreflang, passende Canonicals.

Wartung und Upgrades

Beide Frameworks entwickeln sich schnell, und beide haben größere Versionssprünge. Das ist keine Schwäche, aber ein Kostenfaktor über Jahre.

Beim Sprung auf Astro 7 nennt der Upgrade-Guide unter anderem einen strengeren Rust-Compiler (nicht geschlossene HTML-Tags erzeugen jetzt Fehler), einen neuen Standard-Markdown-Prozessor, eine geänderte Whitespace-Voreinstellung und das entfernte Paket @astrojs/db. Bei einem schlichten Projekt hält sich der Aufwand in Grenzen, bei einem mit vielen Plugins und eigenen Markdown-Erweiterungen fällt er höher aus.

Next.js führt Upgrade-Anleitungen für die Versionen 14, 15 und 16, dazu Codemods und neuerdings next upgrade --agent, das Programmierassistenten durch die Umstellung führen soll. Mit Cache Components wird laut Next.js-Blog in Next.js 17 ein neues Programmiermodell zum Standard, das die impliziten Caching-Verhalten früherer App-Router-Versionen ersetzt. Das ist inhaltlich mehr als ein Versions-Bump. Am 8. Oktober 2026 hat das Next.js-Team außerdem ein Sicherheits-Update für Abhängigkeiten angekündigt. Wer einen Node-Server betreibt, muss solche Updates einplanen.

Unterm Strich: Eine statische Astro-Seite hat weniger Teile, die im Betrieb veralten. Eine Next.js-Anwendung hat mehr Funktionen, und damit mehr, was gepflegt werden will.

Wann Astro, wann Next.js

Deine Situation	Eher
Unternehmenswebsite, Landingpages, Blog, Dokumentation	Astro
Hosting auf klassischem Webspace oder CDN, kein eigener Server gewünscht	Astro
Wenig Interaktivität, Ladezeit und Wartungsarmut zählen	Astro
Inhalte kommen aus Markdown oder einem Headless-CMS und ändern sich überschaubar oft	Astro
Website mit einzelnen interaktiven Bereichen (Rechner, Suche, Formular)	Astro mit Inseln
Eingeloggte Bereiche, Kundenportal, Dashboard	Next.js
Viele Seiten sind nutzerspezifisch und werden pro Anfrage gerendert	Next.js
Das Team arbeitet bereits in React und will Code zwischen Produkt und Website teilen	Next.js
Hohe Interaktivität auf fast jeder Seite (Editoren, Konfiguratoren, Echtzeit)	Next.js
Marketing-Website plus eigenständige Anwendung	Beides, getrennt

Die letzte Zeile ist keine Verlegenheitslösung: Website und Anwendung dürfen verschiedene Werkzeuge nutzen, jeweils das, was zu ihrer Aufgabe passt, und trotzdem unter einer Marke auftreten.

Unsere Empfehlung

Wenn deine Website vor allem informiert, überzeugt und Anfragen sammelt, ist Astro in den meisten Fällen die schlankere Wahl: weniger Technik im Betrieb, weniger Code im Browser, ein einfacheres Hosting-Setup. Wenn du ein Produkt baust, in dem Nutzer arbeiten, ist Next.js mit hoher Wahrscheinlichkeit die richtige Grundlage.

Und wenn du unsicher bist, ob dein Vorhaben mehr Website oder mehr Anwendung ist: Das lässt sich meist in einem Gespräch klären. Wie wir Astro-Projekte angehen, steht auf unserer Seite zur Astro-Agentur. Schreib uns, was die Seite leisten soll, und wir sagen dir, was wir empfehlen, auch wenn es Next.js heißt.

Quellen: Astro-Dokumentation und Astro-Blog (docs.astro.build, astro.build/blog), Next.js-Dokumentation und Next.js-Blog (nextjs.org/docs, nextjs.org/blog), jeweils Stand 11. Oktober 2026.