Qu'est-ce que l'hydration ?
L'hydration est le processus où JavaScript sur le client s'"attache" au HTML server-rendered, transformant du markup statique en une application interactive. Après que SSR envoie HTML au navigateur, le bundle JS télécharge, parse et re-exécute le component tree pour attacher des event handlers, restaurer state et rendre la page interactive.
L'hydration est fondamentale pour les frameworks basés sur SSR. C'est aussi le coût primaire de SSR — une hydration lourde est la cause principale d'un mauvais INP.
La séquence d'hydration
- Serveur rend HTML et envoie au navigateur
- Navigateur affiche HTML
- Navigateur télécharge bundle JS
- JS parse + exécute
- JS parcourt DOM existant, match elements aux components
- JS attache event handlers, initialise state
- Page est maintenant réellement interactive
Pourquoi l'hydration est lente
- Component tree entier re-exécute.
- Taille bundle JS.
- Synchrone sur main thread.
- Compétition ressources.
- Cold starts sur devices lents.
Solutions modernes au coût hydration
| Technique | Comment ça fonctionne | Utilisé par |
|---|---|---|
| Hydration partielle | Hydrater seulement les components marqués interactifs | Astro Islands |
| Streaming SSR | Serveur stream chunks HTML | React 18+, Next.js |
| Hydration progressive | Hydrater à l'entrée du viewport | RSC, Astro |
| Resumability (Qwik) | Skip hydration ; lazy-load handlers | Qwik |
| React Server Components | Components tournent seulement server-side | Next.js App Router |
| Hydration sélective | Hydrater partie user interactionne en premier | React 18+ |
Hydration vs no-hydration approaches
| Approach | Coût JS | Interactivité |
|---|---|---|
| SPA (CSR) | Tout JS upfront | Interactif après load JS |
| SSR + hydration | JS complet sur chaque page | Visible rapide, interactif après hydration |
| SSG (no JS) | Zéro JS | Statique |
| Hydration partielle | Seulement components interactifs | Mostly statique, islands interactifs |
| Resumability | ~No JS upfront | Visible + cliquable immédiatement |
Problèmes hydration courants
Mismatch hydration
HTML server-rendered diffère de l'output client-rendered.
Hydration lente sur pages lourdes
Pages avec milliers de components hydratent lentement.
Hydration bloquant input utilisateur
Utilisateur clique bouton pendant que l'hydration tourne.
Best practices hydration
- Minimiser JS shipped.
- Utiliser hydration partielle.
- Éviter mismatches SSR/CSR.
- Stream HTML.
- Différer hydration non-critique.
- Tester sur devices réels.
- Considérer zero-JS pour pages contenu.
- Monitor INP en production.
Pièges hydration courants
- Mismatches hydration en dev.
- Références window pendant render.
- IDs random.
- Init lourd state global.
- Gros component trees sur chaque route.
- Scripts third-party synchrones.
- Oublier de tester sur devices lents.
FAQ : Hydration
Pourquoi l'hydration est-elle nécessaire ?
SSR envoie du HTML statique pour premier paint rapide. L'hydration ajoute la couche JS.
Combien de temps devrait prendre l'hydration ?
< 100ms sur device rapide, < 300ms sur mobile mid-tier.
Différence entre hydration et rendering ?
Rendering : produire HTML. Hydration : attacher JS au HTML existant.
Qu'est-ce que "React hydration" ?
ReactDOM.hydrateRoot() parcourt le DOM server-rendered.
Puis-je éviter l'hydration entièrement ?
Pour pages sans interactivité : oui. Pour interactives : via Qwik ou partial hydration.
Qu'est-ce que React Server Components ?
Components qui tournent seulement sur le serveur.
L'hydration affecte-t-elle le SEO ?
Indirectement — via Core Web Vitals (INP, LCP).
Testez le coût hydration avec LoadFocus
LoadFocus exécute des audits Lighthouse depuis 25+ régions, mesurant INP et Total Blocking Time. Inscrivez-vous sur loadfocus.com/signup.
Outils LoadFocus connexes
Mettez ce concept en pratique avec LoadFocus — la plateforme même qui propulse tout ce que vous venez de lire.