Astro vs Next.js: Der ehrliche Vergleich mit eigenem Benchmark (2026)

Astro vs Next.js ist die Frage, die sich fast jeder stellt, der heute eine neue Website mit JavaScript-Werkzeugen bauen will. Beide Frameworks erzeugen HTML aus Komponenten, beide können statische Seiten und Server-Rendering, beide haben eine große Community. Und trotzdem sind sie für ganz unterschiedliche Aufgaben gebaut.

Die kurze Antwort: Astro ist ein Framework für Inhalte, Next.js ist ein Framework für Anwendungen. Astro schickt standardmäßig kein JavaScript an den Browser und lädt nur dort Code nach, wo du ihn ausdrücklich brauchst. Next.js baut auf React auf und liefert die React-Laufzeit immer mit, auch auf Seiten, die nur Text zeigen. Für einen Blog, eine Firmenseite oder eine Dokumentation ist Astro meistens die bessere Wahl. Für ein Dashboard, einen Login-Bereich oder eine App mit viel Interaktion ist Next.js stärker.

Wir haben dazu eine eigene Meinung, weil diese Seite, getmind.io, selbst auf Astro läuft, während auf demselben Server mehrere Next.js-Anwendungen von uns laufen. Damit dieser Artikel nicht nur Erfahrung behauptet, haben wir am 15. Oktober 2026 einen fairen Test gebaut: derselbe Blog mit 200 Artikeln, einmal in Astro 7.3.8 und einmal in Next.js 16.4.1 (erschienen einen Tag vorher), beide als statischer Export, beide auf demselben Server mit Node.js 22. Drei Ergebnisse vorweg:

1. Eine Artikelseite aus Astro enthielt null Skripte. Dieselbe Seite aus Next.js lud sechs Skripte mit 569 KB JavaScript (174 KB komprimiert).

2. Im Lighthouse-Test (Mobil) erschien das größte Element bei Astro nach 0,75 Sekunden, bei Next.js nach 1,4 bis 1,9 Sekunden. Beide bekamen trotzdem 100 Punkte.

3. Der Build war bei Astro schneller (2,1 statt 3,8 Sekunden) und brauchte halb so viel Arbeitsspeicher (356 statt 766 MB).

Astro vs Next.js: Der grundlegende Unterschied

Um zu verstehen, warum die beiden so unterschiedliche Zahlen liefern, muss man wissen, woher sie kommen.

Was ist Next.js?

Next.js ist ein React-Framework, das von der Firma Vercel entwickelt wird. Es kam 2016 heraus und hat damals ein echtes Problem gelöst: Reine React-Anwendungen wurden komplett im Browser zusammengebaut. Suchmaschinen und Nutzer sahen zuerst eine leere Seite. Next.js rendert React-Komponenten vorher auf dem Server oder beim Build und schickt fertiges HTML. Danach übernimmt React im Browser die Seite (das nennt man Hydration), und ab da verhält sich alles wie eine Single-Page-App: Seitenwechsel ohne Neuladen, Zustand bleibt erhalten, Formulare reagieren sofort.

Heute nutzt Next.js den App Router mit React Server Components. Komponenten können ausschließlich auf dem Server laufen und schicken dann kein eigenes JavaScript an den Browser. Das hat die Menge an Code deutlich reduziert. Was aber immer bleibt: die React-Laufzeit, der Router von Next.js und ein Datenpaket (der sogenannte RSC-Payload), mit dem der Browser die Seite rekonstruieren kann. Dazu gleich mehr in unserem Test.

Next.js kann statische Seiten erzeugen (SSG), Seiten bei jeder Anfrage auf dem Server rendern (SSR), statische Seiten im Hintergrund erneuern (ISR) und hat eingebaute Server Actions und Route Handler, also Backend-Code direkt im Projekt. Es ist ein Full-Stack-Framework.

Was ist Astro?

Astro erschien 2021 und hat den umgekehrten Ansatz gewählt. Eine Astro-Seite ist erst einmal reines HTML. Komponenten werden beim Build (oder auf dem Server) gerendert, und ihr JavaScript wird danach weggeworfen. Wenn du auf einer Seite doch etwas Interaktives brauchst, zum Beispiel einen Bildslider, ein Suchfeld oder einen Rechner, markierst du genau diese Komponente als Insel (Island). Nur diese Insel bekommt JavaScript, der Rest der Seite bleibt statisch.

