Was ist Hydration?
Hydration ist der Prozess, bei dem JavaScript auf dem Client sich an server-rendered HTML "attacht", statisches Markup in eine interaktive Anwendung verwandelt. Nach SSR sendet der Server HTML an den Browser, das JS-Bundle downloaded, parsed und re-runs den Component-Tree, um Event-Handler zu attachen, State zu restoren und die Page interactive zu machen.
Hydration ist fundamental für SSR-basierte Frameworks. Es ist auch der primäre Cost von SSR — schwere Hydration ist die Leading-Cause für poor INP.
Die Hydration-Sequence
- Server rendert HTML und sendet zum Browser
- Browser zeigt HTML an
- Browser lädt JS-Bundle
- JS parsed + executet
- JS walked das existing DOM, matched Elements zu Components
- JS attacht Event-Handler, initialisiert State
- Page ist jetzt actually interactive
Warum Hydration langsam ist
- Entire Component-Tree re-runs.
- JS-Bundle-Size.
- Synchronous auf Main-Thread.
- Resource-Competition.
- Cold-Starts auf langsamen Devices.
Moderne Lösungen für Hydration-Cost
| Technique | Wie es funktioniert | Genutzt von |
|---|---|---|
| Partial Hydration | Nur als interactive markierte Components hydraten | Astro Islands |
| Streaming SSR | Server streamed HTML-Chunks | React 18+, Next.js |
| Progressive Hydration | Hydraten when in Viewport | RSC, Astro |
| Resumability (Qwik) | Skip Hydration; lazy-load Handler | Qwik |
| React Server Components | Components laufen nur server-side | Next.js App Router |
| Selective Hydration | Hydraten Part user interacted with first | React 18+ |
Hydration vs no-Hydration Approaches
| Approach | JS-Cost | Interactivity |
|---|---|---|
| SPA (CSR) | Alles JS upfront | Interactive nach JS-Load |
| SSR + Hydration | Full JS auf jeder Page | Visible fast, interactive nach Hydration |
| SSG (no JS) | Zero JS | Static |
| Partial Hydration | Nur interactive Components | Mostly static, interactive Islands |
| Resumability | ~No JS upfront | Visible + clickable immediately |
Häufige Hydration-Probleme
Hydration-Mismatch
Server-rendered HTML differs from Client-rendered Output.
Slow Hydration auf heavy Pages
Pages mit Tausenden Components hydraten langsam.
Hydration blocking User-Input
User clicked Button während Hydration läuft.
Hydration Best Practices
- Geshipptes JS minimieren.
- Partial Hydration nutzen.
- SSR/CSR-Mismatches vermeiden.
- HTML streamen.
- Non-critical Hydration deferren.
- Auf echten Devices testen.
- Zero-JS für Content-Pages erwägen.
- INP in Production monitoren.
Häufige Hydration-Fallstricke
- Hydration-Mismatches in Dev.
- Window-References während Render.
- Random IDs.
- Heavy Global-State-Init.
- Big Component-Trees auf jeder Route.
- Third-party Scripts synchronously.
- Vergessen auf langsamen Devices zu testen.
FAQ: Hydration
Warum ist Hydration nötig?
SSR sendet statisches HTML für fast First-Paint. Hydration added den JS-Layer.
Wie lang sollte Hydration dauern?
< 100ms auf fast Device, < 300ms auf Mid-Tier Mobile.
Unterschied zwischen Hydration und Rendering?
Rendering: HTML produzieren. Hydration: JS an existing HTML attachen.
Was ist "React-Hydration"?
ReactDOM.hydrateRoot() walked server-rendered DOM.
Kann ich Hydration ganz vermeiden?
Für non-interactive Pages: ja. Für interactive: via Qwik oder Partial Hydration.
Was ist React Server Components?
Components, die nur server-side laufen.
Beeinflusst Hydration SEO?
Indirekt — via Core Web Vitals (INP, LCP).
Hydration-Cost mit LoadFocus testen
LoadFocus läuft Lighthouse-Audits aus 25+ Regionen, misst INP und Total Blocking Time. 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.