Astro vs Next.js: Die technische Wahrheit hinter 40 % schnellerer Performance bei statischen Websites

Bei der Framework-Wahl für einen Technik-Blog habe ich lange gezögert: Next.js kommt von Vercel und hat ein starkes React-Ökosystem; Astro hat in der Community einen guten Ruf – angeblich „explosive Performance“ und „Lighthouse-Volltreffer“. Vergleichsartikel im Netz widersprechen sich: mal Astro schneller, mal Next.js vollständiger – und man wird nur verwirrter.

Ich habe zwei Tage investiert und beide Frameworks mit identischem Inhalt getestet – zwei Blog-Versionen gebaut, Lighthouse gelaufen, Build-Zeiten verglichen und live deployed. Ergebnis: Astro springt im Lighthouse von 88 auf 100, der First Paint ist fast doppelt so schnell.

Dieser Artikel ist meine Zusammenfassung. Ohne Hype, mit echten Daten – Performance, Architektur, Ökosystem und Deployment in vier Dimensionen. Danach wissen Sie, welches Framework zu Ihnen passt.

Performance-Duell – wer ist wirklich der Speed-König?

Beim Astro-Next.js-Vergleich führt kein Weg an Performance vorbei. Für Blog oder Docs will man schnelle Ladezeiten und gutes SEO.

JavaScript-Volumen: 90 % Unterschied sind kein Scherz

Zuerst die greifbarsten Zahlen. Mit identischem Inhalt habe ich zwei Blogs gebaut (~30 Artikel, Code-Highlighting, Bilder) und die JavaScript-Bundle-Größe verglichen:

• Next.js Static Export: Startseite ~85 KB JS (gzip)
• Astro: Startseite ~8 KB JS (gzip)

Der Abstand ist real. Astros Angabe „90 % weniger JavaScript“ deckt sich mit meinen Messungen.

Warum so viel Unterschied? Architektur. Next.js packt selbst bei SSG React-Runtime, Hydration-Logik und Routing mit. Astro rendert standardmäßig reines HTML – ohne JavaScript, es sei denn, Sie setzen client:* an einer Komponente.

Kurz gesagt: Next.js liefert das komplette React-Paket, auch wenn Sie nur statischen Content zeigen; Astro liefert nur, was Sie wirklich brauchen.

Lighthouse: Astro trifft locker Volltreffer

Bundle-Größe allein reicht nicht – entscheidend ist die Nutzererfahrung. Mit Chrome DevTools Lighthouse habe ich beide Sites in Production auf Vercel gemessen:

Astro-Blog:

• Performance: 100
• Accessibility: 98
• Best Practices: 100
• SEO: 100

Next.js-Blog (SSG):

• Performance: 88
• Accessibility: 98
• Best Practices: 96
• SEO: 100

Der Performance-Abstand kommt vor allem von FCP (First Contentful Paint) und TTI (Time to Interactive). Astro schafft oft First Paint in ~0,5 s, Next.js braucht 1–1,5 s.

Unter Mobile-3G wird der Unterschied größer. Mit Slow-4G-Simulation bleibt Astro bei 95+, Next.js fällt auf ~75.

Für Blogs und Docs ist der Astro-Performance-Vorteil spürbar.

Build-Geschwindigkeit: bei großen Projekten noch deutlicher

Auch die Build-Zeit zählt. Bei einer 1.000-Seiten-Docs-Site (Starlight vs Nextra):

• Astro (Starlight): ~18 s
• Next.js (Nextra): ~52 s

Astro ist fast 3× schneller – ähnlich wie Astros Vergleich zu Gatsby.

Fairerweise: Next.js 15 hat Build-Performance stark verbessert (früher 80+ s, jetzt ~50 s durch Parallelisierung). Gegen Astro bleibt aber ein Gap.

Praxisbeispiele: wie große Unternehmen wählen

Zahlen allein reichen selten – Beispiele helfen.

Astro u. a.:

• IKEA Developer Docs
• NordVPN Blog
• Firebase Docs
• Cloudflare Developer Center

Gemeinsam: content-first, extreme Ladegeschwindigkeit, starkes SEO.

Next.js u. a.:

• Nike E-Commerce
• Spotify Marketing
• Hulu Content-Plattform
• Teile von TikTok

Next.js dominiert bei dynamischen Features, Interaktion und Personalisierung.

🔥 Verschwende keine Monate für ungenutzte Produkte! Teste deine SaaS-Nutzenversprechen mit Adsterra bei kleinem Budget →