Das Besondere: Inseln können in React, Vue, Svelte, Solid oder Preact geschrieben sein, auch gemischt in einem Projekt. Astro selbst ist nicht an ein UI-Framework gebunden. Inhalte schreibst du typischerweise in Markdown oder MDX, und über Content Collections prüft Astro beim Build, ob jeder Artikel die nötigen Felder hat.

Astro kann inzwischen ebenfalls Server-Rendering, hat Server Islands, Actions und Middleware. Im Januar 2026 hat Cloudflare die Firma hinter Astro übernommen. Das Framework bleibt Open Source unter MIT-Lizenz. Damit stehen jetzt beide Frameworks hinter einem großen Hosting-Anbieter: Next.js hinter Vercel, Astro hinter Cloudflare.

Der Unterschied in einem Satz

Next.js geht davon aus, dass deine Seite eine Anwendung ist, und macht Ausnahmen für statische Inhalte. Astro geht davon aus, dass deine Seite ein Dokument ist, und macht Ausnahmen für Interaktivität.

Die Unterschiede in einer Tabelle

Unser Testaufbau

Ein fairer Vergleich braucht identische Bedingungen. Deshalb haben wir beide Frameworks so schlicht wie möglich gehalten, ohne Styling und ohne Extras.

• Inhalt: 200 Markdown-Dateien mit Frontmatter (Titel, Datum), je rund 1.000 Wörter Fülltext mit einer Zwischenüberschrift. Insgesamt 1,6 MB. Mit festem Zufalls-Startwert erzeugt, damit beide Projekte exakt dieselben Texte haben.
• Seiten: eine Startseite mit einer Liste aller Artikel und eine Artikelseite pro Markdown-Datei.
• Astro 7.3.8: Content Collection mit glob-Loader und Schema, Seiten als .astro-Dateien, keine Integrationen.
• Next.js 16.4.1: App Router, generateStaticParams, Markdown mit gray-matter und marked gelesen, output: 'export' für einen rein statischen Export. Für den Servertest zusätzlich ohne Export mit next start.
• Server: unser eigener Linux-Server mit 12 Kernen, Node.js 22.23. Jede Messung mehrfach, wir nennen Spannen statt Einzelwerte.
• Messwerkzeuge: GNU time für Build-Dauer und Speicher, Lighthouse 13.4.1 (Mobil, simulierte Drosselung, Chrome headless), autocannon 8 für die Last.

Wichtig für die Einordnung: Beide Projekte machen dasselbe, aber Next.js braucht für Markdown zwei Zusatzpakete, die Astro eingebaut hat. Das ist kein Trick, sondern genau der Weg, den man in Next.js für einen Markdown-Blog normalerweise geht.

Test 1: Installation und Abhängigkeiten

Bevor eine Zeile gebaut wird, lohnt sich ein Blick auf node_modules.

Das Ergebnis ist gemischt. Next.js installiert schneller und hat viel weniger einzelne Pakete, weil Vercel fast alles fertig gebündelt in das next-Paket packt, inklusive des Compilers als vorkompilierte Binärdatei. Dafür ist der Ordner mehr als doppelt so groß. Astro zieht dagegen viele kleine Pakete aus dem Ökosystem nach (Vite, Rollup, unified/remark, Shiki).

Für den Alltag ist das selten entscheidend. Es wird aber relevant, wenn du viele Projekte auf einem Server oder in CI-Pipelines baust. Weniger Pakete heißt außerdem kleinere Angriffsfläche in der Lieferkette, mehr Megabyte heißt längere Docker-Builds. Hier steht es unentschieden.

Test 2: Build-Zeit und Speicher

Wir haben jeden Build dreimal von Null gestartet (Cache-Ordner gelöscht).

