Server-Side Rendering (SSR)

Server-Side Rendering ist ein Rendering-Pattern, bei dem der HTML-Code einer Seite auf dem Server generiert wird, bevor er an den Browser gesendet wird. Im Gegensatz dazu laedt Client-Side Rendering (CSR) nur ein leeres HTML-Geruest mit JavaScript, das dann erst im Browser den Content aufbaut -- mit deutlichen Nachteilen fuer SEO und initiale Ladezeit.

SSR bietet drei zentrale Vorteile: Erstens ist der Content sofort beim ersten HTTP-Response vollstaendig vorhanden, was zu schnelleren LCP-Werten und besserer wahrgenommener Geschwindigkeit fuehrt. Zweitens koennen Suchmaschinen und AI-Crawler den Content ohne JavaScript-Ausfuehrung lesen -- entscheidend fuer GPTBot, ClaudeBot und PerplexityBot, die bei zu langsamem JS-Rendering abbrechen. Drittens funktioniert die Seite auch fuer Nutzer mit schlechter Internetverbindung oder deaktiviertem JavaScript.

Der Nachteil: SSR erzeugt pro Request Server-Last. Bei hohem Traffic oder rechenintensiven Seiten kann das Kosten treiben. Moderne Frameworks wie Next.js loesen das durch hybrides Rendering: Statische Seiten werden vorab gerendert (SSG), dynamische on-demand (SSR), und Incremental Static Regeneration (ISR) kombiniert beides.

Technisch funktioniert SSR so: Der Server empfaengt die Anfrage, fuehrt den React-Code aus (React.renderToString in Next.js), generiert das vollstaendige HTML, sendet es an den Browser. Nach dem ersten Paint "hydrated" React die Seite und macht sie interaktiv.

Fuer Alunah-Kunden ist SSR Standard: Alle Projekte laufen auf Next.js 16 mit Server Components und optionalem SSG-Fallback. Das resultiert in LCP-Werten unter 1,5s, perfekten Core Web Vitals und AI-Crawler-Kompatibilitaet. Der Performance-Unterschied zu WordPress-Setups ist messbar: typischerweise 2-4x schnellere Ladezeiten bei vergleichbarer Server-Groesse.