Jetzt testen →Anzeige

Die Regel: reine Content-Sites → Astro; dynamische Interaktion → Next.js.

Technische Architektur – Islands vs RSC für statische Szenarien

Nach den Benchmarks die Frage: Welche Technik steckt hinter Astro und Next.js?

Astro Islands: Ozean aus HTML, Inseln aus Interaktion

Kern von Astro ist die Islands-Architektur. Die Seite ist ein „Ozean“ aus statischem HTML; nur wenige „Inseln“ (Suchfeld, Kommentare, Like-Button) brauchen JavaScript.

Standard: ganze Seite als statisches HTML. Mit client:* aktivieren Sie einzelne Komponenten:

---

import SearchBox from '../components/SearchBox.jsx'
import StaticHeader from '../components/Header.astro'

---

<StaticHeader /> <!-- Reines HTML, kein JS -->
<SearchBox client:load /> <!-- Insel: lädt JS -->

Vorteile:

1. JavaScript on demand: nur interaktive Teile
2. Isolierte Hydration: Inseln parallel, ohne sich zu stören
3. Flexible Strategien: client:load, client:idle, client:visible

Beispiel: Code-Highlighting per CSS (kein JS), Dark-Mode-Toggle mit client:load → Startseite nur ~5 KB JS.

Bei Next.js landet selbst statisches Highlighting im React-Runtime-Bundle.

Next.js RSC: Server Components entlasten den Client

Next.js 15 setzt auf React Server Components (RSC) – ähnliche Idee: serverseitig rendern, wo möglich.

Zwei Klassen:

1. Server Components (Default): serverseitig, kein JS im Browser
2. Client Components ('use client'): Interaktion, JS wird ausgeliefert

// app/components/Header.jsx
// Default: Server Component, kein JS
export default function Header() {
  return <header>My Blog</header>
}

// app/components/SearchBox.jsx
'use client' // Explizit Client-JS
import { useState } from 'react'
export default function SearchBox() {
  const [query, setQuery] = useState('')
  // ...
}

Ähnlich wie Astro Islands – aber mit Unterschieden:

1. Default-Verhalten

• Astro: Zero-JS, Inseln manuell
• Next.js: React-Runtime bleibt, weniger Komponenten-Code

2. Szenarien

• Astro Islands: statisch + wenig Interaktion
• Next.js RSC: viel Dynamik, serverseitiges Data Fetching

3. Framework-Bindung

• Astro: React, Vue, Svelte mischbar
• Next.js: React-first

Statische Sites: wer passt besser?

Bei rein statischem Content (Blog, Docs, Portfolio) sind Astro Islands leichter. Ein reiner Markdown-Blog kann komplett ohne JS laufen; Next.js braucht mindestens ~40–50 KB Runtime.

Bei häufigen Content-Updates punktet Next.js ISR: CMS-Anbindung, selektives Regenerieren einzelner Seiten statt Full Rebuild.

Astro 4+ bietet Server Islands für verzögertes dynamisches Rendering – ISR von Next.js ist aber noch ausgereifter.

Empfehlung:

• Über 90 % statisch: Astro
• Häufige Updates: Next.js + ISR
• Hybrid: je nach Team-Stack, beides möglich

Funktionen und Ökosystem – Developer Experience im Vergleich

Markdown: Astro out of the box, Next.js braucht Setup

Für Blog oder Docs ist Astro deutlich angenehmer.

Astro Markdown:

• .md in src/pages/ → sofort Seite
• MDX integriert
• Content Collections für typsicheres Content Management:

// src/content/config.ts
import { defineCollection, z } from 'astro:content'

const blog = defineCollection({
  schema: z.object({
    title: z.string(),
    date: z.date(),
    tags: z.array(z.string())
  })
})

export const collections = { blog }

TypeScript-Typen, RSS, Sitemap – wenig Aufwand.

Next.js Markdown:

• @next/mdx oder next-mdx-remote
• remark/rehype selbst verdrahten
• oft contentlayer o. Ä.

Next.js geht – Astro ist für Einsteiger schneller am Ziel.

Framework-Kompatibilität: Astro als Multi-Framework-Hub

Astro erlaubt React, Vue, Svelte, Solid, Preact im selben Projekt:

---

import ReactNav from './ReactNav.jsx'
import VueForm from './VueForm.vue'
import SvelteChart from './SvelteChart.svelte'