Astro war etwa 40 Prozent schneller und brauchte halb so viel Speicher. Der Speicher ist der interessantere Wert: Next.js startet für das Vorrendern standardmäßig mehrere Worker-Prozesse (in unserem Log „5 workers“), und jeder lädt React und den Next.js-Server. Auf einem kleinen VPS mit 1 oder 2 GB RAM kann genau das den Unterschied machen, ob ein Build durchläuft oder vom Kernel beendet wird. Wie viel Speicher ein Server realistisch braucht, haben wir in Was ist ein VPS? beschrieben.

Zum Vergleich unsere echte Seite: getmind.io baut mit Astro 216 Seiten in zwei Sprachen, inklusive Bildvorschauen für Social Media, Prüfung aller Sprachpaare und eines Linkprüfers über das fertige HTML. Bei 200 Seiten ist die Build-Zeit für beide Frameworks kein Problem. Bei 20.000 Seiten wäre sie es.

Test 3: Was im Browser ankommt

Das ist der Kern des Vergleichs. Wir haben die erzeugten Dateien gezählt und eine einzelne Artikelseite genau angesehen.

Die Astro-Seite ist ein HTML-Dokument. Sonst nichts. Kein Skript, kein Framework, kein Datenpaket.

Die Next.js-Seite enthält denselben Text, plus:

• Drei große JavaScript-Pakete mit 230 KB, 186 KB und 113 KB (unkomprimiert). Das sind im Wesentlichen React, React DOM und der Next.js-Client mit Router.
• Drei kleinere Pakete für die Turbopack-Laufzeit und den Seitencode.
• Den RSC-Payload, einmal eingebettet ins HTML (über self.__next_f) und zusätzlich als eigene .txt-Dateien pro Seite. Daher die 808 Textdateien: Next.js legt für jede Seite mehrere Varianten an, damit der Client-Router bei einem Klick nur die Daten holen muss, nicht das ganze HTML.

Damit kein falscher Eindruck entsteht: Dieses JavaScript ist nicht nutzlos. Es macht die Navigation zwischen Seiten schneller, weil der Browser nach dem ersten Laden nur noch kleine Datenpakete holt. Die großen Pakete landen im Browser-Cache und werden auf der zweiten Seite nicht erneut geladen. Für eine App, in der Nutzer viel klicken, ist das ein echter Vorteil. Für einen Blog-Artikel, auf den jemand aus der Google-Suche kommt, ihn liest und wieder geht, ist es reiner Ballast.

Und wenn Astro doch React braucht?

Fair ist der Vergleich nur, wenn wir auch messen, was Astro kostet, sobald Interaktivität dazukommt. Also haben wir der Astro-Artikelseite einen kleinen „Gefällt mir“-Knopf in React hinzugefügt, als Insel mit client:visible:

---
import Like from '../../components/Like.jsx';
---
<article><Content /></article>
<Like client:visible />

Ergebnis: Die Seite referenziert jetzt zwei Skripte mit 213 KB (66 KB gzip), im Wesentlichen React DOM. Das ist deutlich weniger als bei Next.js (174 KB gzip), aber eben nicht mehr null. Und der wichtige Unterschied: Mit client:visible lädt der Browser das JavaScript erst, wenn der Knopf in den sichtbaren Bereich scrollt. Wer den Artikel nur anliest, lädt kein React. Mit client:load würde es sofort geladen, mit client:idle sobald der Browser nichts mehr zu tun hat.

Die Lehre daraus: Astro ist nicht magisch schneller. Es macht nur den Verzicht auf JavaScript zum Standard und die Nutzung zur bewussten Entscheidung. In Next.js ist es umgekehrt.

Test 4: Lighthouse und Core Web Vitals

Jetzt die Frage, die Nutzer und Google interessiert: Wie schnell ist die Seite gefühlt? Wir haben beide statischen Ausgaben mit demselben einfachen Node-Server (serve, mit gzip) ausgeliefert und Lighthouse je dreimal im Mobil-Modus laufen lassen.

Beide bekommen die volle Punktzahl, und das ist ehrlich gesagt das wichtigste Ergebnis für alle, die Next.js mögen: Eine statisch exportierte Next.js-Seite ist nicht langsam. Der Text erscheint gleich schnell.

