Zwei Wege, ein Frontend auszuliefern: Statische Dateien oder ein laufender Server

Wenn du mit dem Bau einer Frontend-Anwendung beginnst, gibt es eine Frage, die deine gesamte Deployment-Pipeline stärker prägt als jede Framework-Entscheidung: Braucht diese App einen Server, der am Leben bleibt, oder kann sie als Ordner mit Dateien existieren?

Das ist keine theoretische Architekturdebatte. Es ist eine praktische Entscheidung, die bestimmt, wie du baust, wo du deployst, was schiefgehen kann und wie du es behebst.

Das statische Frontend: Dateien, die für sich selbst sprechen

Stell dir vor, du baust eine Unternehmensprofilseite, eine Dokumentationsseite oder eine Marketing-Landingpage. Du schreibst etwas HTML, fügst CSS hinzu, wirfst ein paar Bilder rein und lädst es irgendwo hoch. Der Browser lädt diese Dateien herunter und rendert sie. Fertig.

Das ist ein statisches Frontend. Alles, was der Browser braucht, ist zur Build-Zeit bereit. HTML, CSS, JavaScript, Schriftarten, Bilder – sie werden alle zu Dateien, die auf einem einfachen Webserver, einem CDN oder einem S3-Bucket liegen können. Nach dem Deployment läuft kein Serverprozess. Kein Warten auf eine Runtime, die starten muss. Die Dateien liegen einfach da und warten darauf, ausgeliefert zu werden.

Aber statisch bedeutet nicht einfach. Eine React- oder Vue-Anwendung, die Daten von einer API abruft, kann dennoch in statische Dateien gebaut werden. Der Unterschied ist, dass die Daten erst erscheinen, wenn der Browser das JavaScript ausführt und API-Aufrufe tätigt. Das nennt man Client-Side Rendering. Das anfängliche HTML ist vielleicht nur eine Hülle, und der eigentliche Inhalt wird erst nach dem Laden der Seite eingefügt.

Die Pipeline für ein statisches Frontend ist unkompliziert:

  1. Führe den Build-Befehl aus.
  2. Sammle die Ausgabedateien.
  3. Lade sie in den Storage oder auf ein CDN hoch.

Kein Server-Neustart. Kein Health Check. Kein Warten darauf, dass ein Prozess bereit ist. Das Deployment kann so einfach sein wie das Ersetzen von Dateien in einem Bucket oder das Aktualisieren eines CDN-Zeigers. Wenn etwas schiefgeht, wechselst du zurück zu den vorherigen Dateien. Es ist schnell, günstig und schwer zu zerstören.

Das SSR-Frontend: Seiten, die auf Abruf gekocht werden

Betrachten wir nun eine E-Commerce-Seite, die Echtzeitpreise, Lagerbestände und personalisierte Empfehlungen anzeigt. Wenn du dies als statische Dateien baust, sehen die Benutzer veraltete Daten, bis der Browser JavaScript ausführt und frische Informationen abruft. Diese Verzögerung kann Umsätze kosten, Kunden verwirren und die App träge wirken lassen.

Hier kommt Server-Side Rendering (SSR) ins Spiel. Wenn ein Benutzer eine Seite anfordert, ruft der Server die neuesten Daten ab, rendert das HTML und sendet eine vollständig geformte Seite an den Browser. Der Benutzer sieht den Inhalt sofort, ohne darauf warten zu müssen, dass JavaScript geladen und ausgeführt wird.

SSR bedeutet, dass dein Frontend nicht mehr nur aus Dateien besteht. Es ist eine laufende Anwendung, die einen Server, Abhängigkeiten, Umgebungsvariablen und ordnungsgemäße Startsequenzen benötigt. Die Pipeline ähnelt nun eher einem Backend-Deployment:

  1. Baue die Anwendung in serverbereiten Code.
  2. Installiere Runtime-Abhängigkeiten.
  3. Konfiguriere Umgebungsvariablen für die Zielumgebung.
  4. Starte den Serverprozess oder deploye in einen Container.
  5. Führe Health Checks durch, um zu bestätigen, dass der Server Anfragen annimmt.
  6. Leite den Traffic zur neuen Version.
  7. Überwache auf Fehler nach dem Umschalten.

Wenn etwas schiefgeht, bedeutet ein Rollback das Zurücksetzen der Serverversion, nicht nur das Austauschen von Dateien. Du musst dich um Datenbankverbindungen, Session-Zustände und Cache-Invalidierung kümmern. Es ist komplexer, aber notwendig, wenn Benutzer bei jedem Seitenaufruf frische Daten benötigen.

Der Mittelweg: Static Site Generation

