← Magazin 22. Mai 2026

Framework · 11 min

Astro 5 versus Next.js 15 — zwei Architekturen für statisch dominierte Sites

Astro 5 und Next.js 15 lösen das Problem „Marketing-Page mit Interaktivitäts-Inseln" auf zwei radikal verschiedene Arten. Ein nüchterner Vergleich der Architekturen, der Bundle-Sizes und der Grenzen — mit Code in beiden Frameworks.

Anfang 2026 stehen zwei Frameworks im DACH-Frontend so prominent für content-getriebene Sites wie kein anderes Paar: Astro 5, stabil seit Dezember 2024, und Next.js 15, stabil seit Oktober 2024. Beide reklamieren für sich, das richtige Werkzeug für „statisch dominierte” Web-Anwendungen zu sein — Marketing-Pages, Blogs, Produktdokumentation, Magazine, Doc-Portale. Beide kommen aus völlig anderen architektonischen Welten. Und beide haben in den letzten Monaten Updates ausgeliefert, die die Trennlinie schärfer gemacht haben, nicht unschärfer.

Wer 2026 zwischen den beiden wählt, sollte verstehen, was er wählt — nicht nur welche Features im Marketing stehen.

Astro 5 in einer Minute

Astro hat sich um das Konzept der Islands organisiert. Eine Page ist standardmäßig HTML. Punkt. JavaScript wird erst dort hydratisiert, wo eine interaktive Komponente — eine „Island” — explizit deklariert ist:

---
// src/pages/index.astro
import Hero from '../components/Hero.astro';
import Counter from '../components/Counter.tsx';
---

<html lang="de">
  <body>
    <Hero />
    <Counter client:visible />
  </body>
</html>

<Hero /> ist eine reine Astro-Komponente — sie rendert zu HTML und sendet null Bytes JavaScript. <Counter client:visible /> ist eine React-Komponente, die hydratisiert wird, sobald sie im Viewport sichtbar wird. Der Rest der Page bleibt HTML.

Astro 5 hat zwei Dinge zugefügt, die die Architektur ernster gemacht haben:

Server Islands. Eine Komponente kann server:defer markiert werden, wird dann beim Initial-Request mit einem Fallback gerendert, und der echte Inhalt wird per Streaming nachgereicht — ohne dass Client-JS für die Komponente nötig wäre:

---
import UserBadge from '../components/UserBadge.astro';
---

<UserBadge server:defer>
  <p slot="fallback">Lädt…</p>
</UserBadge>

Personalisierter Content (Login-Status, Warenkorb-Zähler) lebt damit auf einer eigenen Caching-Schicht, ohne die ganze Page dynamisch zu machen.

View Transitions als First-Class-Feature. <ClientRouter /> aus astro:transitions macht aus Multi-Page-Apps Single-Page-Apps mit nativen View Transitions auf modernen Browsern und sauberem Fallback auf älteren.

Dazu kommt Astro DB (libSQL/Turso-basiert) als optionale Datenschicht, Content Layer als typsicheres Content-Modul-System und ein Adapter-Modell, das Cloudflare Workers, Netlify, Vercel, Node und Deno als gleichwertige Deploy-Targets behandelt.

Next.js 15 in einer Minute

Next.js 15 hat eine andere Geschichte. Der App Router, seit Next 13 in Beta und seit Next 14 stabil, ist in Version 15 der einzige empfohlene Pfad. Der Pages Router wird weiter unterstützt, bekommt aber keine neuen Features mehr. Das Default-Rendering-Modell sind React Server Components (RSC):

// app/page.tsx
import { Hero } from '@/components/hero';
import { Counter } from '@/components/counter';

export default async function Page() {
  const featured = await fetchFeatured();
  return (
    <main>
      <Hero items={featured} />
      <Counter />
    </main>
  );
}

<Hero /> ohne "use client" rendert serverseitig zu HTML und sendet ihren JSX-Output als RSC-Payload mit — kein Komponenten-Code im Bundle. <Counter /> hat "use client" an der Dateispitze und landet im Client-Bundle. Die Grenze zwischen Server- und Client-Komponenten ist explizit deklariert, nicht implizit.

Next 15 hat zwei wichtige Erweiterungen:

