Astro für content-getriebene SaaS-Marketing-Seiten: Wann es Next.js schlägt

Die meisten SaaS-Unternehmen betreiben zwei verschiedene Websites unter einer Marke: das Produkt, in das sich Leute einloggen, und die Marketing-Seite, die sie zur Anmeldung bringt. Das Produkt ist meist React, oft Next.js. Die Marketing-Seite landet meist ebenfalls auf Next.js, vor allem weil das Team dort ohnehin zu Hause ist. Die Frage Astro vs Next.js ist in Wahrheit eine Frage nach diesem Standard: Ist für Landing Pages, einen Blog und Docs ein Application-Framework noch das richtige Werkzeug? Oft nicht. Astro wurde genau für diesen Workload gebaut. Es gibt allerdings auch ein verbreitetes Setup, bei dem Next.js klar die bessere Wahl bleibt, also lohnt es sich, die Entscheidung sauber durchzugehen, statt sie aus Gewohnheit zu treffen.

Was Astro anders macht

Astro geht von der Annahme aus, dass eine Content-Seite HTML sein sollte. Seiten werden zur Build-Zeit oder auf dem Server zu statischem Markup gerendert, und JavaScript wird nur für Komponenten ausgeliefert, die du explizit als interaktiv markierst. Diese Komponenten werden zu Islands: kleine, isolierte Widgets, die unabhängig voneinander hydrieren. Eine Pricing-Seite mit einem Währungsumschalter liefert den Code für den Umschalter und sonst nichts. Ein Blogbeitrag ohne Interaktivität liefert überhaupt kein JavaScript.

Next.js nähert sich derselben Seite aus der anderen Richtung. Es ist ein Application-Framework, und selbst mit React Server Components im App Router lädt jede Seite die React-Runtime und den Client-Router, damit der Baum auf dem Client hydrieren und navigieren kann. Je nach Setup sind das grob 80 bis 100 KB gzipptes JavaScript, bevor dein eigener Code überhaupt läuft, auf jeder Seite, auch auf denen, die nur aus Text und Bildern bestehen.

Für ein Dashboard verdient sich die Runtime ihren Platz. Für einen Artikel, den ein Interessent einmal im Zug liest, ist sie Overhead, den der Besucher bezahlt und nie nutzt.

Astro vs Next.js: Wo Astro bei Marketing-Seiten gewinnt

Das Performance-Argument ist das lauteste, und es stimmt größtenteils. Ein schlichter Astro-Build landet bei mobilen Lighthouse-Scores in den hohen 90ern, ohne jedes Tuning. Eine Next.js-Seite bekommst du auf ähnliche Werte, wir haben das gemacht, aber du kommst dorthin durch Arbeit: Client-Komponenten auditieren, Abhängigkeiten stutzen, Bildladeverhalten bändigen und nach jedem Feature nachprüfen. Unser Leitfaden zu Next.js Performance-Optimierung beschreibt diesen Workflow im Detail, und die ehrliche Zusammenfassung lautet: Es ist ein Workflow. Astro liefert dir ein ähnliches Ergebnis als Ausgangszustand.

Der leisere Vorteil ist der Content-Workflow. Mit Astros Content Collections definierst du ein Schema für dein Frontmatter, validierst jede Datei zur Build-Zeit und fragst Beiträge über eine typisierte API ab. Kaputte Datumsangaben und fehlende Felder lassen den Build fehlschlagen, statt ausgeliefert zu werden. In Next.js wird die Unterstützung für Markdown und MDX von Hand aus Paketen und Glue-Code zusammengesetzt, und das Community-Tooling, das diese Lücke gefüllt hat, hatte eine holprige Wartungsgeschichte. Ein Team, das vier Beiträge im Monat veröffentlicht, spürt diesen Unterschied jede Woche.

Die Bundle-Größe folgt aus der Architektur, also braucht sie kaum ein eigenes Argument. Weniger ausgeliefertes JavaScript heißt auch weniger Hydration-Mismatches, weniger Fehlerberichte von uralten Android-Browsern und weniger Code, den du aktuell halten musst.