Aber: Das größte sichtbare Element (LCP) erschien bei Next.js zwei- bis zweieinhalbmal später, und die Seite war erst nach knapp zwei Sekunden vollständig bedienbar, weil der Browser vorher 140 KB JavaScript laden, entpacken und ausführen muss. Lighthouse drosselt dabei auf ein simuliertes langsames Mobilnetz und eine vierfach gebremste CPU. Auf einem schnellen Laptop im WLAN merkst du davon nichts. Auf einem drei Jahre alten Android-Handy in der Bahn schon.

Ohne Kompression wird es deutlich

Im ersten Durchlauf hatten wir aus Versehen einen Server ohne gzip benutzt (Pythons eingebauten http.server). Das ist kein exotischer Fall, sondern passiert bei falsch konfigurierten Servern häufiger, als man denkt. Ergebnis:

Bei Astro ändert sich fast nichts, weil kaum Daten übertragen werden. Bei Next.js steigt der LCP auf bis zu 3,6 Sekunden und kratzt damit an der Grenze, ab der Google ihn als „verbesserungswürdig“ einstuft (2,5 Sekunden). Je weniger du auslieferst, desto weniger kann deine Server-Konfiguration kaputtmachen. Wie Kompression und Caching über ein CDN helfen, steht in Was ist ein CDN?. Deine eigene Seite kannst du mit unserem Core-Web-Vitals-Test prüfen.

Eine animierte Gegenüberstellung von Devsplainers (April 2026, Englisch). Gut als visuelle Ergänzung zu unseren Zahlen, besonders der Teil zur Inseln-Architektur.

Test 5: Server-Betrieb mit next start

Viele Next.js-Projekte werden nicht als statischer Export ausgeliefert, sondern mit next start als Node-Server. Das ist nötig, sobald du Server-Rendering, ISR, Middleware oder Server Actions nutzt. Wir haben dasselbe Projekt deshalb ohne output: 'export' gebaut und mit next start gestartet. Die Astro-Seite haben wir als statische Dateien über serve ausgeliefert, ebenfalls ein Node-Prozess, damit der Vergleich nicht unfair gegen Node ausfällt.

Lasttest: autocannon mit 32 gleichzeitigen Verbindungen, 10 Sekunden, immer dieselbe Artikelseite.

Next.js schafft auch hier tausende Anfragen pro Sekunde, das reicht für fast jede Website. Aber derselbe Server bedient mit statischen Dateien fast dreimal so viele Anfragen. Dazu kommt: In der Praxis würde man eine Astro-Seite gar nicht über Node ausliefern, sondern direkt über den Webserver. getmind.io liegt als Ordner mit HTML-Dateien unter Caddy, ohne einen einzigen laufenden Node-Prozess. Ein Artikel antwortet live mit einer Time to First Byte von 47 ms. Warum wir Caddy nutzen, steht in Caddy vs Nginx.

Bei den fünf Next.js-Anwendungen, die auf demselben Server laufen, haben wir den Speicher nachgesehen: 117 bis 188 MB pro Prozess, dauerhaft, auch wenn gerade niemand die Seite aufruft. Das ist kein Problem, aber es ist ein Unterschied zu einer statischen Seite, die im Leerlauf gar nichts verbraucht.

Ein Praxisfehler, den wir beim Testen selbst gemacht haben

Während dieses Tests wollten wir unsere Test-Server mit pkill -f "next-server" beenden. Der Befehl hat nicht nur die Testprozesse beendet, sondern alle fünf produktiven Next.js-Dienste auf dem Server, weil sie alle denselben Prozessnamen tragen. systemd hat sie innerhalb von 5 bis 10 Sekunden neu gestartet, weil die Dienste mit Restart=always laufen. Ohne diese Einstellung wären die Seiten offline geblieben.

Zwei Lehren daraus, die mit dem Framework-Vergleich direkt zu tun haben. Erstens: Ein Next.js-Server ist ein laufender Prozess, und laufende Prozesse kann man abschießen. Eine statische Astro-Seite kann man nicht „aus Versehen beenden“. Zweitens: Wer Node-Prozesse auf einem geteilten Server betreibt, sollte Testprozesse über ihre Prozessgruppe oder PID beenden, nie über ein Namensmuster. Und jeder produktive Dienst gehört unter systemd mit automatischem Neustart. Wie das geht, beschreibt unser Artikel zu systemd-Services.

