Astro als Website-Framework, warum wir von React-SPA umgestiegen sind

Drei Stationen

rypox.de lief von 2021 bis 2024 auf WordPress. Funktional reichte das, doch der Betrieb sammelte mit der Zeit eine Reihe von Reibungspunkten. Für SEO, Backend-Verwaltung, Kontaktformular und etliche Detailfunktionen waren kostenpflichtige Plugins nötig, die jeweils ihre eigenen Updates und Sicherheitspatches verlangten. Themes ließen unser gewünschtes Design nur über Page-Builder-Wildwuchs und PHP-Eingriffe zu. Die ausgelieferte Performance war unbefriedigend. Redaktionelle Funktionen wie WYSIWYG-Editor und Mehrautor-Workflow, der eigentliche Daseinszweck von WordPress, brauchten wir gar nicht. Inhalte lebten zudem in einer MySQL-Datenbank statt in einem Git-Repository, ohne Diff, ohne Pull Request, ohne Review. Was den Ausweg schließlich attraktiv machte: KI-gestützte Codegenerierung ermöglichte es, SEO-Funktionen und Kontaktformular ohne Plugin-Abhängigkeit passgenau selbst zu schreiben.

2024 stiegen wir auf eine React Single-Page-Application um. Ausschlaggebend waren zwei Punkte: Die interaktive WebGL-Visualisierung (TechSphere) auf der Startseite ließ sich nicht aus rein statischem HTML zusammensetzen, und mit dem internen Projekt poc-ai-website lag bereits eine funktionierende React-Codebase vor, die als Basis dienen konnte. Das löste das WebGL-Problem, brachte aber gleich das nächste mit, weil die restliche, primär statische Site ebenfalls als SPA gerendert wurde.

Das Problem mit der React-SPA

Die zweite Version von rypox.de war damit eine React Single-Page Application. Technisch funktional, aber mit Problemen, die sich mit der Zeit nicht verbesserten, sondern verschärften:

SEO war mangelhaft, Suchmaschinen-Crawler hatten Schwierigkeiten mit Client-Side Rendering. Trotz Workarounds wie react-helmet und Pre-Rendering blieben die Ergebnisse unbefriedigend
Initial Load war langsam, Das JavaScript-Bundle umfasste über 400 KB (gzipped). Für eine primär statische Website mit Blog und Unternehmensseiten war das unverhältnismäßig
Lighthouse-Scores waren mittelmäßig, Performance um 60-70, LCP über 3 Sekunden auf mobilen Geräten
Hydration-Overhead, React musste die gesamte Seite im Browser “hydrieren”, obwohl 90% des Inhalts statisch war

Die Entscheidung fiel: Wir brauchen ein Framework, das statische Inhalte als statisches HTML ausliefert und JavaScript nur dort einsetzt, wo es tatsächlich benötigt wird.

Warum Astro

Astro verfolgt einen radikal anderen Ansatz als React, Next.js oder Gatsby: Zero JavaScript by Default. Jede Seite wird zur Build-Zeit als statisches HTML gerendert. JavaScript wird nur explizit und gezielt eingebunden, als sogenannte „Islands” (Astro-Doku zu Islands).

Core Principles

Prinzip	Beschreibung
Zero JS by Default	Kein JavaScript im Browser, solange nicht explizit angefordert
Islands Architecture	Interaktive Komponenten als isolierte „Inseln” in statischem HTML
UI-agnostisch	Offizielle Integrationen für React, Preact, Vue, Svelte und Solid, weitere Frameworks über Community-Pakete
Content First	Optimiert für content-lastige Websites: Blogs, Docs, Marketing
Edge-Ready	Static Output oder Server-Side Rendering, deploybar auf jeder Plattform

Die aktuellen Messwerte

Die folgenden Zahlen stammen aus einem Lighthouse-Lauf gegen https://rypox.de/ mit Lighthouse 13.0.1, Throttling-Modus „simulate”, aufgezeichnet am 2026-04-12. Permalinks zum aktuellen PageSpeed-Bericht: mobil und desktop.

Vorher-Werte der alten React-SPA liegen nicht in vergleichbarer Qualität vor, eine ehrliche Gegenüberstellung wäre Pseudo-Präzision. Wir zeigen deshalb nur die aktuellen Astro-Werte, getrennt nach Mobile und Desktop.

Lighthouse-Kategorien (Startseite)

Kategorie	Mobile	Desktop
Performance	92	100
Accessibility	100	100
Best Practices	100	100
SEO	100	100

Core Web Vitals und Performance-Metriken

