Statamic mit Astro: Wann ein statisches Frontend Sinn ergibt

Die kurze Antwort: wenn eine Seite für alle Besucher gleich aussieht und schnell sein muss. Dann pflegt die Redaktion die Inhalte wie gewohnt im Control Panel von Statamic, und Astro erzeugt daraus vorab fertige HTML-Seiten. Beim Aufruf läuft auf dem Server kein CMS, keine Datenbankabfrage, kein Template: Der Webserver liefert eine Datei aus.

Astro rendert Seiten, Routen und Endpunkte standardmäßig beim Build als statische Seiten ^[2]. Der Build ist der Moment, in dem Astro die Inhalte aus dem CMS holt und daraus fertige HTML-Dateien für den Webserver erzeugt; ausgelöst wird er automatisch, etwa nach dem Speichern, nach Zeitplan oder per Knopf. Komponenten werden zu reinem HTML und CSS, clientseitiges JavaScript entfernt Astro dabei automatisch ^[1]. Wo eine Seite doch Interaktion braucht, etwa ein Karussell oder einen Rechner, kommt nur für dieses Element JavaScript dazu; Astro nennt das „Inseln“ ^[1]. Statamic liefert die Inhalte über seine REST- oder GraphQL-Schnittstelle, die Teil von Statamic Pro sind ^[3].

Typische Fälle sind Kampagnen- und Landingpages, bei denen jede Millisekunde zählt, Microsites zu einem Produkt oder einer Veranstaltung und Unternehmensseiten, die sich ein paar Mal pro Woche ändern, aber jeden Tag gelesen werden. Für Ihre Agentur bleibt der Ablauf derselbe: Sie bringen die Daten, der Rest klappt.

Die Seite, die Sie lesen, ist ein Beispiel für den dritten Weg. Inhalte, Pakete, Fragen und diese Artikel liegen in Statamic 6 auf Laravel 13. Astro 7 holt sie beim Build über die REST-Schnittstelle von Statamic und schreibt daraus statische Seiten, das Stylesheet steht direkt im HTML. Auf dem Webserver liegen nur die fertigen Dateien und ein kleines PHP-Skript, das Anfragen aus den Formularen verschickt. Das Control Panel muss dafür nicht öffentlich erreichbar sein.

Jeder Inhalt wird beim Build gegen feste Regeln geprüft. Ist ein SEO-Titel länger als 60 Zeichen, fehlt eine Pflichtangabe oder verweist eine Fußnote auf eine Quelle, die es nicht gibt, bricht der Build ab, statt eine fehlerhafte Seite zu veröffentlichen. Die Fehlermeldung nennt Abschnitt und Feld. Das ist kein Feature von Astro, sondern Teil des Projekts, und genau diese Art Absicherung bauen wir auch für Kundenprojekte.

Die Messwerte unten gelten für den Tag der Messung. Lighthouse ist ein offenes Prüfwerkzeug von Google mit Tests für Performance, Barrierefreiheit, SEO und mehr ^[6]. Ein guter Wert ersetzt keine Prüfung mit Tastatur und Screenreader, mehr dazu unter Statamic barrierefrei.

Ein statisches Frontend ist kein Selbstzweck. Für Login-Bereiche, Portale und Inhalte, die je nach Besucher anders aussehen, braucht es einen Server, der bei jedem Aufruf rechnet. Astro kann das mit einem Adapter ^[2], aber dann ist der Vorteil kleiner, und Statamic mit eigenen Laravel-Funktionen ist oft der direktere Weg. Auch wenn eine Redaktion Änderungen sekundengenau live sehen muss, ist der Umweg über einen Build eher hinderlich.

Für die meisten Unternehmensseiten reicht aus unserer Sicht Statamic mit dem eingebauten Static Caching ^[4]. Astro empfehlen wir, wenn Tempo das Hauptargument ist: für Kampagnen, Landingpages und Seiten, die mit ihren Messwerten verkaufen sollen. Die Lizenzen für unsere Basis-Werkzeuge sind in der Wartung enthalten, ohne Wartung bis zum Launch; auf Wunsch bauen wir auch Lizenzen Ihres Kunden oder Ihrer Agentur ein. Die Pakete stehen unter Pakete, den Vergleich der Systeme finden Sie unter Statamic oder WordPress.