Viele Teams übersehen außerdem, dass die Wahl von Astro nicht bedeutet, React zu verlassen. Islands können React-Komponenten sein, also lässt sich ein bestehendes Design-System übernehmen. Du schreibst das Seitengerüst in Astro-Templates und mountest dein Signup-Formular oder deinen interaktiven Rechner als React-Island dort, wo er hingehört.

Ein kurzer Vergleich speziell für den Fall Marketing-Seite:

	Astro	Next.js
JavaScript auf einer reinen Content-Seite	Standardmäßig keins	React-Runtime plus Router auf jeder Seite
Lighthouse-Scores	Hoch ohne Aufwand	Hoch mit laufendem Aufwand
Markdown und MDX	Eingebaut, schema-validiert	Manuelles Setup
Geteilter Login-Zustand mit deiner App	Möglich, aber umständlich	Nativ
Team-Overhead	Zweites Framework zu pflegen	Ein Framework überall

Wo Next.js weiterhin die richtige Wahl ist

Das stärkste Argument für Next.js hat nichts mit Rendering-Geschwindigkeit zu tun. Es ist die geteilte Session.

Wenn deine Marketing-Seiten und deine Anwendung auf einer Domain leben und sich die Navbar ändert, sobald jemand eingeloggt ist, wenn Pricing-Seiten personalisierte CTAs zeigen, wenn du Experimente über dasselbe Feature-Flag-System fährst wie das Produkt, dann ist deine Marketing-Seite eine Erweiterung des Produkts und keine separate Seite. Sie in derselben Next.js-App zu behalten bedeutet, dass Komponenten, Auth und Analytics ohne Umstände funktionieren.

Du kannst das in Astro nachbauen. Server Islands können personalisierte Fragmente rendern, und Cookies lassen sich über Subdomains hinweg lesen. Aber jede dieser Brücken ist Code, den du über eine Framework-Grenze hinweg schreibst und pflegst, und die Komplexität landet genau dort, wo Astro die Dinge eigentlich einfacher machen sollte. Wenn wir ein solches Setup in einem Tech-Stack-Strategie-Projekt prüfen, ist unser Rat meist unverblümt: Eine eingeloggte Navbar ist ein Zeichen, dass du bleiben solltest, wo du bist.

Der zweite Grund ist Teamkapazität. Astro ist eine zweite Toolchain, mit einer zweiten Konfiguration zum Verstehen und einem zweiten Upgrade-Zyklus zum Einplanen. Ein Fünfpersonenteam, das Produktfeatures mit Next.js ausliefert, fährt womöglich besser mit einem langsameren Blog als mit geteilter Aufmerksamkeit über zwei Frameworks. Framework-Wildwuchs hat Kosten, auch wenn jedes Framework für sich exzellent ist, ein Thema, das wir auch in unserem Vergleich von React-Frameworks behandeln.

Was eine Migration kostet

Für Teams, die zum Astro-Profil passen, ist die Migration kleiner als die meisten erwarten, denn Marketing-Seiten bestehen vor allem aus Content, und Content lässt sich gut portieren.

Umfang	Typischer Aufwand
Landing Pages plus Blog, bis etwa 50 Seiten	1 bis 2 Wochen
Mehrsprachige Seite mit Docs, 100 bis 300 Seiten	3 bis 5 Wochen
Marketing-Seiten, die mit der Produkt-App verflochten sind	Oft nicht wert, sie herauszulösen; nur wirklich statische Seiten ausgliedern

Markdown- und MDX-Inhalte ziehen meist mit leichten Frontmatter-Anpassungen um. React-Komponenten lassen sich als Islands wiederverwenden statt neu schreiben. Die Zeit fließt in die unglamourösen Ränder: Redirect-Regeln, die in der Middleware lebten, internationalisiertes Routing, Open-Graph-Bildgenerierung, Consent- und Analytics-Skripte und Formular-Endpunkte. Plane den Großteil deines Zeitbudgets dafür ein, nicht für Seiten.

Plane die SEO-Mechanik so, wie du es bei jedem Plattformwechsel tun würdest. Halte URLs stabil, wo es geht, lege 301-Redirects an, wo nicht, und vergleiche die Sitemap vorher und nachher. Sorgfältig gemacht, sollten die Rankings den Wechsel nicht bemerken, und die Verbesserungen bei den Core Web Vitals können ihnen in den Folgemonaten helfen.

