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
- Browser requested
/products/42 - Server fetcht Daten, läuft Komponenten-Tree, generiert HTML
- Server returnt HTML — Browser displayed sofort
- Browser lädt JavaScript-Bundle
- JS hydratiert HTML — Page wird interactive
SSR vs andere Rendering-Strategien
| Strategie | HTML generiert | Trade-off |
|---|---|---|
| SSR | Pro Request, auf Server | Frisch + SEO; braucht Server |
| SSG (Static) | Einmal at Build-Time | Schnellste Delivery; stale |
| CSR | Im Browser via JS | App-like UX; langsames First-Paint |
| ISR | Build + on-demand | Static-Perf + dynamic Frische |
| Edge SSR | Pro Request at CDN-Edge | Low-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
| Pros | Cons |
|---|---|
| Schnelles First-Paint (LCP) | Langsamere TTFB als SSG |
| SEO-friendly out-of-box | Braucht laufenden Server |
| Immer frischer Content | Höhere Hosting-Kosten |
| Per-User-Personalisierung | Cache-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.
Verwandte LoadFocus-Tools
Setze dieses Konzept mit LoadFocus in die Praxis um — derselben Plattform, die alles antreibt, was du gerade gelesen hast.