---

<ReactNav client:load />
<VueForm client:visible />
<SvelteChart client:idle />

Next.js ist React-zentriert – kein Nachteil, aber andere Positionierung.

Für statische Sites ist Astros Flexibilität ein echter Vorteil: bestehende Komponenten wiederverwenden.

Plugin-Ökosystem: Next.js Masse, Astro Fokus

Next.js:

• Riesiges npm/React-Ökosystem
• Vercel-Integrationen (Analytics, Edge Config, KV)
• sehr aktive Community

Astro:

• 400+ offizielle und Community-Integrationen
• Starlight für Docs
• Bildoptimierung, Sitemap, RSS offiziell

Für Blog/Docs reicht Astro. Für komplexe Apps gewinnt React via Next.js.

Lernkurve

Astro: HTML/CSS/JS reichen; .astro-Syntax ähnlich Vue SFC; Docs klar – in ~10 Minuten startklar.

Next.js: React nötig; App Router mit Server/Client Components, Layouts, Data Fetching – mehr Konzepte.

Für einen schnellen Blog ist Astro oft angenehmer.

Docs-Lösungen: Starlight vs Nextra

Astro Starlight:

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

• Offiziell, tief integriert
• Sidebar, Suche, i18n automatisch
• Lighthouse-tauglich, modernes Theme

Next.js Nextra:

• Von Vercel, auf Next.js
• stark anpassbar, React-Komponenten
• etwas langsamer als Starlight, aber solide

Mit Starlight hatte ich eine Docs-Site in ~2 Stunden inkl. Deployment – sehr reibungslos.

Anwendungsfälle – Entscheidungsbaum

Wann Astro?

Mindestens zwei Treffer → Astro:

1. Content first, Interaktion second

• Blog, Docs, Unternehmensseite, Landing
• ~90 %+ statischer Inhalt
• wenig Interaktion (Suche, Kommentare, Dark Mode)

2. Performance und SEO sind harte KPIs

• Lighthouse nahe 100
• Core Web Vitals relevant für Ranking
• viele Mobile-/Schwachnetz-Nutzer

3. Markdown-Workflow

• Artikel in Markdown, lokale Bilder
• typsichere Content API
• RSS/Sitemap out of the box

4. Multi-Framework

• React und Vue im Team
• Komponenten wiederverwenden
• keine Single-Framework-Bindung

5. Schneller Start

• wenig Framework-Theorie
• in Minuten lauffähige Site
• heterogener Team-Stack

Wann Next.js?

1. Dynamische Content-Updates

• Headless CMS (Contentful, Sanity)
• ISR für zeitgesteuertes Regenerieren
• UGC (Kommentare, Likes)

2. Komplexe dynamische Routen

• E-Commerce, Community, viel SSR-Data-Fetching

3. React-first

• Team lebt React
• spezifische React-Libraries
• Auth, Analytics, Edge Functions im Next.js-Stack

4. Hybrid-Rendering

• statische und SSR-Seiten gemischt
• Personalisierung nach Login
• API Routes als BFF

5. Vercel-Ökosystem

• Deployment und Integrationen auf einer Plattform

Praxis: Migrationsgeschichten

Next.js → Astro:

• situ2001 Blog: statisch, Lighthouse 88→100, Build halbiert
• Tech-Docs (~1.000 Seiten): Build 80 s→20 s, First Paint ~40 % schneller

Gründe: kein schwerer React-Runtime, Performance, besseres Markdown.

Next.js bleibt sinnvoll:

• Online-Lernplattform mit Login und Fortschritt
• E-Commerce mit ISR
• SaaS-Marketing mit dynamischen Demos

Gründe: SSR/Dynamik, React-Know-how, Vercel-Workflow.

Migrationskosten

Gering (1–2 Tage):

• reiner Markdown-Blog
• keine komplexen React-Komponenten
• keine Next.js-spezifischen APIs

Mittel (1–2 Wochen):

• eigene React-Komponenten (Astro Islands)
• Bildpipeline anpassen
• Layout/Routing neu

Hoch (nicht empfohlen):

• viele Hooks/State
• API Routes, Middleware
• komplexes serverseitiges Data Fetching

Faustregel: ~90 % statisch → Migration lohnt; über 30 % Dynamik → bei Next.js bleiben.

Drei Fragen zur Entscheidung

Q1: Wie oft aktualisieren Sie Content?