Test 6: Entwicklungsserver

Wie fühlt sich die Arbeit im Alltag an? Wir haben beide Dev-Server mit leerem Cache gestartet und gemessen, wann die erste Artikelseite antwortet und wie schnell eine zweite Seite danach kommt.

Beim Start sind beide gleichauf, Turbopack hat Next.js hier deutlich schneller gemacht als früher mit Webpack. Danach liefert Astro weitere Seiten schneller, weil es keine Client-Pakete für jede Route bauen muss. Im Alltag sind 90 Millisekunden nicht spürbar. Der höhere Speicherbedarf kann es auf schwächeren Laptops sein.

Wo Next.js klar gewinnt

Nach so vielen Zahlen für Astro wäre es unehrlich, die Stärken von Next.js kleinzureden. Es gibt Projekte, in denen wir selbst ohne Zögern Next.js nehmen, und das tun wir auch.

Anwendungen mit viel Zustand. Ein Shop-Backend, ein Admin-Bereich, ein Dashboard mit Filtern, Tabellen und Live-Daten. Hier ist fast jede Komponente interaktiv. Astro-Inseln würden die ganze Seite bedecken, und dann bist du mit einem React-Framework besser bedient, das genau dafür gebaut ist.

Client-Navigation. Next.js wechselt Seiten, ohne den Browser neu zu laden. Ein geöffnetes Menü, ein abspielendes Video, der Inhalt eines Warenkorbs bleiben erhalten. Astro kann mit View Transitions weiche Übergänge machen, aber der Zustand von Komponenten geht dabei ohne Zusatzaufwand verloren.

Backend im selben Projekt. Mit Server Actions schreibst du eine Funktion, die auf dem Server läuft, und rufst sie direkt aus einem Formular auf. Authentifizierung, Datenbankzugriff, Zahlungsabwicklung: Das Next.js-Ökosystem hat dafür fertige, gut dokumentierte Bibliotheken (Auth.js, Prisma/Drizzle, Stripe-Beispiele). Astro hat Actions und Endpoints, aber die Auswahl an fertigen Lösungen ist kleiner.

Teams und Arbeitsmarkt. Next.js ist das meistgenutzte React-Framework. Wer Entwickler sucht, findet für Next.js deutlich leichter jemanden. Wer in einem Team mit React-Erfahrung arbeitet, ist in Next.js sofort produktiv.

Dynamische Routen in großen Mengen. Für Seiten mit Millionen möglicher URLs, etwa Produktseiten, die bei Bedarf gerendert und dann zwischengespeichert werden, ist ISR sehr praktisch. Wie Next.js dynamische URLs auflöst, haben wir in Next.js Dynamic Routes ausführlich beschrieben.

Wo Astro klar gewinnt

Inhaltsseiten. Blogs, Magazine, Dokumentationen, Firmenseiten, Landingpages, Portfolios. Alles, was Menschen hauptsächlich lesen. Hier gibt es keinen technischen Grund, ein JavaScript-Framework an den Browser zu schicken, und Astro schickt keins.

Markdown und MDX. Content Collections prüfen beim Build, ob jeder Artikel einen Titel, ein Datum und eine Kategorie hat. Fehlt etwas, bricht der Build mit einer klaren Meldung ab. Bei getmind.io nutzen wir das für 170 Artikel in zwei Sprachen. Ein falsch geschriebenes Datum oder eine unbekannte Kategorie geht so nie live.

Betrieb ohne Server. Eine statische Astro-Seite ist ein Ordner. Du kannst ihn auf jeden Webserver, jedes CDN, jeden günstigen Webspace legen. Es gibt keinen Node-Prozess, der abstürzen, Speicher fressen oder Sicherheitsupdates brauchen könnte. Eine Sicherheitslücke in React oder Next.js betrifft eine statische Astro-Seite nicht, weil zur Laufzeit kein solcher Code existiert.

Freiheit beim UI-Framework. Du kannst eine Svelte-Komponente neben eine React-Komponente setzen. Das ist für Migrationen praktisch, und für Teams, die React gar nicht wollen.