Partial Prerendering (PPR). Eine Page kann statisch vorgerendert werden, einzelne dynamische Slots werden zur Request-Zeit aufgefüllt — als Stream, in derselben Response. Damit fällt die strikte Trennung zwischen getStaticProps und getServerSideProps weg. Eine Marketing-Page kann zu 95 % aus dem Edge-Cache kommen und nur den Header (Login-Status) on-request laden.

Turbopack ist in Next 15 für Production-Builds als opt-in verfügbar, in Next 15.2 als stable, in Next 16 als Default angekündigt. Build-Zeiten in mittleren Codebases (5.000–15.000 Module) liegen damit etwa bei einem Viertel des Webpack-Werts.

Dazu kommen Server Actions als integrierter RPC-Layer, Streaming Suspense Boundaries überall, und ein Caching-Modell, das in Next 14 berüchtigt aggressiv war und in Next 15 deutlich entschärft wurde — fetch() ist nicht mehr per Default gecached, der opt-in über { cache: 'force-cache' } ist explizit.

Architektonischer Kernunterschied

Der eigentliche Unterschied ist nicht „Astro ist schneller” oder „Next ist mächtiger”. Der Unterschied ist:

Astro ist HTML mit JS-Inseln. Next ist React mit Server-Rendering.

Das klingt nach Wortspiel, ist aber operativ entscheidend. In Astro ist der Default null Hydration. Wenn du nichts tust, läuft kein einziger Zeile Client-JavaScript. In Next ist der Default React. RSC reduziert das Bundle, aber die React-Runtime selbst, das Hydration-Framework, der Router — das ist Sockel-Kost, die immer mitkommt.

Daraus folgt die zweite Asymmetrie. Astro ist framework-agnostisch. Du kannst auf derselben Page eine React-Island, eine Vue-Island, eine Svelte-Island und eine Solid-Island gemeinsam betreiben. Das klingt nach Spielerei, ist aber im Migrationsszenario Gold wert — eine bestehende Site mit React-Komponenten lässt sich nach Astro portieren, ohne dass eine einzige Komponente neu geschrieben werden müsste. Next ist React-monolithisch. Eine Vue-Komponente in einer Next-App ist kein vorgesehener Pfad.

Performance: die nüchternen Zahlen

Für statisch dominierte Sites — Marketing, Blogs, Dokumentation — sind die typischen Bundle-Größen 2026 wie folgt. Die Zahlen beziehen sich auf Production-Builds einer Standard-Marketing-Page mit Hero, drei Content-Sektionen, einem Kontaktformular und einer Theme-Toggle-Komponente.

	Astro 5	Next.js 15
HTML	18 KB	14 KB
JS initial	5–15 KB	70–120 KB
JS lazy (interaction)	8–25 KB	0–40 KB
Time to Interactive (4G median)	0.8–1.2 s	1.6–2.4 s
Lighthouse Performance	98–100	88–95

Die Astro-Zahlen sind die schlankeren, weil das Framework selbst kein Runtime-Overhead in die Page schiebt — was eingebunden wird, ist genau das, was die Islands brauchen. Next’s 70–120 KB sind die React-Runtime, der App-Router-Code und der RSC-Reconciler. Das ist seit Next 14 → 15 erkennbar geschrumpft (RSC reduziert den Client-Anteil deutlich), aber die Basis bleibt React, und React ist nicht null.

Für eine reine Content-Page macht das einen messbaren Unterschied im Largest Contentful Paint und im INP (siehe das Schwester-Artikel zur Core-Web-Vitals-Reform). Für eine App-Page mit komplexem State und vielen Server-Roundtrips ist der Unterschied gering, weil dort die Server-Latenz dominiert und nicht das Initial-Bundle.

Code-Vergleich: dieselbe Marketing-Page

Astro 5

---
// src/pages/index.astro
import Layout from '../layouts/Base.astro';
import Hero from '../components/Hero.astro';
import FeatureGrid from '../components/FeatureGrid.astro';
import NewsletterForm from '../components/NewsletterForm.tsx';
import { getCollection } from 'astro:content';

const features = await getCollection('features');
---

<Layout title="Viewport — Frontend Magazin">
  <Hero />
  <FeatureGrid items={features} />
  <NewsletterForm client:visible />
</Layout>

<NewsletterForm /> ist die einzige interaktive Komponente. Sie kommt aus React (.tsx) und wird per client:visible erst hydratisiert, wenn sie in den Viewport scrollt. Der Rest der Page ist HTML.

