Was SSR verändert
SSR verlagert die Erzeugung des initialen Markups auf den Server. Der Browser erhält das HTML, danach können JavaScript-Komponenten die interaktiven Teile hydrieren. SSR ist nicht gleichbedeutend mit statischer Generierung, Caching, schneller TTFB oder erfolgreicher Indexierung.
Maßgeblich ist die Antwort und ihr Status für eine echte URL, nicht eine Einstellung im Framework.
Antwort testen
Prüfen Sie das initiale HTML bei deaktiviertem JavaScript oder über einen rohen Abruf. Kontrollieren Sie Status, Canonical, den Haupttext und das Fehlerverhalten, bevor die Hydrierung einsetzt.
- Initiales HTML abrufen.
- Eine nicht vorhandene Route testen.
- Gerenderten und rohen Inhalt vergleichen.
- TTFB separat messen.
- Cache-Varianten testen.
Den Rendering-Weg wählen
Setzen Sie SSR dort ein, wo anfragebezogene Daten oder Personalisierung nötig sind und der Origin-Server zuverlässig antworten kann. Statische oder gecachte Ausgaben passen bei stabilen öffentlichen Seiten oft besser.
| Frage | Prüfung | Grenze |
|---|---|---|
| Initiale Inhalte | Im HTML der Antwort vorhanden | HTML allein garantiert keine Qualität |
| Fehlerroute | Korrekter Status 404/410/500 | Die Client-UI kann den Status verdecken |
| Leistung | TTFB und Assets getrennt prüfen | Ein einzelner Wert verdeckt die Schichten |
Grenzen von SSR
Eine serverseitig gerenderte Seite kann trotzdem langsam sein, einen Fehler liefern oder Inhalte hinter späteren Client-Aufrufen verbergen.