Von Nuxt 2 zu Astro: Relaunch unserer eigenen Website

Wer unsere Website heute besucht, sieht sie in der dritten Generation: neu aufgebaut mit Astro. Davor lief sie jahrelang als Nuxt-2-Frontend mit Strapi als Headless CMS dahinter. Dieser Artikel erzählt, warum wir umgezogen sind, wie der Umzug ablief — und was wir dabei über das richtige Werkzeug für Inhaltsseiten gelernt haben.

Die Ausgangslage: zwei Systeme für eine Inhaltsseite

Die alte Architektur war eine klassische Headless-Lösung: ein Nuxt-2-Frontend, das seine Inhalte zur Laufzeit aus Strapi holt. Das funktioniert — bringt aber dauerhafte Verpflichtungen mit:

• Zwei Systeme im Betrieb. Frontend-Server, Strapi und dessen Datenbank wollen deployt, überwacht und aktuell gehalten werden. Für ein CMS heißt das: Sicherheitsupdates, Admin-Zugänge, Backups.
• Inhalte außerhalb der Versionskontrolle. Texte lebten in der Strapi-Datenbank. Wer wann was geändert hat, war dort nachvollziehbar — aber getrennt vom Rest des Projekts, ohne Review-Prozess, ohne gemeinsame Historie mit dem Code.
• Ein Framework am Lebensende. Nuxt 2 hat sein End-of-Life erreicht. Die Migration auf Nuxt 3 wäre kein Update gewesen, sondern ein Rewrite — und damit der richtige Moment, die Architektur grundsätzlich zu hinterfragen.

Die ehrliche Frage dahinter: Braucht eine Unternehmensseite mit Blog überhaupt ein SPA-Framework und ein CMS? Unsere Antwort: nein. Es ist eine Inhaltsseite. Sie ändert sich, wenn wir sie ändern — nicht zur Laufzeit.

Warum Astro

Astro dreht das Modell um: Standardmäßig wird alles zu HTML gerendert, JavaScript landet nur dort im Browser, wo tatsächlich Interaktion stattfindet. Für eine Inhaltsseite ist das genau die richtige Voreinstellung.

Drei Dinge haben uns überzeugt:

Content Collections. Inhalte sind Dateien im Repo, beschrieben durch ein typisiertes Schema. Unser Blog ist eine Collection aus Markdown-Dateien mit geprüftem Frontmatter — fehlt ein Pflichtfeld oder stimmt ein Datum nicht, schlägt der Build fehl statt die Seite kaputt auszuliefern:

---
title: "Traefik - ein Reverse-Proxy für Docker"
author: "Sebastian Koch"
abstract: "…"
tags:
  - Softwareentwicklung
publishedAt: 2021-02-22
---

Redaktion im Git-Workflow. Ein neuer Artikel ist ein Merge Request: Markdown schreiben, Bilder daneben legen, Review, mergen. Versionierung, Vier-Augen-Prinzip und Deployment kommen aus dem Workflow, den wir ohnehin jeden Tag benutzen — ein eigenes Redaktionssystem mit eigener Rechteverwaltung ist dafür nicht mehr nötig.

JavaScript als bewusste Entscheidung. Unsere Seiten haben durchaus Bewegung — Scroll-Animationen, interaktive Elemente wie der Tech-Radar auf der Karriereseite. Aber das ist jeweils ein kleines, gezieltes Script. Eine Blog-Seite liefert heute fertiges HTML plus ein einziges Script-Bundle von rund 60 kB für die Animationen aus. Es gibt keinen Hydration-Schritt, der erst das halbe Framework laden muss, bevor die Seite benutzbar ist. Und alle Animationen sind so gebaut, dass die Seite auch ohne JavaScript vollständig lesbar bleibt.

Dazu kommt Bild-Optimierung im Build: Astro erzeugt aus den Quellbildern passende Größen und moderne Formate, ohne dass zur Laufzeit ein Bildservice laufen muss.

Der Umzug

Der eigentliche Umzug war unspektakulärer als befürchtet — und das ist das Kompliment an die Architektur:

1. Inhalte exportieren: Die Blog-Artikel wanderten aus Strapi in Markdown-Dateien, die Bilder in Ordner direkt neben den Artikeln. Einmalaufwand, danach nie wieder API-Aufrufe für Inhalte.
2. Seiten neu bauen: Die Seiten entstanden als Astro-Komponenten neu — mit Tailwind CSS und einem konsequenten Design-System statt mitgeschleppter Alt-Styles. Der Rewrite war ohnehin fällig; so wurde er zur Chance.
3. Betrieb vereinfachen: Am Ende baut die CI ein einziges Docker-Image. Strapi und seine Datenbank sind ersatzlos entfallen — ein System weniger, das gepatcht, überwacht und gesichert werden will.

Den alten Stand haben wir übrigens eine Weile als Referenz im Repository behalten. Nichts beschleunigt einen Rebuild so sehr wie die Möglichkeit, schnell nachzusehen, wie etwas vorher war.

Was Astro nicht ist

Genauso wichtig wie das Warum ist das Wofür-nicht: Astro ersetzt bei uns kein Anwendungs-Frontend. Unsere Produkte sind echte Webanwendungen mit Zuständen, Formularen und Echtzeit-Verhalten — dort sind Vue und Nuxt weiterhin gesetzt und bewähren sich seit Jahren. Die Erkenntnis ist keine Framework-Entscheidung, sondern eine Werkzeug-Entscheidung:

Anwendungen brauchen ein Anwendungs-Framework. Inhaltsseiten brauchen keins.

Fazit

Der Relaunch hat sich an drei Stellen ausgezahlt: schnellere Seiten (HTML statt Hydration), einfacherer Betrieb (ein System statt drei) und bessere Redaktion (Git-Workflow statt CMS-Pflege). Wenn Ihre Website eigentlich eine Inhaltsseite ist, die ein SPA-Framework mit angeschlossenem CMS spazieren fährt, lohnt sich der prüfende Blick — das Ergebnis ist weniger Maschine und mehr Seite.