Es gibt einen hybriden Ansatz namens Static Site Generation (SSG). Er sieht während der Build-Zeit wie SSR aus, verhält sich aber zur Laufzeit wie eine statische Seite. Das Rendering erfolgt einmal während des Builds, nicht bei jeder Anfrage. Das Ergebnis ist eine Reihe von vorgerenderten HTML-Dateien, die statisch ausgeliefert werden können.

SSG funktioniert gut für Inhalte, die sich nicht jede Sekunde ändern. Blogbeiträge, Dokumentationsseiten, Produktseiten, die von einem CMS abgerufen werden – diese können zur Build-Zeit gerendert und als statische Dateien ausgeliefert werden. Der Benutzer erhält schnelle Seitenladezeiten, und du vermeidest die Verwaltung einer Server-Runtime.

Aber SSG hat einen Nachteil. Wenn sich deine Inhalte häufig ändern, musst du die gesamte Seite neu bauen und deployen. Für einen Blog mit einem neuen Beitrag pro Woche ist das in Ordnung. Für eine E-Commerce-Seite mit Lagerbestandsaktualisierungen jede Minute wird SSG unpraktisch.

Was das für deine Pipeline bedeutet

Die Wahl zwischen statisch, SSR und SSG ist nicht nur eine Frage der Architektur. Es geht darum, wie oft sich deine Inhalte ändern, wie schnell Benutzer Aktualisierungen sehen müssen und wie viel operativen Overhead dein Team bewältigen kann.

Hier ist eine schnelle Möglichkeit, darüber nachzudenken:

Das folgende Diagramm führt durch die Entscheidung und zeigt die entsprechende Pipeline für jeden Pfad.

flowchart TD A[Braucht die App einen Server?] -->|Nein| B[Statisches Frontend] A -->|Ja| C[Ändern sich die Inhalte ständig?] C -->|Nein| D[SSG - Static Site Generation] C -->|Ja| E[SSR - Server-Side Rendering] B --> F[Statische Dateien bauen] F --> G[Auf CDN / S3 hochladen] G --> H[Dateien ausliefern] D --> I[HTML bauen & vorrendern] I --> J[Statische Ausgabe hochladen] J --> K[Als statische Dateien ausliefern] E --> L[Server-Code bauen] L --> M[Runtime-Abhängigkeiten installieren] M --> N[Serverprozess starten] N --> O[Health Check & Traffic routen]
  • Statisch: Inhalte ändern sich selten. Benutzer können eine kleine Verzögerung tolerieren, bevor Daten erscheinen. Du möchtest das einfachstmögliche Deployment.
  • SSR: Inhalte ändern sich ständig. Benutzer benötigen bei jedem Seitenaufruf frische Daten. Du bist bereit, eine Server-Runtime zu verwalten.
  • SSG: Inhalte ändern sich periodisch. Du möchtest schnelle Seitenladezeiten, ohne einen Server zu betreiben. Du kannst die Seite neu bauen, wenn sich die Inhalte aktualisieren.

Deine Pipeline sollte dieser Entscheidung folgen, nicht dagegen ankämpfen. Wenn du dich für statisch entscheidest, füge keine unnötige Serververwaltung hinzu. Wenn du dich für SSR entscheidest, tue nicht so, als wäre es nur ein Ordner mit Dateien.

Eine praktische Checkliste vor der Entscheidung

Bevor du dich für eine Deployment-Strategie festlegst, beantworte diese Fragen:

  • Wie oft ändern sich die Inhalte auf dieser Seite? Jede Sekunde, jede Stunde oder jede Woche?
  • Können Benutzer warten, bis JavaScript nach dem Laden der Seite Daten abruft, oder benötigen sie den Inhalt sofort?
  • Hat dein Team die Kapazität, eine Server-Runtime zu verwalten, einschließlich Überwachung, Neustarts und Rollbacks?
  • Wie schnell musst du dich von einem fehlerhaften Deployment erholen? Das Austauschen von Dateien ist schneller als ein Server-Neustart.
  • Wird dieselbe Seite für verschiedene Benutzer basierend auf ihrer Sitzung oder ihrem Standort anders aussehen?

Deine Antworten werden dich zum richtigen Ansatz führen. Lass dich nicht vom Framework oder vom Hype leiten.

Die konkrete Erkenntnis

Ein statisches Frontend ist ein Ordner mit Dateien. Ein SSR-Frontend ist eine laufende Anwendung. Behandle sie in deiner Pipeline unterschiedlich, und du vermeidest unnötige Komplexität oder das Übersehen kritischer Schritte. Beginne mit dem einfachsten Ansatz, der das Bedürfnis deiner Benutzer nach frischen Inhalten erfüllt, und füge Server-Side Rendering nur hinzu, wenn die Daten es erfordern.