Einstieg. Eine .astro-Datei sieht aus wie HTML mit einem Skriptblock oben. Wer HTML und ein bisschen JavaScript kann, versteht sie sofort. In Next.js musst du zuerst React verstehen, dann die Grenze zwischen Server- und Client-Komponenten ('use client'), dann das Caching-Verhalten. Das ist kein Hexenwerk, aber eine steilere Kurve. Wer in die Webentwicklung einsteigt, dem empfehlen wir zuerst TypeScript zu lernen, egal für welches Framework.

Warum getmind.io auf Astro läuft

Wir haben uns für diese Seite bewusst für Astro entschieden, und nach mehreren Monaten im Betrieb würden wir es wieder tun. Ein paar konkrete Gründe aus dem Alltag:

• Jeder Artikel ist eine MDX-Datei. Wir schreiben in einem Editor, ein Build erzeugt HTML, ein rsync legt es auf den Server. Kein Datenbank-Backup, kein Admin-Login, das man absichern muss.
• Interaktive Werkzeuge gibt es trotzdem. Unser Bildkompressor, der Core-Web-Vitals-Test und ein TypeScript-Playground laufen auf getmind.io. Sie laden ihr JavaScript nur auf ihrer eigenen Seite. Die Artikel bleiben davon unberührt.
• Eigene Prüfungen im Build. Weil am Ende nur HTML-Dateien entstehen, können wir sie mit einfachen Skripten prüfen: Hat jeder deutsche Artikel ein englisches Gegenstück? Verlinkt ein deutscher Artikel versehentlich auf die englische Fassung? Ist irgendwo ein Platzhalter stehen geblieben? Bricht etwas, geht nichts live.
• Angriffe laufen ins Leere. In unseren Server-Logs sehen wir jeden Tag hunderte Anfragen an /wp-admin, /.env oder /api/. Bei einer statischen Seite gibt es dahinter nichts, was antworten könnte. Alle laufen in einen 404.

Was uns gestört hat, wollen wir auch nicht verschweigen: Jede Änderung braucht einen Build. Einen Tippfehler „schnell im Browser“ zu korrigieren, geht nicht. Für ein Team ohne technischen Hintergrund wäre das ein echtes Hindernis, dann bräuchte es ein CMS davor. Welche Möglichkeiten es dafür gibt, steht in unserem Überblick zu modernen WordPress-Alternativen.

Hosting und Kosten

Die Wahl des Frameworks beeinflusst direkt, wo und wie günstig du hosten kannst.

Astro (statisch) läuft überall: auf einem 3-Euro-Webspace, auf GitHub Pages, auf Cloudflare Pages, Netlify oder einem eigenen Server hinter Nginx oder Caddy. Traffic-Spitzen sind kein Problem, weil nur Dateien ausgeliefert werden.

Next.js (statischer Export) läuft ebenfalls überall, verzichtet dann aber auf Server-Funktionen wie ISR, Middleware, Server Actions und die eingebaute Bildoptimierung über next/image ohne eigenen Loader.

Next.js (Server) braucht eine Umgebung, die Node.js dauerhaft ausführt: einen VPS, einen Container, oder eine Plattform wie Vercel. Vercel ist der bequemste Weg, weil das Framework vom selben Hersteller stammt. Bei viel Traffic oder vielen Projekten können die Kosten aber schnell steigen. Welche Alternativen es gibt, haben wir in Vercel-Alternativen verglichen. Unser eigener Weg: Next.js mit next start als systemd-Dienst auf einem eigenen Server, davor ein Reverse Proxy.

Astro (Server) braucht ebenfalls eine Laufzeit, hat aber Adapter für Node, Cloudflare Workers, Netlify und Vercel. Seit der Übernahme durch Cloudflare ist die Integration mit Cloudflare besonders eng. Astro betont aber ausdrücklich, dass alle anderen Adapter weiter gepflegt werden.

Migration: Von Next.js zu Astro und umgekehrt

Next.js zu Astro ist bei Inhaltsseiten überraschend einfach. Deine React-Komponenten kannst du mit der React-Integration weiterverwenden, als Inseln oder rein serverseitig gerendert. Markdown-Inhalte ziehen in eine Content Collection um. Der aufwendigste Teil sind meist Routen mit Server-Logik und alles, was auf next/router oder next/navigation aufbaut. Wichtig: Die URLs müssen gleich bleiben, sonst brauchst du 301-Weiterleitungen, um dein Google-Ranking nicht zu verlieren.