Metrik	Mobile	Desktop
First Contentful Paint	1,3 s	0,3 s
Largest Contentful Paint	2,3 s	0,7 s
Total Blocking Time	280 ms	0 ms
Cumulative Layout Shift	0	0
Speed Index	1,3 s	0,5 s
Time to Interactive	2,5 s	0,8 s
Server-Antwortzeit (TTFB)	10 ms	10 ms
Build-Zeit (lokal)	~3 s	~3 s

Übertragene Bytes (Transfer)

Ressourcentyp	Mobile	Desktop
Dokument	11 KB	11 KB
Skripte	232 KB	232 KB
Schriften	49 KB	49 KB
Bilder	81 KB	127 KB
Sonstiges	1 KB	1 KB
Gesamt	373 KB	419 KB

Was die Zahlen sagen

Die Spreizung zwischen Desktop (100) und Mobile (92) kommt aus genau einem Faktor: Total Blocking Time 280 ms auf Mobile gegen 0 ms auf Desktop. Lighthouse drosselt für Mobile die CPU um Faktor 4, und damit fällt die React Three Fiber-Initialisierung der TechSphere-Insel ins Gewicht. Auf Desktop ist sie unsichtbar.

Auch die 232 KB JavaScript-Transfer sind fast vollständig dieser Insel zuzuschreiben: ein einzelnes Chunk client.*.js bringt 186 KB davon mit. Auf einer reinen Content-Seite ohne TechSphere ist die JS-Last entsprechend deutlich niedriger. „Zero JS by Default” gilt für Astro als Framework — die konkrete Seite zahlt nur das, was sie selbst an Inseln einbettet.

CLS bei 0 und TTFB bei 10 ms sind die unspektakulären, aber wichtigen Werte. Statisches HTML hinter Nginx hat keinen Layout-Shift und kein Server-Bottleneck.

Hinweis zur Variance bei PageSpeed Insights

Wer den Permalink aufruft, sieht eventuell andere Werte als hier in der Tabelle. Single-Run-Lighthouse-Werte schwanken auf pagespeed.web.dev typischerweise um zehn oder mehr Punkte, weil dort auf geteilter Infrastruktur gemessen wird und Mobile zusätzlich CPU-gedrosselt ist. Belastbar wird das Bild erst mit mehreren Läufen (lighthouse --runs=5 lokal) oder mit den CrUX-Felddaten, die Google über 28 Tage aggregiert.

Content Collections für den Blog

Astros Content Collections sind der Grund, warum die Blog-Pflege hier reibungslos läuft. Markdown-Dateien mit Frontmatter werden typsicher verwaltet, inklusive Schema-Validierung:

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

const blogCollection = defineCollection({
  type: 'content',
  schema: z.object({
    title: z.string(),
    description: z.string(),
    date: z.date(),
    author: z.string(),
    tags: z.array(z.string()),
    image: z.string().optional(),
  }),
});

export const collections = {
  blog: blogCollection,
};

Jeder Blogartikel wird beim Build gegen dieses Schema validiert. Ein fehlender Titel oder ein falsches Datumsformat führt zu einem Build-Fehler, nicht zu einer kaputten Seite in Produktion.

Querying

---
// src/pages/blog/index.astro
import { getCollection } from 'astro:content';

const posts = (await getCollection('blog'))
  .sort((a, b) => b.data.date.valueOf() - a.data.date.valueOf());
---

<ul>
  {posts.map(post => (
    <li>
      <a href={`/blog/${post.slug}/`}>
        <h2>{post.data.title}</h2>
        <time>{post.data.date.toLocaleDateString('de-DE')}</time>
      </a>
    </li>
  ))}
</ul>

Kein GraphQL, kein CMS-API-Call, keine Laufzeit-Datenbank. Markdown-Dateien im Repository, typsicher gequeried zur Build-Zeit.

Islands Architecture, React als Insel

Nicht alles auf rypox.de ist statisch. Die TechSphere-Visualisierung auf der Startseite ist eine WebGL-Komponente, gebaut mit React Three Fiber. In Astro wird sie als Island eingebunden:

---
import TechSphere from '../components/TechSphere';
---

<section class="hero">
  <h1>Softwarearchitektur für den Finanzsektor</h1>
  <TechSphere client:visible />
</section>

client:visible bedeutet: Die React-Komponente wird erst geladen und hydriert, wenn sie in den Viewport scrollt. Vorher wird kein Byte JavaScript für diese Komponente übertragen.

Hydration-Strategien

