TypeScript für Marketing-Sites: Wann es sich lohnt, wann nicht
TypeScript fügt Build-Komplexität hinzu. Für eine fünfseitige statische Site ist das Overhead. Für ein mehrsprachiges, CMS-gestütztes Projekt kann es Monate Debugging sparen.
Wir haben Astro für Marketing-Sites in unseren Standardstack aufgenommen. Das ist eine bedeutende Entscheidung für ein Studio, das primär Next.js verwendet. Hier ist die Begründung.
Astro rendert standardmäßig kein JavaScript an den Client. Das ist das zentrale Unterscheidungsmerkmal.
Next.js sendet eine JavaScript-Bundles an den Browser, auch für vollständig statische Seiten. Das ist die Grundlage von React — ein Komponentenbaum, der im Browser hydratisiert wird. Für interaktive Anwendungen ist das sinnvoll. Für eine Marketing-Site mit einer Kontaktformular ist es Overhead.
Astro verfolgt ein anderes Modell: Komponenten werden zur Build-Zeit zu reinem HTML gerendert. Kein JavaScript wird standardmäßig gesendet. Wenn Sie JavaScript brauchen (für ein interaktives Formular, ein Animations-Element, eine Suche), können Sie es granular hinzufügen — nur für die Komponente, die es braucht.
Das nennt sich „Islands Architecture".
Auf einer typischen Marketing-Site mit Astro:
LCP: 0,6–1,2s auf Mobil — deutlich besser als der Next.js Durchschnitt von 1,4–2,1s.
JavaScript-Bundle-Größe: 0–15 KB für rein statische Seiten, gegenüber 80–200 KB für eine minimal konfigurierte Next.js-Site.
Lighthouse-Score: 95–100 auf Mobil ohne spezifische Performance-Optimierungen.
Diese Verbesserungen sind nicht dramatisch für Rankings. Sie sind dramatisch für Nutzererfahrung auf Mobil-Verbindungen.
Primär Content-fokussierte Sites. Wenn 80 % der Seite statischer Content ist (Texte, Bilder, Videos), und nur 20 % interaktiv (Formular, Navigation, Animationen), ist Astro die bessere Wahl.
Blog-intensive Sites. Astro's Content Collections sind für Blog-Systeme optimiert. Markdown und MDX werden nativ unterstützt, mit stark typisierten Schemas.
Wenn der Kunde die Site selbst warten wird. Astro's Komponentenmodell ist einfacher für nicht-React-Entwickler. Kein React-spezifisches Wissen erforderlich.
Wenn Performance die primäre Anforderung ist. Für Kunden, die PageSpeed-Scores oder Core Web Vitals als explizite Anforderung haben.
SaaS-Dashboards. Hoch-interaktive Anwendungen brauchen React's Zustandsmanagement und komponentenbasiertes Rendering.
Blog + App unter einer Domain. Wenn Marketing-Site und App aus derselben Codebase stammen sollen.
Wenn das Team React-Expertise hat und Astro neu wäre. Lernkurve hat Kosten.
Wenn i18n-Routing-Komplexität hoch ist. Astro's i18n-Unterstützung ist gut, aber Next.js hat mehr Ökosystem und Muster für komplexe Lokalisierungen.
Astro unterstützt React-, Vue-, Svelte- und andere Framework-Komponenten innerhalb derselben Site. Das bedeutet: Wenn Sie eine React-Komponente brauchen (z.B. eine bestehende Bibliothek), können Sie sie verwenden — ohne die gesamte Site in React zu zwingen.
Das ist praktisch mächtig. Eine statische Landing Page mit einem einzigen interaktiven React-Widget sendet JavaScript nur für dieses Widget, nicht für die gesamte Seite.
Astro ist jünger. Das Ökosystem ist kleiner. Weniger fertige Bibliotheken, weniger StackOverflow-Antworten, weniger Entwickler, die es kennen.
Kein serverseitiges Rendering mit Zustandsmanagement. Wenn Sie Server-Side Auth, Session-Management oder dynamische personalisierten Inhalte brauchen, brauchen Sie entweder Server-Endpunkte (die Astro unterstützt) oder Next.js ist die einfachere Wahl.
Deployment. Vercel und Netlify unterstützen Astro vollständig. Aber das Ökosystem ist kleiner als Next.js auf Vercel.
Marketing-Site ohne Auth oder komplexes Routing → Astro. Marketing-Site + App in einer Codebase → Next.js. Reines Blog-System → Astro. SaaS-Dashboard → Next.js.
Die Antwort ist keine Religion. Es ist eine technische Entscheidung basierend auf dem, was das Projekt braucht.
Unsicher, welches Framework für Ihr Projekt richtig ist? Starten Sie ein Gespräch — wir erklären die Tradeoffs für Ihr spezifisches Projekt.
Wir nehmen jeden Quartal eine begrenzte Anzahl von Projekten an. Erzählen Sie uns, was Sie bauen.
TypeScript fügt Build-Komplexität hinzu. Für eine fünfseitige statische Site ist das Overhead. Für ein mehrsprachiges, CMS-gestütztes Projekt kann es Monate Debugging sparen.
Ihre Website fehlt bei Google aus zwei Gründen: zu neu oder blockiert. So erkennen Sie in zwei Minuten welcher – plus 10 Ursachen und Lösungen.