Was ist Server-Side Rendering (SSR)?

Server-Side Rendering erzeugt das HTML einer Seite pro Request auf einem Server oder Edge-Runtime und sendet das fertige Markup an den Browser. In headless-commerce-Storefronts ist SSR der Default, wenn Inhalte stark dynamisch oder personalisiert sind oder ohne Wartezeit auf Client-JavaScript SEO-fähig ausgeliefert werden müssen.

Definition

SSR führt denselben Komponentenbaum, der sonst im Browser laufen würde, auf Node.js, Bun, Deno oder einem Edge-Worker wie Cloudflare Workers oder Vercel Edge aus. Der Server fragt Commerce-, Content-, Search- und Personalisierungs-APIs ab, erzeugt ein HTML-Dokument und liefert es an den Client. Der Browser bekommt schnell ein sinnvolles First Paint und übernimmt anschließend per Hydration die Interaktivität. SSR ist Standard in Next.js, Nuxt, Remix, SvelteKit und Astro und wird oft mit Caching-Strategien wie ISR oder stale-while-revalidate kombiniert.

Warum es zählt

SSR ist der sicherste Weg zu guten LCP- und akzeptablen TTFB-Werten, wenn Daten zu oft wechseln für static-site-generation oder Personalisierung gefordert ist. Suchmaschinen erhalten vollständiges Markup, was für Kategorieseiten, PDPs und Content-Bereiche entscheidend ist. In composable-commerce-Stacks zentralisiert SSR außerdem die API-Orchestrierung: Der Storefront-Server fanned parallel zu Commerce-Backend, CMS, Search und Recommendation aus und assembliert ein konsistentes Dokument. Das schirmt den Client von API-Komplexität ab und stabilisiert die Core Web Vitals.

Anwendungsfälle

Typische SSR-Fälle sind eingeloggte Warenkörbe, lokalisierte Preise, inventarbewusste PDPs und personalisierte landing-page-Varianten. Headless-Teams mit Next.js kombinieren SSR häufig mit React Server Components und Streaming SSR, um früh HTML zu flushen, während schwere Daten nachladen. Edge Rendering auf Vercel Edge oder Cloudflare Workers bringt SSR näher an die Nutzer globaler Storefronts. Cache-Layer-Strategien cachen vollständiges HTML für anonymen Traffic und fallen für personalisierte Sessions auf Request-SSR zurück. SSR ist selten noch eine binäre Entscheidung - moderne Stacks mischen SSR, SSG, ISR und CSR pro Route, um Frische, Kosten und Performance auszubalancieren.

Verwandt

Mehr dazu: Composable Headless Frontend · Performance and Core Web Vitals.