Astro zu Next.js ist sinnvoll, wenn aus einer Inhaltsseite eine Anwendung wird, etwa wenn ein Blog plötzlich Nutzerkonten, Bezahlinhalte und ein Dashboard bekommt. Dann ist es oft sauberer, die Anwendung in Next.js zu bauen und den Inhaltsteil getrennt in Astro zu lassen, zum Beispiel unter einer Subdomain. Beide Frameworks müssen nicht gegeneinander antreten. Viele Firmen betreiben genau diese Kombination: Marketing-Seite in Astro, Produkt in Next.js.

Ein ausführliches Gespräch der Agentur Pagepro über Architektur, Performance und Projektwahl (Englisch, Dezember 2024). Die Versionen sind älter, die Grundargumente gelten unverändert. Ein aktuelles deutschsprachiges Video zum direkten Vergleich haben wir nicht gefunden.

Astro vs Next.js: Die Entscheidung für dein Projekt

Nimm Astro, wenn …

• deine Seite hauptsächlich gelesen wird (Blog, Doku, Firmenseite, Landingpage, Portfolio),
• Ladezeit und Core Web Vitals dir wichtig sind, besonders für mobile Nutzer aus der Suche,
• du günstig und ohne laufenden Server hosten willst,
• deine Inhalte als Markdown oder aus einem Headless-CMS kommen,
• du nicht auf React festgelegt sein willst.

Nimm Next.js, wenn …

• deine Seite eine Anwendung ist, mit Login, Nutzerdaten, Dashboards oder viel Interaktion,
• Seitenwechsel ohne Neuladen und erhaltener Zustand wichtig sind,
• du Backend-Logik im selben Projekt haben willst (Server Actions, API-Routen),
• dein Team React kennt oder du gezielt nach React-Entwicklern suchst,
• du Seiten bei Bedarf rendern und im Hintergrund erneuern musst (ISR).

Nimm beide, wenn … du eine Produktseite mit Marketing-Inhalten und eine Web-Anwendung hast. Das ist keine Notlösung, sondern oft die sauberste Architektur.

Checkliste: Astro oder Next.js in fünf Fragen

Wenn drei oder mehr Antworten in einer Spalte stehen, hast du deine Entscheidung.

Häufige Fragen zu Astro vs Next.js

Was ist der Unterschied zwischen Astro und Next.js?

Astro ist ein Framework für inhaltsgetriebene Websites, das standardmäßig reines HTML ohne JavaScript ausliefert und Interaktivität nur gezielt über Inseln nachlädt. Next.js ist ein React-Framework für Web-Anwendungen, das die React-Laufzeit immer mitliefert und dafür Client-Navigation, Server Actions und flexibles Server-Rendering bietet.

Ist Astro schneller als Next.js?

Bei Inhaltsseiten ja. In unserem Test mit identischen 200 Artikeln erschien das größte Element bei Astro nach 0,75 Sekunden, bei Next.js nach 1,4 bis 1,9 Sekunden (Lighthouse, Mobil). Astro übertrug 2,8 KB statt 143 KB. Beide erreichten trotzdem 100 Lighthouse-Punkte. Bei stark interaktiven Anwendungen relativiert sich der Unterschied, weil dann auch Astro viel JavaScript laden müsste.

Ist Astro besser als Next.js?

Nicht allgemein. Für Blogs, Dokumentationen und Firmenseiten ist Astro meistens die bessere Wahl, weil es schneller, einfacher und günstiger im Betrieb ist. Für Anwendungen mit Login, Dashboards und viel Zustand ist Next.js besser, weil es genau dafür gebaut ist und ein größeres Ökosystem hat.

Kann ich React-Komponenten in Astro verwenden?

Ja. Mit der offiziellen React-Integration (npx astro add react) kannst du React-Komponenten in Astro-Seiten einsetzen. Ohne Zusatz werden sie nur auf dem Server gerendert und schicken kein JavaScript. Mit client:load, client:idle oder client:visible werden sie im Browser interaktiv. In unserem Test kostete eine kleine React-Insel rund 66 KB gzip, geladen erst beim Sichtbarwerden.

