Warum Astro für B2B-Marketing-Sites

Weniger JS, schnellere Seiten, glücklichere Kunden. Dazu ein Build-Prozess, den man in fünf Jahren noch versteht.

Ich baue seit Jahren Kunden-Webseiten. Früher mit Gatsby, dann Next.js, zuletzt ein Abstecher zu SvelteKit. Für statische Marketing-Sites bin ich bei Astro in der aktuellen Stable-Version gelandet und bleibe dort. Kurz, warum.

Astro erzwingt kein Framework

Astro rendert .astro-Komponenten serverseitig zu HTML. React-Islands fügt man dort hinzu, wo Interaktivität wirklich nötig ist (Theme-Toggle, Formular-Validierung). Der Rest ist reines HTML + CSS im Browser. Das bedeutet: 0 kB JavaScript für die Hero-Sektion, für die Service-Karten und für den Footer.

Content Collections sind unterschätzt

Die Blog-Posts hier liegen als .mdx-Dateien unter src/content/blog/. Frontmatter ist zod-validiert. Es gibt kein CMS, keine Datenbank und keine Migrations. Für eine Einzel-Entwickler-Site ist das die richtige Menge Komplexität.

View Transitions sind eingebaut

Seitenwechsel laufen ohne Flash und ohne Layout-Shift. Der Header bleibt persistent, der Rest crossfadet. Das ist das Gefühl, das man früher nur mit einer schweren SPA bekommen hat. Jetzt genügt das <ClientRouter />-Tag.

Astro passt nicht überall

• Für hochdynamische Apps (Live-Chats, Realtime-Dashboards) ist Astro falsch. Da greife ich zu ASP.NET Core und Blazor auf aktueller .NET-LTS-Basis.
• MDX-Builds mit 100+ Posts werden merklich langsam. Dann lohnt sich das Caching via astro:content.

Für alles dazwischen ist Astro aktuell mein Default: Landing-Pages, Marketing-Sites, Content-lastige Projekte mit gelegentlicher Interaktion.