Warum SSR besser als SSG ist

Jun 30, 2024

Warum SSR allein ausreicht

SSR (Server-Side Rendering) bedeutet, dass Seiten bei Bedarf zur Laufzeit auf dem Server gerendert und dann an das Frontend gesendet werden. SSG (Static Site Generation) bezieht sich auf das Vorab-Kompilieren von HTML und anderen statischen Dateien, die dann direkt an das Frontend gesendet werden, wenn Benutzer sie anfordern.

Mit diesen Definitionen ist es leicht zu verstehen, dass SSR dynamische Logik einbetten kann, aber einen ständig laufenden Server erfordert, während SSG besser für statische Inhalte geeignet ist, die auf einem CDN platziert werden können. Das bekannte NextJS-Framework unterstützt sowohl SSR als auch SSG. Das neuere Remix-Framework hat SSG jedoch vollständig aufgegeben, da es genügend Vorteile in diesem Ansatz sieht. Basierend auf meiner Erfahrung macht dieser Ansatz mit moderner CDN-Unterstützung durchaus Sinn.

Moderne CDNs wie Cloudflare und Vercel unterstützen serverlose Umgebungen, wodurch das Deployment von NodeJS-Anwendungen fast so bequem ist wie das Deployment statischer Dateien.
Der Hauptvorteil von SSG ist das direkte Deployment statischer Dateien auf CDNs, um Serverressourcen zu sparen. SSR kann jedoch auch leicht Inhalte auf CDNs zwischenspeichern, indem entsprechende Cache-Control-Header gesetzt werden. Dies bedeutet, dass der SSR-Server nur bei der ersten Anfrage läuft, was ihn fast nicht von statischen Dateien unterscheidbar macht.
Keine Neukompilierung und kein Redeployment bei jeder Änderung statischer Inhalte erforderlich.
Sobald man den NextJS-Ansatz der Unterscheidung zwischen SSG und SSR aufgibt, wird die mentale Belastung deutlich reduziert. Cache-Einstellungen basieren vollständig auf HTML-Standards wie Cache-Control, ohne dass eine zusätzliche Schnittstelle erlernt werden muss. Das Debuggen von Cache-Problemen wird auch viel einfacher - wenn der Browser eine Anfrage zwischenspeichert, die nicht zwischengespeichert werden sollte, muss man nur die Response-Konfiguration überprüfen.

Ein Beispiel

Tatsächlich ist die offizielle Remix-Website ein ausgezeichnetes Beispiel. Ihre Dokumentation wird mit SSR generiert. Viele Leute denken vielleicht, dass SSG am besten geeignet wäre, da Dokumentation nur statischer Text ist. Das Remix-Team erklärt ihre Überlegungen.

Ihre Dokumentation ist im Remix-Quellcode-Repository gespeichert, nicht direkt auf der offiziellen Website geschrieben. Dieser Ansatz, Dokumentation mit Quellcode zu halten, hat mehrere Vorteile:

Referenzierbarer beim Lesen von Code
Einfacher, Dokumentation beim Ändern von Code zu aktualisieren
Git verfolgt Dokumentationsänderungen automatisch und bindet sie an Quellcode-Versionen

Der Server der offiziellen Website liest aus dem Remix-Quellcode-Repository und generiert Dokumentationsseiten durch SSR. Dieser Ansatz hat mehrere Vorteile:

Keine Neukompilierung und kein Redeployment der gesamten Website bei jeder Dokumentationsänderung erforderlich
Direkter Zugriff auf Dokumentation für jede Remix-Version aus dem Quellcode-Repository, sogar die neueste Dokumentation vom dev-Branch. Dies ermöglicht der offiziellen Website, Dokumentation entsprechend jeder Remix-Version anzuzeigen.

Da Dokumentation keine Echtzeitdaten sind, haben sie einige Cache-Optimierungen implementiert:

Verwendung von lru-cache zum Zwischenspeichern von Dokumentationsergebnissen. Der Cache ist serverseitig, sodass alle Clients profitieren.
- Timeout auf 5 Minuten gesetzt
Einstellung von Cache-Control auf stale-while-revalidate. Dies ermöglicht CDN-Caching:
```
return json(
  { doc },
  {
    headers: {
      "Cache-Control": "max-age=300, stale-while-revalidate=604800",
    },
  }
);
```
Dies bedeutet, dass bei Änderungen an der Dokumentation die offizielle Website die Änderungen mit einer maximalen Verzögerung von 5 Minuten (max-age=300) anzeigt.