Kann Astro Server-Rendering wie Next.js?

Ja. Astro kann Seiten bei jeder Anfrage auf dem Server rendern, mit Adaptern für Node.js, Cloudflare, Netlify und Vercel. Mit Server Islands lassen sich einzelne dynamische Bereiche in sonst statische Seiten einsetzen. Funktionen wie ISR in der Form von Next.js gibt es nicht eingebaut, ähnliches erreicht man über Cache-Header und ein CDN.

Ist Next.js für einen Blog übertrieben?

Für einen reinen Blog meistens ja. Next.js funktioniert für Blogs einwandfrei und erreicht auch gute Lighthouse-Werte, liefert aber auf jeder Seite die React-Laufzeit mit, die ein Artikel zum Lesen nicht braucht. Wenn der Blog Teil einer größeren Next.js-Anwendung ist, kann es trotzdem sinnvoll sein, alles in einem Projekt zu halten.

Ist Astro gut für SEO?

Ja. Astro liefert fertiges HTML, das Suchmaschinen ohne JavaScript lesen können, und erreicht sehr gute Core Web Vitals. Sitemaps, Canonical-Tags und strukturierte Daten lassen sich einfach einbauen. Next.js ist ebenfalls gut für SEO, solange Seiten serverseitig oder statisch gerendert werden.

Gehört Astro jetzt zu Cloudflare?

Die Firma hinter Astro, The Astro Technology Company, wurde im Januar 2026 von Cloudflare übernommen. Das Framework selbst bleibt Open Source unter MIT-Lizenz und läuft weiterhin auf allen Plattformen. Next.js wird von Vercel entwickelt, ist ebenfalls Open Source und läuft auch ohne Vercel.

Welches Framework ist leichter zu lernen?

Astro. Eine Astro-Komponente sieht aus wie HTML mit einem kleinen Skriptblock. Für Next.js musst du React verstehen und zusätzlich die Unterscheidung zwischen Server- und Client-Komponenten, das Routing über Ordner und das Caching-Verhalten. Wer bereits React kann, findet sich in Next.js allerdings schnell zurecht.

Kann ich mit Astro einen Onlineshop bauen?

Für kleine Shops mit wenig Produkten und einem externen Checkout (etwa Shopify Buy Button oder Stripe Checkout) ja. Für Shops mit Warenkorb-Logik, Kundenkonten und vielen Filtern ist ein Anwendungs-Framework wie Next.js oder ein fertiges Shopsystem meist die bessere Wahl. Ein Mittelweg ist ein Headless-Shop mit Astro für die Produktseiten und Inseln für den Warenkorb.

Kann man Astro und Next.js kombinieren?

Ja, und das ist oft eine gute Lösung. Typisch ist eine Marketing-Seite in Astro unter der Hauptdomain und die eigentliche Anwendung in Next.js unter einer Subdomain oder einem Unterpfad hinter einem Reverse Proxy. Gemeinsame React-Komponenten können in beiden Projekten verwendet werden.

Fazit

Der Vergleich Astro vs Next.js hat in unserem Test ein klares, aber kein einseitiges Ergebnis. Für einen Blog mit 200 Artikeln war Astro in jeder Messung vorne: kein JavaScript statt 174 KB pro Seite, halb so lange Zeit bis zum größten Element, schnellerer Build mit halbem Speicher, fast dreimal so viele Anfragen pro Sekunde. Gleichzeitig hat Next.js die volle Lighthouse-Punktzahl erreicht und tausende Anfragen pro Sekunde geschafft. Es ist kein langsames Framework, es ist nur für eine andere Aufgabe gebaut.

Unsere Empfehlung ist deshalb einfach: Frag nicht, welches Framework besser ist, sondern ob du eine Website oder eine Anwendung baust. Für eine Website nimm Astro. Für eine Anwendung nimm Next.js. Und wenn du beides hast, nimm beide. Wir machen es genauso: getmind.io läuft auf Astro, unsere Anwendungen laufen auf Next.js, auf demselben Server, jeweils mit dem Werkzeug, das zur Aufgabe passt.