Inhalt
Beide Frameworks docken sauber an ein WordPress-Backend an — die Entscheidung fällt nicht an der Schnittstelle, sondern am Interaktivitätsbedarf des Frontends. Astro ist die schlankere Wahl für inhaltslastige, wenig interaktive Sites, weil es standardmässig kein clientseitiges JavaScript ausliefert. Next.js ist die robustere Wahl für app-artige Frontends, häufig aktualisierte Inhalte via ISR und Projekte, die tief im React-Ökosystem stehen. Wer die Grundlagen der Trennung von Backend und Frontend zuerst sucht, findet sie im Beitrag dazu, was Headless WordPress technisch ist.
Dieser Beitrag vergleicht beide entlang der Achsen, die in einem Headless-Projekt tatsächlich zählen: Rendering-Modelle, Performance-Default, Entwickler-Erfahrung, WPGraphQL-Anbindung und Interaktivität. Offenlegung vorweg: Diese Seite läuft selbst auf Next.js — das ändert nichts daran, dass Astro für einen grossen Teil typischer Marketing- und Content-Sites die bessere technische Wahl ist. Genau diese ehrliche Abgrenzung ist das Ziel.
Worin unterscheiden sich die Rendering-Modelle?
Der grösste Unterschied liegt im Default-Verhalten. Astro generiert jede Seite standardmässig zu HTML und CSS und entfernt clientseitiges JavaScript automatisch — interaktive Teile werden als einzelne Inseln hydratisiert, gesteuert über client:load, client:visible oder client:idle (Astro Docs, Islands). Next.js geht den umgekehrten Weg: Es baut auf React auf, das clientseitige Laufzeit mitbringt, und reduziert von dort aus.
Beim statischen Vorrendern sind sich beide ähnlich — sie erzeugen HTML zur Build-Zeit. Für häufig aktualisierte WordPress-Inhalte hat Next.js mit Incremental Static Regeneration (ISR) einen ausgereiften Mechanismus: Zwischengespeicherter Inhalt wird sofort ausgeliefert und im Hintergrund neu generiert, gesteuert per revalidate-Wert pro Seite, ohne kompletten Rebuild (Next.js Docs, ISR). Astro deckt denselben Bedarf seit Astro 5.0 über Server Islands ab: SSG und SSR wurden vereinheitlicht, und einzelne Routen werden allein durch Hinzufügen eines Adapters für Node, Netlify, Vercel oder Cloudflare zur Laufzeit serverseitig gerendert (Astro 5.0 Announcement).
Architektonisch heisst das: Next.js denkt von der React-Anwendung her und macht sie statisch, wo es geht. Astro denkt vom statischen Dokument her und fügt Interaktivität nur punktuell hinzu. Beide erreichen statisches HTML, beide können on-demand rendern — der Unterschied ist, was der jeweilige Default ohne Zutun ausliefert.
Welches Framework liefert den besseren Performance-Default?
Im unveränderten Default-Zustand liefert Astro messbar weniger JavaScript aus. Der HTTP Archive Web Almanac misst für vorgerenderte Sites im Median 164 KB JavaScript bei Astro gegenüber 583 KB bei Next.js — rund 3,5-mal mehr; die Gesamt-Transfergrösse liegt bei 889 KB (Astro) gegenüber 1'659 KB (Next.js) (HTTP Archive Web Almanac 2024, Jamstack). Diese Zahlen sind Mediane ausschliesslich der prerendered-Kohorte — keine Aussage über jede einzelne Astro- oder Next.js-Site, aber ein klarer Hinweis auf das, was der Default produziert.
Dieser Unterschied zählt, weil JavaScript-Last grundsätzlich wächst und oft ungenutzt bleibt. Der Median-JavaScript-Umfang einer Seite stieg 2024 auf 613 KB (Desktop) und 558 KB (Mobile), und rund 44 % der ausgelieferten Bytes bleiben auf Mobile beim Laden ungenutzt (HTTP Archive Web Almanac 2024, JavaScript). Wer den Default schlank hält, statt nachträglich zu optimieren, startet auf der richtigen Seite dieser Kurve.
Für die Sichtbarkeit ist das relevant: Google empfiehlt einen Largest Contentful Paint innerhalb der ersten 2,5 Sekunden, und die Core Web Vitals sind Teil der Page-Experience-Signale, bewertet anhand von Felddaten realer Nutzer (Google Search Central, Core Web Vitals). Google selbst formuliert den Ranking-Einfluss zurückhaltend — kein riesiger Faktor, aber mehr als ein Tiebreaker. Dass vorgerenderte Sites zu 41 % gute Core Web Vitals erreichen, hybride nur zu 31 % und dynamische zu 33 %, ist eine Korrelation, keine Kausalität (HTTP Archive Web Almanac 2024, Jamstack). Die Richtung ist trotzdem deutlich: weniger ausgeliefertes JavaScript, bessere Feldwerte.
Astro startet bei null clientseitigem JavaScript und fügt es nur dort hinzu, wo eine Insel es braucht — Next.js startet bei React und reduziert von dort.
Wichtig zur Einordnung: Next.js ist nicht langsam. Ein sorgfältig gebautes Next.js-Frontend erreicht ausgezeichnete Werte — es erfordert nur bewusste Arbeit am Bundle. Astro verlangt diese Arbeit seltener, weil sein Ausgangspunkt schon schlank ist.
Wie unterscheidet sich die WPGraphQL-Anbindung?
Bei der Anbindung an WordPress nehmen sich beide Frameworks wenig — der Unterschied liegt nicht im Anschluss, sondern im Datenfluss danach. WordPress liefert mit der REST API unter /wp-json/wp/v2/ standardmässig eine Datenschnittstelle; WPGraphQL oder Gato GraphQL lassen sich optional installieren, und Astro holt die Daten typischerweise zur Build-Zeit für statisches HTML (Astro Docs, Headless WordPress). Next.js fragt dieselben Endpunkte ab, üblicherweise über Server Components oder einen Datenabruf im Build, und kombiniert das mit ISR für die Aktualisierung.
Die Wahl zwischen GraphQL und REST hängt am Projekt, nicht am Frontend-Framework — beide Frameworks sprechen beide Protokolle. Welche Variante für welchen Datenbedarf sinnvoll ist, vertieft der Beitrag zu WPGraphQL gegenüber der REST API, statt das Argument hier zu wiederholen.
Welches Framework gewinnt bei Interaktivität?
Bei app-artiger Interaktivität gewinnt Next.js, bei punktueller Interaktivität auf Content-Seiten gewinnt Astro. Next.js ist als React-Anwendungsframework gebaut — geteilter Client-State über viele Routen, komplexe Formularflüsse, Dashboards und eingeloggte Bereiche sind genau sein Terrain. Astro hingegen behandelt Interaktivität als Inseln in einem ansonsten statischen Dokument: ideal für ein Suchfeld, einen Konfigurator oder ein Karussell auf einer sonst ruhigen Seite, weniger ideal für ein durchgängig interaktives Single-Page-Erlebnis.
Bemerkenswert: Astro zwingt niemanden weg von React. Es unterstützt React, Preact, Solid, Svelte und Vue offiziell und erlaubt sogar, mehrere davon auf derselben Seite zu mischen (Astro Docs, Islands). Bestehende React-Komponenten lassen sich als Inseln einbinden. Der Lock-in-Vorwurf greift also nicht — was Astro nicht bietet, ist das durchgängige React-Routing-Modell mit gemeinsamem Client-State, das Next.js zur Grundlage macht.
Daraus folgt eine brauchbare Faustregel: Je mehr eine Seite sich wie ein Dokument anfühlt, desto eher Astro. Je mehr sie sich wie eine Anwendung anfühlt, desto eher Next.js. Die meisten Marketing-, Blog- und Unternehmensseiten sind Dokumente mit Inseln; Buchungssysteme, Kundenportale und Konfiguratoren sind Anwendungen.
Wann passt welches Framework? — die Entscheidungstabelle
Die Wahl lässt sich an wenigen Projektprofilen festmachen. Die folgende Tabelle ordnet typische Headless-WordPress-Szenarien einer Empfehlung zu — als Ausgangspunkt für ein Gespräch, nicht als starres Gesetz.
| Projektprofil | Empfehlung | Warum |
|---|---|---|
| Marketing-/Content-Site, viel Text, wenig Interaktion | Astro | Default ohne clientseitiges JavaScript; schlankster Performance-Ausgangspunkt für inhaltslastige Seiten |
| Blog/Magazin mit Tausenden Seiten, häufige Updates | Next.js | ISR liefert zwischengespeicherte Seiten sofort und regeneriert im Hintergrund, ohne Full-Rebuild |
| App-artiges Frontend, eingeloggte Bereiche, Dashboards | Next.js | Geteilter Client-State über Routen, grosses React-Ökosystem, durchgängiges Anwendungsmodell |
| Landingpage oder Kampagnen-Site, Performance kritisch | Astro | Minimales JavaScript korreliert mit besseren Feld-Werten der Core Web Vitals |
| Team steht tief im React-Stack, vorhandene Komponenten | Next.js | Geringste Migrationsreibung; React ist hier first-class, nicht Insel |
| Gemischte Site mit punktueller Interaktivität (Suche, Konfigurator) | Astro mit Inseln | Statisches Dokument plus gezielte hydratisierte Komponenten via client:visible |
Was die Framework-Wahl nicht löst — der ehrliche Teil
Hier wird die Bewertung unbequem, und genau das gehört dazu. Die Wahl zwischen Next.js und Astro entscheidet weniger, als Framework-Debatten oft suggerieren — viele Projektrisiken liegen ganz woanders.
Performance entsteht nicht allein aus dem Framework. Ein schlecht konfiguriertes Astro-Setup mit überladenen Inseln kann langsamer sein als ein sorgfältig optimiertes Next.js. Die 164-KB-gegen-583-KB-Zahlen sind Mediane der prerendered-Kohorte (HTTP Archive Web Almanac 2024) — sie beschreiben Tendenzen, keine Garantie für Ihr konkretes Projekt. Bildgrössen, Caching, Hosting-Region und Datenabruf-Strategie wiegen im Alltag oft schwerer als die Framework-Marke.
Das WordPress-Backend bleibt unberührt. Welches Frontend auch immer rendert — Plugin-Pflege, API-Härtung und die Hosting-Entscheidung für das Backend bleiben dieselbe Aufgabe. Wo das Backend stehen sollte und was das kostet, ordnet der Beitrag zum Headless-WordPress-Hosting 2026 ein, statt es hier zu doppeln.
Die falsche Wahl ist selten ein Totalverlust, aber spürbar. Wer Astro für ein hochinteraktives, app-artiges Frontend wählt, baut komplexe Insel-Konstruktionen, die Next.js direkt mitbringt. Wer Next.js für eine reine Content-Site nimmt, verschenkt den Performance-Default. In unseren Schweizer Projekten 2024–2026 liess sich die Wahl fast immer am Interaktivitätsbedarf festmachen — in einem Fall reduzierte der Wechsel einer reinen Content-Site von einem unoptimierten React-Setup auf einen statischen, inselbasierten Aufbau das ausgelieferte JavaScript um deutlich mehr als die Hälfte, ohne dass eine einzige Funktion wegfiel.
Beide Frameworks entwickeln sich schnell. Was heute der Default ist, kann sich mit der nächsten Hauptversion verschieben — die hier beschriebenen Architekturprinzipien (Islands gegen React-Laufzeit, ISR gegen Server Islands) sind stabiler als jede einzelne Versionsnummer. Entscheiden Sie entlang des Modells, nicht entlang der Release-Notes.
Kurz: Die Framework-Wahl ist eine wichtige, aber keine schicksalhafte Entscheidung. Sie ist gut investierte Sorgfalt am Anfang — und kein Ersatz für saubere Arbeit am Backend, am Hosting und an der Datenstrategie.
Was bedeutet das für KI-Suchmaschinen?
Für die Sichtbarkeit in KI-Suchmaschinen wie ChatGPT, Perplexity und Gemini zählt zuerst schnell und zuverlässig ausgeliefertes HTML — und genau das liefern beide Frameworks beim statischen Vorrendern. Eine Princeton-Studie zur Optimierung für generative Suchmaschinen zeigt, dass zitierfähige Inhalte mit Quellenangaben und Statistiken die Sichtbarkeit in generativen Antworten deutlich steigern können, in der untersuchten Metrik um bis zu 40 % je nach Domäne (Aggarwal et al., GEO, KDD 2024).
Das ist primär eine Inhalts- und Schema-Frage, keine Framework-Frage. Beide, Astro und Next.js, können sauberes, semantisches HTML mit strukturierten Daten ausgeben. Der Vorteil eines schlanken Default liegt eher darin, dass statisches HTML ohne JavaScript-Abhängigkeit zuverlässiger von Crawlern und Antwort-Engines gelesen wird. Welches Framework dahintersteht, ist für die Zitierfähigkeit zweitrangig — der Inhalt entscheidet.
Nächster Schritt
Die Framework-Wahl entscheidet sich am Interaktivitätsbedarf, nicht an der Marke — und die lässt sich in einem kurzen Gespräch sauber einordnen. Ob Astro mit seinem schlanken Default oder Next.js mit ISR und React-Ökosystem für Ihr Projekt der bessere Frontend-Unterbau ist, hängt an wenigen, klar benennbaren Fragen. Wenn Sie ein Headless-Frontend planen oder ein bestehendes hinterfragen, vereinbaren wir gerne ein Erstgespräch — 15 Minuten, kostenlos.
Wer zuerst die technische Grundlage vertiefen will, findet auf der Themenseite zu Headless WordPress die Einordnung von Backend, API-Layer und Frontend — und in der Architektur-Kategorie im Blog die Beiträge zu API-Wahl, Hosting und Migration, die rund um die Frontend-Entscheidung mitspielen.