Wenn ein Frontend gewählt wird, fällt die Entscheidung erstaunlich oft nur zwischen den „großen": Next, Nuxt, vielleicht SvelteKit. Die Frage davor — braucht diese Seite das überhaupt? — wird übersprungen.
Ich habe das an meiner eigenen Seite durchgespielt: migriert von einer statischen Astro-Seite hin zu Astro plus Payload CMS. Der Grund war kein Framework-Frust, sondern die Pflege der Inhalte — und der Wunsch, an einem echten Projekt zu prüfen, was die Technik dahinter wirklich leistet. Es hätte genauso ein Wechsel von Next auf Astro sein können; die Lehre ist dieselbe.
Die Entscheidung, die meist gar nicht getroffen wird
Das eigentliche Problem ist nicht „Astro oder Next", sondern dass die Auswahl auf „welches der großen Frameworks" verkürzt wird. Astro steht selten überhaupt auf der Liste — obwohl es für eine Website, eine Landingpage oder eine Marketing-Seite vollkommen ausreicht und in Wartung, Performance und Ballast oft die bessere Wahl ist.
Wo Astro konkret gewinnt: Islands und JS-Last
Das ist der Kern. Die meisten Marketing-Seiten zeigen Inhalt, einen Slider, ein bisschen Animation. Ein SPA-first-Framework liefert dafür eine JavaScript-Laufzeit aus — ob man sie nutzt oder nicht. Astros Islands-Modell liefert standardmäßig HTML und JavaScript nur für die wenigen interaktiven Stellen. Weniger ausgeliefertes JavaScript ist der größte einzelne Hebel für Pagespeed.
Genau deshalb fallen gute Pagespeed-Werte mit Astro leichter — nicht, weil Astro einen magischen Optimierer hätte, sondern weil der Standard „kein JavaScript, solange nicht gefragt" ist. Man erreicht die Werte, indem man das Problem gar nicht erst ausliefert. SSR funktioniert dabei genauso wie anderswo — man ist nur leichtfüßiger unterwegs.
Wo Next.js die richtige Wahl bleibt
Next hat seinen Platz, und der ist real: E-Commerce, große Anwendungen mit viel dynamischem Inhalt, tief interaktive Produkt-Oberflächen, ein gemeinsamer Stack mit dem Backend. Da trägt das Gewicht etwas.
Selbst dort lohnt sich inzwischen der Blick, ob Astro es nicht auch trägt. Das hier ist kein Anti-Next-Text. Es geht darum, Next nicht reflexhaft für eine Broschüren-Seite zu nehmen, nur weil es das bekannte Werkzeug ist.
Der scheinbare Widerspruch: diese Seite läuft auch auf Next
Die Pointe: Genau diese Seite enthält eine Next.js-App. Sie ist ein pnpm-Monorepo aus zwei Teilen — das öffentliche Frontend in Astro 6 mit Tailwind, und ein Payload-CMS, das, weil Payload v3 Next.js-nativ ist, als schlanke Next-App läuft.
Heruntergebrochen aufs Wesentliche sieht das so aus:
michaelseliger.com/ pnpm-Monorepo
├── apps/
│ ├── web/ Astro 6 — die öffentliche Seite
│ │ └── src/
│ │ ├── pages/ Datei-Routing (/, /de/...)
│ │ └── lib/payload.ts EINZIGE Stelle, die das CMS aufruft
│ └── cms/ Payload auf Next.js — nur CMS-Host
│ └── src/
│ ├── collections/ Posts, Pages, ...
│ └── payload-types.ts auto-generierte Typen
├── .env eine Quelle (per-App-Symlinks)
└── pnpm-workspace.yaml packages: apps/*Die Kopplung zwischen beiden ist bewusst dünn — und genau deshalb leicht nachzubauen. Das Web liest die Typen des CMS über einen tsconfig-Alias, ohne die Datei je zu kopieren:
// apps/web/tsconfig.json
{
"compilerOptions": {
"paths": {
"@cms-types": ["../cms/src/payload-types.ts"]
}
}
}Und es holt die Inhalte über genau eine typisierte Stelle, per API-Key gegen die Payload-REST-API:
// apps/web/src/lib/payload.ts (vereinfacht)
import type { Post } from '@cms-types'
const PAYLOAD_URL = process.env.PAYLOAD_URL ?? 'http://localhost:3000'
const API_KEY = process.env.PAYLOAD_API_KEY ?? ''
async function payloadFetch<T>(path: string): Promise<T> {
const headers = new Headers({ Accept: 'application/json' })
if (API_KEY) headers.set('Authorization', `users API-Key ${API_KEY}`)
const res = await fetch(`${PAYLOAD_URL}/api${path}`, { headers })
if (!res.ok) throw new Error(`Payload ${res.status}`)
return (await res.json()) as T
}
export const getPosts = (locale: 'de' | 'en') =>
payloadFetch<{ docs: Post[] }>(`/posts?locale=${locale}`)Mehr Verbindung gibt es nicht: ein Typ-Alias und ein Fetch-Modul. Next macht, worin es wirklich gut ist — die Admin- und App-Fläche des CMS, samt Live-Preview. Astro macht, worin es gut ist — schnelle, schlanke Inhalts-Auslieferung, zweisprachig DE/EN, deployt über Dokploy. Die Trennung ist hier die Architektur, kein Kompromiss.
Fazit
Die Frontend-Entscheidung ist nicht „welches der großen Frameworks", sondern „was tut diese Seite eigentlich?". Für Marketing- und Content-Seiten ist die Antwort meistens Astro: weniger zu warten, weniger JavaScript, schneller von Haus aus. Die schweren Frameworks hebt man sich für die Stellen auf, an denen ihr Gewicht etwas einbringt.
Wenn bei Ihnen gerade die Frontend-Entscheidung ansteht und Sie eine nüchterne Einordnung statt eines Framework-Glaubenskriegs wollen: Das ist Teil meiner Arbeit im Technical Consulting.