Als wir uns daran machten, die Website von Basi Software neu zu gestalten, lag die Wahl ganz klar bei Next.js. Wir setzen es ständig bei Kundenprojekten ein. Das Team kennt es in- und auswendig.
Wir haben uns stattdessen für Astro entschieden. Hier sind die Gründe dafür – und was wir dabei gelernt haben.
Die SPA-Steuer
Single-Page-Anwendungen haben die Last der Darstellung vom Server auf den Client verlagert. Für hochgradig interaktive Anwendungen – Dashboards, Editoren, Tools für die Zusammenarbeit – ist das der richtige Kompromiss. Für eine Marketing-Website mit einem Kontaktformular ist es jedoch eine Belastung.
Die „SPA-Steuer“ wird wie folgt ausgewiesen:
- JavaScript, das für Interaktionen bereitgestellt wird, die niemals stattfinden — Der Nutzer liest den Hero-Bereich, scrollt weiter und verlässt die Seite. Er hat den Auslöser für das Modal-Fenster nie angeklickt. Aber du hast das Modal-JS trotzdem ausgeliefert.
- Wasserfälle zur Flüssigkeitszufuhr — React rehydriert den gesamten Baum, bevor Interaktionen möglich sind
- Layoutverschiebung — Server-gerendertes HTML wird durch clientseitig gerendertes HTML ersetzt, was zu CLS führt
# Lighthouse on our old Next.js site (production build)
Performance: 71
First Contentful Paint: 1.8s
Total Blocking Time: 340ms
JavaScript bundle: ~280kb (gzipped)
# After migrating to Astro
Performance: 98
First Contentful Paint: 0.6s
Total Blocking Time: 0ms
JavaScript bundle: ~6kb (only the Nav and ContactForm islands)Was Astros Inselarchitektur eigentlich bedeutet
Der Begriff „Inseln“ wurde von Katie Sylor-Miller von Etsy geprägt. Die Idee dahinter: Eine ansonsten statische Seite enthält isolierte „Inseln“ der Interaktivität. Jede Insel wird unabhängig geladen. Alles andere wird als HTML ohne JavaScript ausgeliefert.
---
// Layout.astro — the shell is pure HTML
import Nav from '../components/Nav.astro'; // Static shell + small script
import ContactForm from './ContactForm'; // React island
import HeroSection from './HeroSection.astro'; // Zero JS — static HTML
---
<body>
<!-- Astro component — no framework runtime required -->
<Nav />
<main>
<!-- Static Astro component — ships as HTML, zero runtime cost -->
<HeroSection />
</main>
</body>Das Kontaktformular ist hier die einzige Framework-Insel. Die Navigation behält ihr interaktives Verhalten dank eines kleinen Browserskripts bei, sodass React nicht auf jeder Seite geladen wird.
Wichtige Richtlinien
Astro stellt fünf Richtlinien zur Flüssigkeitszufuhr vor. Die Wahl der richtigen Richtlinie hat messbare Auswirkungen:
| Richtlinie | Wann es Feuchtigkeit spendet | Verwendung für |
|---|---|---|
client:load | Sofort | Navigation, interaktiv im oberen Bereich |
client:idle | Wenn der Browser inaktiv ist | Komponenten unterhalb der Falz |
client:visible | Wenn ein Element in den Sichtbereich gelangt | Lazy-Komponenten |
client:media | Wenn die Medienabfrage zutrifft | Widgets nur für Mobilgeräte |
client:only | Nur clientseitig, kein SSR | Browser-API-abhängige Komponenten |
Für die meisten Marketing-Websites, client:visible ist die richtige Standardeinstellung für alles, was unterhalb der Falz liegt.
Übergänge ohne Framework anzeigen
Einer der Gründe, warum Teams sich für Next.js entscheiden, ist der integrierte Router mit Seitenübergängen. Auch Astro verfügt darüber, und zwar über den <ClientRouter /> Komponente und die View-Transitions-API.
---
import { ClientRouter } from 'astro:transitions';
---
<head>
<ClientRouter />
</head>/* Custom transition — runs on every page navigation */
::view-transition-old(root) {
animation: fade-out 0.3s ease-in forwards;
}
::view-transition-new(root) {
animation: slide-up 0.4s cubic-bezier(0.22, 1, 0.36, 1) forwards;
}Die transition:persist Das Attribut „nav“ sorgt dafür, dass die Navigation zwischen den Seiten nicht neu geladen wird – die React-Insel bleibt aktiv und behält dabei die Scrollposition sowie den geöffnete bzw. geschlossene Zustand bei.
Inhaltssammlungen für typsichere Inhalte
Dieser Blog selbst basiert auf Astro Content Collections – einer von Zod validierten, TypeScript-orientierten Content-Schicht:
// src/content/config.ts
import { defineCollection, z } from 'astro:content';
const blog = defineCollection({
type: 'content',
schema: z.object({
title: z.string(),
description: z.string(),
pubDate: z.coerce.date(),
category: z.string(),
tags: z.array(z.string()).default([]),
}),
});
export const collections = { blog };Jede MDX-Datei in src/content/blog/ ist nun vollständig typisiert. Fehlt in einem Beitrag ein Pflichtfeld, schlägt der Build fehl – es handelt sich nicht um einen Laufzeitfehler in der Produktion.
Wann sollte man sich dennoch für Next.js entscheiden?
Astro ist nicht die Antwort auf alles:
- Äußerst interaktive Apps — Wenn der Großteil der Seite reaktiv sein muss, setze React ein. Eine Astro-Website mit
client:loadBei jeder Komponente ist es schlechter als bei Next.js. - Echtzeitfunktionen — Live-Dashboards, gemeinsame Bearbeitung und WebSocket-intensive Benutzeroberflächen gehören in eine echte SPA
- Große authentifizierte Apps — Authentifizierungsabläufe, dynamisches Routing auf Basis von Benutzerdaten, komplexer clientseitiger Status — Hier hat Next.js die Nase vorn
Die Faustregel: Wenn die meisten Ihrer Seiten in erster Linie lesen anstatt mit … interagiert, Astro ist der bessere Ausgangspunkt.
Fazit
Die Rückkehr zur mehrseitigen Architektur ist kein Rückschritt. Es ist vielmehr die Erkenntnis, dass das ursprüngliche Modell des Webs – durch Hyperlinks verknüpfte Dokumente – nach wie vor die leistungsfähigste, barrierefreieste und robusteste Architektur für Websites ist, bei denen der Inhalt im Vordergrund steht.
Astro macht es einfach angenehm, im Jahr 2026 auf diese Weise zu bauen.
Comments
Loading comments…