Astro oder ein eigener Static-Site-Generator.

Beide erzeugen am Ende statisches HTML; der Unterschied liegt nicht in der Datei, sondern darin, welche Arbeit abgegeben wird — und was diese Abgabe kostet.

Beginnt der Vergleich mit „was ist besser“, bleibt er unbeantwortet, denn beide erzeugen dasselbe: vorab vorbereitetes HTML. Die nützliche Frage lautet: welche der zur Bauzeit anfallenden Arbeiten geben Sie an ein Framework ab, und wo bezahlen Sie diese Abgabe? Dieselbe Frage stellt sich eine Ebene höher: statische Website oder CMS.

Was das Framework übernimmt

Ein Static-Site-Framework bringt fertig mit, was sonst jedes Projekt neu schreibt: dateibasiertes Routing, Schemaprüfung der Inhaltsdateien, Bildableitungen, eine Sitemap, ein Komponentenmodell und eine Insel-Architektur, die JavaScript nur dort ausliefert, wo es gebraucht wird. Jedes davon ist für sich Tage an Arbeit, und alles ist dokumentiert. Die Kosten zeigen sich in zwei Posten: im installierten Abhängigkeitsbaum und im Releasekalender des Frameworks. Der zweite ist nicht abstrakt — bei der Vorbereitung dieses Vergleichs verweigerte die Framework-Version eines gemessenen Projekts den Start unter der Node-Version der Maschine und verlangte zuerst ein Umgebungs-Update.

Was ein eigener Generator gibt

Ein eigener Generator bedeutet, dass die gesamte Ausgabe in Ihrer Verantwortung liegt. Der Gewinn zeigt sich bei ungewöhnlichen Anforderungen: diese Website trägt auf jeder Seite eine Maschinenschicht, einen Schemagraphen in drei Sprachen, aus Messbüchern gespeiste Figuren und einen aus Inhaltsdateien abgeleiteten Linkgraphen — nichts davon wird per Plug-in ein- oder ausgeschaltet, alles steht im Generator. Die Kosten stehen im selben Satz: Sie schreiben es, Sie messen es, Sie pflegen es.

Zwei gemessene Zahlen und was sie nicht sagen

Gleiche Maschine, 22. September 2026: ein Astro-Projekt erzeugte 122 Seiten in 1,57 Sekunden, der Generator dieser Website 466 Seiten in 1,03. Das ist kein Wettrennen, sondern die Dauer zweier verschiedener Arbeitsbeschreibungen. Astro kompiliert Komponenten, verarbeitet Assets und erzeugt Bildableitungen; dieser Generator druckt HTML aus freigegebenem JSON, zeichnet Figuren in seiner eigenen Zeichensprache und überlässt Bildableitungen getrennten Werkzeugen. Richtig gelesen heißt das: beide bleiben weit unter der Zeit, die ein Mensch zu warten bereit ist — die Build-Geschwindigkeit entscheidet diese Wahl also nicht.

Wie man entscheidet

Wächst das Team, ist die Arbeit Standard und wird ein Wechsel der Hände erwartet, hält die Framework-Seite weniger Überraschungen bereit: die Dokumentation ist geteilt, die Muster sind bekannt, neue Mitarbeitende liefern am ersten Tag. Sind die Anforderungen ungewöhnlich, muss jedes Byte der Ausgabe prüfbar sein und ist das Team klein, bedeutet ein eigener Generator weniger Schichten — die Zeit auf der Suche nach Hintertüren kann länger sein als die Zeit für eigenen Code. Beide Wege sind legitim; falsch ist nur, ohne Messung zu entscheiden.

Kriterium

1. Start — Astro: Installation und Konfiguration dauern Minuten; Routing, Inhaltskollektionen, Bildverarbeitung und Sitemap sind fertig · Eigener Generator: Jedes Teil wird geschrieben: Routentabelle, Vorlagen, Sitemap, Feed, Mehrsprachigkeit
2. Abhängigkeiten (gemessen · 22.09.2026) — Astro: Zwei Laufzeit- und vier Entwicklungspakete; der installierte Baum liegt auf dieser Maschine bei 478 Megabyte · Eigener Generator: In diesem Repository keine Laufzeitabhängigkeit; ein `node_modules`-Verzeichnis existiert nicht
3. Build (gleiche Maschine · 22.09.2026) — Astro: 122 Seiten in 1,57 Sekunden (warmer Bild-Cache) · Eigener Generator: 466 Seiten in 1,03 Sekunden (bester von drei Läufen: 1,03 · 1,03 · 1,13)
4. Laufzeit — Astro: Insel-Architektur: nur Komponenten mit Interaktion werden hydriert · Eigener Generator: Ausgeliefert wird, was geschrieben wurde; es gibt keine Standardlaufzeit
5. Versionen und Umgebung — Astro: Die Framework-Version treibt die Umgebung: in diesem Projekt verweigerte Astro 7 den Start unter Node 20 und verlangte 22.12 oder neuer · Eigener Generator: Kein Framework-Update; die Umgebungsanforderung bestimmt der eigene Code
6. Ökosystem — Astro: Integrationen, Themes, Dokumentation und Community · Eigener Generator: Keines — jeder Bedarf wird im eigenen Code gedeckt
7. Übergabe und Lernen — Astro: Weit verbreitet: neue Entwickler lernen aus der Dokumentation · Eigener Generator: Hausspezifisch: die Übergabe hängt an geschriebener Doku und lesbarem Code
8. Grenzen — Astro: Für Bedarf außerhalb des Frameworks sucht man eine Hintertür · Eigener Generator: Keine Grenzen — und keine geteilten Kosten
9. Wo es passt — Astro: Teams, Standardbedarf, schneller Start, Übergabefähigkeit · Eigener Generator: Einzelperson oder kleines Team, ungewöhnliche Anforderungen, über Jahre prüfbare Ausgabe

HÄUFIGE FRAGEN

Ist eine mit Astro gebaute Website langsamer?

Nein; beide liefern statisches HTML aus, und über die Laufzeitgeschwindigkeit entscheidet das Gewicht der Seite, nicht der Generator. Die Zahlen in diesem Vergleich stammen von der Build-Seite: am 22. September 2026 erzeugte auf derselben Maschine ein Astro-Projekt 122 Seiten in 1,57 Sekunden, der Generator dieser Website 466 Seiten in 1,03. Die beiden Zahlen messen nicht dieselbe Arbeit — Astro kompiliert Komponenten und verarbeitet Bilder, dieser Generator druckt HTML aus JSON und zeichnet seine Figuren selbst.

Wie lange dauert es, einen eigenen Generator zu schreiben?

Auf dieser Website entstand der Generator nicht in einem Zug, er wuchs mit der Website. Die eigentliche Frage lautet nicht „soll ich einen schreiben“, sondern „welche Arbeit gebe ich ab“: sollen Routing, Schema, Mehrsprachigkeit, Feeds und Bildverarbeitung fertig kommen, oder soll alles messbar und prüfbar sein?

Welches Risiko hat ein eigener Generator?

Zwei: die Übergabe und der Messaufwand. In einem Framework findet die Community Fehler, die Sie sonst selbst finden müssten. Die Antwort darauf lautet in diesem Repository: hinter jeder Entscheidung steht ein Tor — genau dafür gibt es die Prüfsuite.