Astro + SSG bringen schnelle Seiten ohne Server-Runtime. Was das für Wartung, Sicherheit und Kosten bedeutet.
Statische Auslieferung heißt: Jede Seite wird einmal zur Build-Zeit erzeugt und danach als fertiges HTML ausgeliefert. Kein Server-Prozess, der pro Anfrage rechnet, keine Datenbank, die im Moment des Klicks antworten muss. Der Browser bekommt genau die Datei, die beim letzten Build entstanden ist — und die liegt idealerweise schon im Cache am nächsten Netzknoten.
Für ein Marketing-Angebot, einen Blog oder eine Dokumentation ist das kein Kompromiss, sondern der Normalfall. Wir bauen die öffentlichen Seiten von Tracht Digital Solutions mit Astro im Modus output: 'static' — und liefern sie ohne Node-Runtime auf dem Produktionsserver aus.
Statisch heißt nicht „unveränderlich“ und schon gar nicht „ohne Inhalte aus einer Datenbank“. Es heißt nur: Der teure Teil — Daten holen, Templates rendern, HTML zusammensetzen — passiert einmal beim Build, nicht bei jedem Besuch.
Der Unterschied zu einer klassisch server-gerenderten Seite ist der Zeitpunkt. Server-Rendering rechnet pro Anfrage; statische Auslieferung rechnet pro Veröffentlichung. Bei Inhalten, die sich stündlich und nicht pro Sekunde ändern, ist der zweite Weg um Größenordnungen effizienter.
Ohne Runtime gibt es keine Cold Starts, keine Datenbank im kritischen Pfad, keinen Anwendungsserver, der unter Last einbricht. Eine HTML-Datei vom CDN ist praktisch immer schneller ausgeliefert als eine, die erst berechnet werden muss.
Astro hilft zusätzlich mit „Islands“: Interaktive Komponenten werden nur dort geladen, wo sie wirklich gebraucht werden. Der Rest der Seite bleibt reines HTML ganz ohne JavaScript. Das Ergebnis sind kleine Bundles, kurze Ladezeiten und stabile Core-Web-Vitals-Werte — messbar, nicht nur gefühlt.
Die sicherste Komponente ist die, die es gar nicht gibt. Wo kein Anwendungsserver läuft und keine Datenbank am öffentlichen Endpunkt hängt, fehlt die halbe Angriffsfläche: keine SQL-Injection, kein verwundbarer Server-Prozess, keine veraltete Runtime, die ständig gepatcht werden will.
Dynamik, die tatsächlich einen Server braucht — Login, Zahlungen, Kundendaten — kapseln wir bewusst in getrennte APIs hinter einem einzigen Gateway. Die öffentliche Seite selbst bleibt eine Sammlung statischer Dateien und ist damit denkbar schwer anzugreifen.
Statisches Hosting ist günstig und langweilig — im besten Sinn. Es gibt keinen Prozess, der nachts abstürzt, kein Autoscaling, das konfiguriert werden will, keine Runtime-Version, die zum Sicherheitsrisiko wird. Ein Fehler im Build fällt vor dem Deploy auf, nicht um drei Uhr nachts im Log.
Für kleine und mittlere Unternehmen ist das der eigentliche Gewinn: planbare Kosten und eine Seite, die auch dann zuverlässig läuft, wenn monatelang niemand am Server schraubt.
Der häufigste Einwand lautet: „Aber unsere Inhalte ändern sich doch.“ Genau dafür fließen sie zur Build-Zeit ein. Blogbeiträge und redaktionelle Abschnitte kommen aus einem Headless-CMS und werden beim Bauen als HTML eingebacken. Wer im Redaktionswerkzeug auf „Veröffentlichen“ klickt, stößt einen neuen Build an — Sekunden später ist die Änderung live.
Schlägt der Abruf einmal fehl, fällt die Seite auf ihren statischen Standardinhalt zurück, statt kaputtzugehen. Der Build bricht nicht an einem kurzen Schluckauf der Schnittstelle.
Hochdynamische, pro Nutzer personalisierte Ansichten gehören nicht in eine statische Seite, sondern in eine App: ein Kundenkonto, ein Warenkorb, ein Dashboard mit Live-Daten. Dort ist ein Server-Prozess kein Ballast, sondern die eigentliche Aufgabe.
Die ehrliche Antwort ist deshalb selten „entweder/oder“. Öffentliche Seiten liefern wir statisch aus; die App-Teile bekommen ihre eigene, klar abgegrenzte Infrastruktur. So zahlt jede Seite genau den Aufwand, den sie wirklich braucht — und keinen Cent mehr.