Bundle-Output (Production-Build): 8 KB JS für die Newsletter-Komponente plus React-Runtime, lazy geladen on viewport entry. Initial JS: 0 KB. HTML enthält den vollen Content vorgerendert.

Next.js 15

// app/page.tsx
import { Hero } from '@/components/hero';
import { FeatureGrid } from '@/components/feature-grid';
import { NewsletterForm } from '@/components/newsletter-form';
import { getFeatures } from '@/lib/content';

export default async function HomePage() {
  const features = await getFeatures();
  return (
    <main>
      <Hero />
      <FeatureGrid items={features} />
      <NewsletterForm />
    </main>
  );
}

// components/newsletter-form.tsx
'use client';

import { useState } from 'react';

export function NewsletterForm() {
  const [email, setEmail] = useState('');
  // ...
}

<Hero /> und <FeatureGrid /> sind RSCs, ihr Code geht nicht ins Bundle. <NewsletterForm /> ist Client-Komponente, sie wird hydratisiert.

Bundle-Output: 96 KB JS initial (React + Router + RSC-Reconciler + Newsletter-Form), wird beim Page-Load geparsed.

Funktional identisch. Architektonisch verschieden.

Wann was

Die Heuristik 2026, soweit sie sich aus zwei Jahren praktischer Erfahrung verdichten lässt:

Astro 5 für:

Marketing-Sites, Landing-Pages, Produktportale
Blogs, Magazine, Editorial-Sites
Technische Dokumentation, API-Referenzen
E-Commerce mit geringem dynamischen Anteil (Katalog statisch, Cart als Island)
Migration bestehender Multi-Framework-Sites
Sites mit harten Performance-Budgets

Next.js 15 für:

App-Dashboards mit komplexem State Management
B2B-SaaS mit tiefer React-Komponenten-Bibliothek
Sites mit serverseitiger Autorisierung als zentralem Mechanismus
Anwendungen, die Server Actions als RPC-Schicht produktiv nutzen
Projekte, die im React-Ökosystem (Next-Auth, TanStack Query in RSC-Modus, Drizzle in RSC) tief verzahnt sind

Schwächen — wo das jeweilige Framework klemmt

Astro klemmt bei komplexem Routing mit Auth-State. Ein App-Dashboard mit Login-Wall, geschützten Routes, Rolle-basiertem Routing, persistentem Sidebar-State über Routenwechsel — das geht in Astro, aber es ist viel Klebcode. View Transitions helfen, lösen aber nicht das Grundproblem, dass Astro für Multi-Page denkt. Wer State über Routengrenzen hinweg synchronisieren muss, baut entweder eine SPA-Island, die die halbe Page einnimmt — was den Punkt der Islands aushöhlt — oder weicht auf Next aus.

Next klemmt bei Bundle-Size-sensitiven Marketing-Pages. Die 70–120 KB sind keine Frage des Wollens; sie sind die React-Sockelkost. Für eine Page, die in unter 1 Sekunde Time-to-Interactive im 3G-Szenario sein muss, ist Next strukturbedingt im Nachteil. Hinzu kommt die App-Router-Lernkurve: RSC vs. Client Components, cache() vs. unstable_cache() vs. fetch({ cache }), Server Actions mit FormData vs. JSON — das Modell hat viele Stellschrauben, und die Doku ist 2026 immer noch nicht so klar wie der Code es bräuchte.

Was bleibt

Astro und Next sind keine Konkurrenten im engen Sinn. Sie lösen unterschiedliche Probleme mit unterschiedlichen Annahmen. Astro nimmt an, dass die meisten Bytes einer Page Content sind und nicht App-Code. Next nimmt an, dass die meisten Pages App-Logik sind, die nur zufällig auch Content ausspielt. Welche Annahme stimmt, hängt nicht vom Framework ab — sie hängt vom Projekt ab.

Wer 2026 eine Marketing-Site neu beginnt und reflexartig zu Next greift, weil „React halt der Standard ist”, trägt 100 KB JS in den Production-Bundle, die er nicht braucht. Wer ein App-Dashboard mit Astro angeht, weil „Astro halt schneller ist”, schreibt Wochenarbeit für Routing- und State-Probleme, die in Next mit zwei Hooks gelöst wären.

Die ehrliche Antwort auf „Astro oder Next?” lautet 2026 wie 2024: Was baust du eigentlich? Wer das beantworten kann, hat die Wahl schon getroffen.

Ressort: Framework ▮

Viewport_