Astro bietet mehrere client:*-Direktiven, die festlegen, wann eine Insel hydratisiert wird:

Directive	Verhalten	Use Case
`client:load`	Sofort beim Seitenaufruf	Kritische interaktive Elemente
`client:idle`	Nach dem Laden, wenn Browser idle	Nicht-kritische Interaktivität
`client:visible`	Wenn Komponente in Viewport scrollt	Below-the-fold Inhalte
`client:media`	Wenn Media Query zutrifft	Responsive Interaktivität
`client:only`	Nur Client-Side, kein SSR	Reine Client-Komponenten (z.B. WebGL)

Für die TechSphere verwenden wir client:visible, weil die 3D-Visualisierung auf der Startseite erst relevant wird, wenn der Nutzer sie sieht. Das spart bei Mobile-Nutzern, die nicht bis zur Visualisierung scrollen, den kompletten Download des Three.js-Bundles. Dummerweise wird sie bei uns gleich am Anfang der Seite eingesetzt. Im konkreten Fall wird sie also doch sofort geladen, aber in der Theorie stimmt es.

Build Performance

Astro baut schnell. Die gesamte rypox.de Website, Blog, Unternehmensseiten, Komponenten, baut in unter 3 Sekunden. Das klingt trivial, hat aber praktische Auswirkungen:

Schnelles Feedback, Änderungen am Blog sind in Sekunden live in der Preview
CI/CD, Der Build-Schritt in der Pipeline ist vernachlässigbar
Content-Workflow, Autoren können Markdown-Dateien pushen und sehen das Ergebnis fast sofort

Vite als Build Tool

Astro nutzt Vite unter der Haube. Hot Module Replacement im Dev-Server ist quasi instantan. Das ist ein drastischer Unterschied zu Webpack-basierten React-Setups, wo nach jeder Änderung Sekunden vergehen.

llms.txt für KI-Discoverability

Ein Nebeneffekt der Migration, der sich als strategisch relevant herausgestellt hat: Astro macht es einfach, maschinenlesbare Metadaten bereitzustellen. Wir haben eine llms.txt-Datei implementiert, ein aufkommendes Format, das KI-Systemen strukturierte Informationen über eine Website bereitstellt.

# rypox GmbH
> Softwarearchitektur und Entwicklung für den Finanzsektor

## Kernkompetenzen
- Zahlungsverkehr (VoP, SEPA, ISO 20022)
- Clean Architecture und Domain-Driven Design
- Microservices mit Spring Boot und Kubernetes

## Blog
- /blog/verification-of-payee/
- /blog/kafka-echtzeit-transaktionen/
- /blog/java-21-virtual-threads/

In einer Welt, in der immer mehr Informationen über KI-Assistenten abgerufen werden, ist die maschinenlesbare Aufbereitung der eigenen Inhalte keine Spielerei, sondern vorausschauende Content-Strategie.

Deployment

Das Deployment ist denkbar einfach: Astro generiert statische HTML-Dateien, die auf jedem Webserver laufen. In unserem Fall deployen wir auf einen einfachen Nginx, kein Node.js-Server, kein CDN-Setup notwendig (auch wenn ein CDN natürlich sinnvoll ist).

npm run build    # Generiert dist/
# dist/ enthält reines HTML, CSS und minimales JS

Was wir vermissen

Fairness halber: Astro ist nicht perfekt für jeden Anwendungsfall.

Keine Client-Side Navigation, Jeder Seitenaufruf ist ein vollständiger Page Load. Für eine Content-Website akzeptabel, für eine Web-App nicht
Ökosystem kleiner als React/Next.js, Weniger Third-Party-Komponenten und Tutorials
View Transitions ersetzen keine SPA-Navigation vollständig, Astros View Transitions API ist seit Astro 3 stabil und liefert geschmeidige Übergänge, erreicht aber dort, wo komplexe State-Übergänge nötig sind, nicht ganz das Gefühl einer echten Client-Side-App

Für rypox.de, eine Unternehmenswebsite mit Blog und technischen Inhalten, überwiegen die Vorteile bei weitem.

Fazit

Die Migration von React-SPA zu Astro war eine der besten technischen Entscheidungen für rypox.de. Perfekte Lighthouse-Scores, minimales JavaScript, schnelle Builds und ein Content-Workflow, der auf Markdown und Git basiert. Astro löst genau das Problem, das wir hatten: Eine Website, die primär Inhalte ausliefert, braucht kein 400-KB-JavaScript-Framework. Sie braucht gutes HTML und gezieltes JavaScript dort, wo es tatsächlich Interaktion gibt.