• täglich/wöchentlich → Next.js (ISR)
• selten → Astro (Performance)

Q2: Wie viel Interaktion?

• Suche/Kommentare → Astro (Islands)
• viel User-Interaktion → Next.js

Q3: Team-Stack?

• multi-framework / HTML → Astro
• React-first → Next.js

Damit sollte die Wahl klarer sein.

Praxisempfehlungen – Einstieg und Deployment

Theorie reicht – hier kommt die Umsetzung. Unabhängig vom Framework hilft dieser Teil beim schnellen Start.

Quick Start: Hello World in 10 Minuten

Astro Quick Start:

# Projekt erstellen
npm create astro@latest my-blog

# Template wählen (Blog oder Empty)
cd my-blog
npm install
npm run dev

http://localhost:4321 – src/pages/index.astro bearbeiten, sofort sichtbar.

Next.js Quick Start:

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

# Projekt erstellen
npx create-next-app@latest my-blog

# TypeScript, App Router, Tailwind …
cd my-blog
npm run dev

http://localhost:3000, app/page.tsx editieren.

Beide starten schnell; Astros Templates sind blog-näher, Next.js eher app-orientiert.

Empfohlene Starter

Astro:

• Astro Blog
• AstroPaper
• Starlight

Next.js:

• Next.js Blog Starter
• Nextra
• Contentlayer Blog

Persönlicher Favorit für Blogs: AstroPaper.

Deployment im Vergleich

Vercel:

• Astro: Zero-Config, npm run build
• Next.js: native, Auto-Optimierung
• schnell international, in China etwas langsamer; Free-Tier ~100 GB/Monat

Netlify:

• beide einfach; großzügigere Free-Tier, Functions
• Builds oft etwas langsamer als Vercel

Cloudflare Pages:

• beide unterstützt, schnelle Deploys
• globales CDN, unbegrenzte Bandbreite (Free)
• Build-Umgebung gelegentlich instabil

GitHub Pages:

• Astro: straightforward
• Next.js: output: 'export', Einschränkungen
• kostenlos, in China oft langsam, kein Server Components

Optimierung für Nutzer in China

1. CDN: Cloudflare Pages oft schneller als Vercel
2. Fonts: lokal oder china-taugliche CDN statt Google Fonts
3. Kommentare: Giscus statt Disqus
4. Bilder: OSS/COS statt Imgur

Mein Blog läuft auf Cloudflare Pages – in China solide.

Grenzen und Workarounds

Astro:

• ❌ weniger für Dashboards/SaaS mit viel Interaktion
• ❌ Echtzeit-Updates schwächer als Next.js
• ✅ Statik in Astro, Dynamik als separater Service

Next.js:

• ❌ für simple Blogs oft Overkill
• ❌ steiler App-Router
• ✅ bei reiner Statik Astro erwägen

Performance-Checklist (allgemein):

• ☑ WebP, Lazy Loading
• ☑ font-display: swap
• ☑ Third-Party-Skripte verzögert
• ☑ HTTP/2, Brotli
• ☑ sinnvolle Cache-Control-Header

Lernressourcen

Astro:

• Offizielle Docs
• Astro Blog Tutorial
• Starlight

Next.js:

• Offizielle Docs
• Next.js Learn
• App Router Migration

Fazit

Astro vs Next.js – kein absolutes „besser“. Entscheidend ist Ihr Szenario:

Meine Empfehlung:

• Persönlicher Blog, Tech-Docs: Astro
• Unternehmensseite, Landing: Astro – Performance als Vorteil
• CMS: seltene Updates → Astro; häufig → Next.js
• E-Commerce, komplexe Apps: Next.js
• Team deep in React: Next.js

Ich nutze Astro, weil ~95 % meines Blogs statisch ist, Lighthouse-Spaß und besseres Markdown-Schreiben.

Für SaaS mit Demo und Dashboard würde ich wieder Next.js wählen.

Jetzt testen:

# Astro
npm create astro@latest test-astro
cd test-astro && npm install && npm run dev

# Next.js
npx create-next-app@latest test-nextjs
cd test-nextjs && npm run dev

Lighthouse in Chrome DevTools – Zahlen überzeugen mehr als Vergleichsartikel.

Abschließend: Framework ist Werkzeug, Content zählt. Ob Astro oder Next.js – anfangen schreiben ist wichtiger als endlos vergleichen.

Fragen gerne in den Kommentaren – viel Erfolg beim Aufsetzen!