Server-Side Rendering (SSR): Definition, Pros, Wann nutzen

SSR generiert HTML auf dem Server pro Request — schnelles First-Paint, SEO-friendly, dynamisch. Genutzt von Next.js, Nuxt, Remix, SvelteKit.

Was ist Server-Side Rendering (SSR)?

Server-Side Rendering (SSR) ist eine Web-Rendering-Strategie, bei der HTML auf dem Server für jeden Request generiert und ready-to-display an den Browser geschickt wird. Der Browser zeigt Content sofort an; JavaScript "hydratiert" die Seite dann interactive. SSR kontrastiert mit Client-Side Rendering (CSR).

SSR ist der Default-Rendering-Modus für moderne Frameworks wie Next.js, Nuxt, SvelteKit und Remix.

Wie SSR funktioniert

  1. Browser requested /products/42
  2. Server fetcht Daten, läuft Komponenten-Tree, generiert HTML
  3. Server returnt HTML — Browser displayed sofort
  4. Browser lädt JavaScript-Bundle
  5. JS hydratiert HTML — Page wird interactive

SSR vs andere Rendering-Strategien

StrategieHTML generiertTrade-off
SSRPro Request, auf ServerFrisch + SEO; braucht Server
SSG (Static)Einmal at Build-TimeSchnellste Delivery; stale
CSRIm Browser via JSApp-like UX; langsames First-Paint
ISRBuild + on-demandStatic-Perf + dynamic Frische
Edge SSRPro Request at CDN-EdgeLow-Latency global

Wann SSR die richtige Wahl ist

  • Per-User-Personalisierung.
  • Frequently changing Content.
  • SEO-kritisch mit dynamic Daten.
  • Geo-lokalisierter Content.
  • A/B-Testing auf Page-Level.
  • Heavy Auth/Session-Logic.

Wann NICHT SSR

  • Statische Marketing-Pages.
  • Logged-in Dashboards ohne SEO-Need.
  • Highly interactive Apps mit simpler Home-Page.

SSR Pros und Cons

ProsCons
Schnelles First-Paint (LCP)Langsamere TTFB als SSG
SEO-friendly out-of-boxBraucht laufenden Server
Immer frischer ContentHöhere Hosting-Kosten
Per-User-PersonalisierungCache-Komplexität

Hydration: der SSR-Catch

Nach SSR muss Client "hydraten". Hydration ist teuer.

SSR mit Next.js (App Router)

export default async function ProductPage({ params }) {
  const product = await fetchProduct(params.id);
  return <div><h1>{product.name}</h1></div>;
}

SSR mit Express + React

import { renderToString } from 'react-dom/server';

app.get('/', (req, res) => {
  const html = renderToString(<App />);
  res.send(`<div id="root">${html}</div>`);
});

SSR Best Practices

  • Wisely cachen.
  • Streaming SSR nutzen.
  • Server-only Data-Fetching.
  • Database-Queries server-side cachen.
  • Cache-Headers thoughtfully setzen.
  • Hydration-Kosten überwachen.
  • Errors am Server handeln.
  • TTFB + LCP monitoren.

Häufige SSR-Fallstricke

  • Window/document Referenzen in Server-Code.
  • Server-Client-Mismatch.
  • Langsame DB-Queries blocken Response.
  • Vergessen zu cachen.
  • Bundle-Bloat.
  • Memory-Leaks.
  • Auth in Middleware.

FAQ: Server-Side Rendering

SSR oder SSG: was ist besser?

Hängt von Content-Frische ab.

Fixt SSR SEO automatisch?

Crawler bekommen HTML, aber Title/Meta/Structured-Data noch nötig.

Ist SSR langsamer als CSR?

Für TTFB: SSR langsamer. Für First-Paint: SSR viel schneller.

Was über TTFB mit SSR?

Höher als SSG. Mit Edge SSR mitigieren.

Kann ich SSR und CSR mixen?

Ja.

Was ist React Server Components?

Components laufen nur auf Server.

Ist SSR teuer im Hosting?

Mehr als SSG. Modern serverless macht es bei niedrigem Traffic billig.

SSR-Apps mit LoadFocus load-testen

SSR shifted Arbeit zum Server — Load-Testing ist essentiell. Registrieren bei loadfocus.com/signup.

Wie schnell ist Ihre Website?

Steigern Sie ihre Geschwindigkeit und SEO nahtlos mit unserem kostenlosen Geschwindigkeitstest.

Kostenloser Websitespeed-Test

Analysieren Sie die Ladegeschwindigkeit Ihrer Website und verbessern Sie ihre Leistung mit unserem kostenlosen Seitengeschwindigkeits-Checker.

×