MenüSchließen

Von Angular zu Astro: Warum ich meine Website umgebaut habe

Warum ich meine eigene Website von Angular auf Astro umgebaut habe: kaum noch JavaScript, einfachere Pflege, verständlichere Texte. Mit echten Messwerten.

Von Ioan Serbanaktualisiert am 4 Min. Lesezeit

Bis zum Herbst 2026 lief diese Website auf Angular. Heute läuft sie auf Astro. Das war kein Wechsel aus Mode, sondern eine Korrektur: Ich hatte für eine Website voller Texte ein Werkzeug gewählt, das für Anwendungen gebaut ist.

In diesem Artikel steht, warum ich umgebaut habe, was sich geändert hat und was es gebracht hat. Die Zahlen habe ich an beiden Versionen am selben Tag gemessen.

Warum ich zuerst Angular gewählt habe

Angular ist das Framework, das ich am besten kenne. Ich wollte sehen, welche Geschwindigkeit sich mit einem Enterprise-Framework erreichen lässt. So nennt man Frameworks, die für große Firmenanwendungen gebaut sind.

Im PageSpeed-Test, den ich während der Entwicklung laufen ließ, kam die Seite auf 84 von 100 Punkten für Mobilgeräte und auf 100 für den Desktop. PageSpeed ist ein kostenloser Test von Google, der die Ladegeschwindigkeit einer Seite bewertet. Das war gut genug. Danach bin ich auf Astro gewechselt, ein leichteres Framework, das vor allem CSS und HTML ausliefert und nur wenig JavaScript.

Die Ausgangslage

Die alte Website lief auf Angular mit Server-Side-Rendering. Das heißt: Ein Server baut jede Seite fertig zusammen, bevor sie an den Browser geht. Gehostet war sie bei Railway, davor lag Cloudflare. Für Google war das in Ordnung, denn Suchmaschinen bekamen fertige Seiten zu lesen.

Das Problem lag woanders. Angular ist für Webanwendungen gemacht: Programme im Browser mit Login, Formularen und vielen Klicks. Meine Website besteht aber vor allem aus Texten: Leistungen, Preise, Projekte und Artikel. Für so eine Seite war der Aufbau zu schwer.

Was der alte Aufbau gekostet hat

  • Ein eigener Server, nur damit die Seiten entstehen konnten.
  • 476 KB JavaScript auf der Startseite, verteilt auf 15 Dateien. Der Browser muss das alles laden und ausführen.

Warum Astro

Astro erzeugt beim Veröffentlichen aus jeder Seite eine fertige HTML-Datei. Diese Dateien liefert Cloudflare direkt aus, ohne eigenen Server dahinter. JavaScript kommt nur dorthin, wo es wirklich gebraucht wird: auf der Startseite ist es ein kleines Skript für das Menü auf dem Handy.

Die Artikel sind jetzt einfache Textdateien im Markdown-Format, mit wenigen Zeichen für Überschriften und Links. Deutsch und Englisch liegen nebeneinander, jede Seite hat ihre englische Fassung unter derselben Adresse mit /en/ davor.

Nur das Kontaktformular braucht noch ein kleines Stück Code auf dem Server. Es nimmt die Anfrage entgegen und gibt sie an meinen Server bei Railway weiter. Der macht jetzt nur noch zwei Dinge: Kontaktanfragen und den KI-Chat.

Bei jedem Veröffentlichen läuft außerdem ein Prüfprogramm mit. Es prüft, ob alle alten Adressen noch erreichbar sind, ob irgendwo Code direkt in einer Seite steht und ob jede Seite ihre strukturierten Daten vollständig mitbringt. Das sind die Angaben im Code, aus denen Google zum Beispiel Leistungen, Preise und Adresse abliest.

Was es gebracht hat

Gemessen auf der Startseite, beide Versionen am 30. September 2026, nur Dateien der eigenen Domain:

  • JavaScript: vorher 476 KB in 15 Dateien, jetzt unter 1 KB in einer Datei.
  • HTML: vorher 107 KB, jetzt 57 KB.
  • CSS: vorher 23 KB, jetzt 59 KB. Das neue Design zeichnet mehr, deshalb ist das CSS gewachsen. Anders als JavaScript muss der Browser es aber nicht erst ausführen.
  • Lesbarkeit nach Flesch-Amstad: vorher 38, jetzt 60. Werte unter 50 gelten als schwer lesbar, Werte um 60 als gut verständlich.

Die Lesbarkeit hat mit der Technik nichts zu tun. Aufgefallen ist es mir zuerst nicht. Dann öffnete jemand aus meinem Freundeskreis die alte Website und verstand sie nicht. Ein Online-Test bestätigte es: Die Texte waren zu technisch. Deshalb habe ich beim Umbau jede Seite neu geschrieben.

Im PageSpeed-Test stieg der Wert für Mobilgeräte von 84 auf 94. Auf dem Desktop sank er von 100 auf 96. Das CSS ist groß, weil alle Zeichnungen auf dieser Website Code sind. Bei dieser Menge ist das Ergebnis gut. Ich würde mich an den Zahlen nicht aufhalten: Der Test läuft mit alten Handymodellen und einem langsamen 4G-Netz. Lädt Ihre Seite in unter 2,5 Sekunden, ist das in Ordnung.

Wie schnell die Seite bei echten Besuchern lädt, zeigen erst die Daten von Google nach einigen Wochen. Diese Werte ergänze ich hier, sobald sie vorliegen.

Der KI-Chat blieb, wie er war

Der Chat ist ein eigenes kleines Programm, gebaut mit Preact, einer schlanken Alternative zu React. Er läuft in einem abgeschotteten Rahmen (Sandbox-iFrame) auf einer eigenen Adresse, getrennt vom Rest der Seite. Im Hintergrund sucht ein RAG-System passende Inhalte heraus, bevor das Sprachmodell Gemini antwortet. So stützen sich die Antworten auf echte Inhalte.

Weil der Chat nicht an Angular hing, konnte ich ihn beim Umbau unverändert übernehmen. Genau dafür war die Trennung gedacht: Er lässt sich auf jede Website setzen, egal womit sie gebaut ist.

Was ich daraus mitnehme

  • Das Werkzeug richtet sich nach dem Inhalt. Angular kenne ich am besten. Für eine Website voller Texte war es nicht die beste Wahl.
  • Für echte Anwendungen bleibt ein Framework richtig. Bei Login, Kundenbereich oder vielen Eingaben ist Angular weiterhin ein gutes Werkzeug.
  • Keine Adresse ging verloren. Alle 60 alten Adressen führen weiter zur passenden Seite, entweder direkt oder über eine dauerhafte Weiterleitung.
  • Früh umbauen ist billiger. Je jünger eine Website ist, desto weniger hängt an ihr.

Welche Technik zu welcher Website passt, erkläre ich im Artikel WordPress oder individuelle Website. Für die meisten Betriebe reicht eine schlanke Unternehmenswebsite.