Das Performance-Delta, das du erwarten kannst

Typische Ergebnisse, mit dem Vorbehalt, dass jede Seite von einer anderen Basis startet. Auf Content-Seiten fällt das ausgelieferte JavaScript von irgendwo zwischen 90 und 250 KB gzippt auf nahe null, weil nur die Islands übrig bleiben. Mobiles LCP verbessert sich üblicherweise um mehrere hundert Millisekunden, sobald render-blockierende Skripte verschwinden, mehr, wenn die alte Seite große Komponentenbäume hydriert hat. Interaktionsmetriken wie INP verbessern sich, weil kaum noch JavaScript den Main Thread belegt. Mobile Lighthouse-Scores, die in den 60ern oder 70ern lagen, landen tendenziell in den 90ern.

Zwei ehrliche Einschränkungen gehören neben diese Zahlen. Wenn deine Next.js-Marketing-Seite mobil bereits über 95 liegt, bringt dir Astro wenig, das Besucher spüren, und die Migration lässt sich allein über Performance kaum rechtfertigen. Und Core Web Vitals sind ein Ranking-Faktor unter vielen, also retten schnellere Seiten keinen dünnen Content. Die Gewinne sind real, aber sie verstärken guten Content, statt ihn zu ersetzen.

Wie du entscheidest

Wähle Astro, wenn die Marketing-Seite content-lastig ist, keinen Login-Zustand hat, getrennt vom Produkt deployt wird und das Team ein weiteres Werkzeug verkraften kann. Bleib bei Next.js, wenn Marketing und Produkt eine Session oder eine Domain teilen, wenn Personalisierung den Funnel antreibt oder wenn das Team zu klein ist, um seine Aufmerksamkeit zu teilen. Wenn du einen Stack für ein neues Projekt wählst, statt eine Migration abzuwägen, behandelt unser Leitfaden zur Wahl eines Next.js-Framework-Setups diese benachbarte Entscheidung.

Das Muster, das wir in der Praxis am häufigsten sehen, ist ein Hybrid. Das Produkt bleibt auf Next.js, Marketing-Seite und Blog ziehen auf Astro mit eigenem Deploy, und beide teilen sich eine Komponentenbibliothek. Jedes Werkzeug macht den Job, für den es gebaut wurde, was als Ideologie weniger befriedigend ist und im Lighthouse-Bericht umso mehr.

FAQ

Kann ich meine bestehenden React-Komponenten in Astro nutzen?

Ja. Astro rendert React-, Vue-, Svelte- und Solid-Komponenten als Islands. Die meisten Teams übernehmen ihr Design-System direkt und schreiben nur Komponenten neu, die mit Anwendungszustand verflochten waren.

Funktioniert Astro mit einem Headless CMS?

Ja. Der mit Astro 5 eingeführte Content Layer lädt Einträge aus APIs und CMS-Backends über dieselben typisierten Collections, die auch für lokale Markdown-Dateien genutzt werden, sodass Redakteure ihren bestehenden Workflow behalten.

Eignet sich Astro für die Anwendung selbst?

Meist nicht. Sobald die meisten Seiten hinter einem Login liegen und Zustand tragen, baust du eine Anwendung, und ein Application-Framework wie Next.js passt besser. Astros Stärke ist der Content-Rand um das Produkt herum.

Wo Wolf-Tech ins Spiel kommt

Wir helfen SaaS-Teams, Framework-Entscheidungen wie diese mit Messungen statt mit Überzeugungsarbeit zu treffen, als Teil unserer Arbeit in der Webanwendungsentwicklung. Manchmal heißt das ein Migrationsplan mit Redirect-Map und Zweiwochenplan. Genauso oft heißt es, einem Team zu sagen, dass sein aktuelles Setup in Ordnung ist und der Nachmittag anderswo besser investiert wäre.

Wenn du Astro vs Next.js für deine Marketing-Seite abwägst, schreib uns an hello@wolf-tech.io oder besuche wolf-tech.io. Wir schauen uns an, was du hast, und geben dir eine klare Antwort.