Définition technique
Phase où React « reprend la main » sur du HTML déjà rendu côté serveur (SSR ou SSG) : il attache les écouteurs d'événements et rend les composants interactifs. Sans hydratation correcte, le contenu s'affiche puis « clignote » ou ne répond pas aux clics. Une hydratation lente ou désynchronisée (contenu serveur ≠ client) dégrade l'expérience et les Core Web Vitals (INP). Les frameworks comme Next.js gèrent l'hydratation ; les erreurs viennent souvent de contenu dynamique (date, random) ou de scripts tiers qui modifient le DOM avant l'hydratation.
Comment ça fonctionne ?
Le serveur envoie du HTML pré-rendu. Le JavaScript React se charge, lit le DOM existant et « s'y attache » : il associe chaque nœud à un composant React et attache les événements. Si le DOM a été modifié entre-temps (par un script ou une donnée différente), React peut signaler un mismatch. L'hydratation se fait en général après le First Contentful Paint.
L'erreur classique à éviter
Générer du contenu différent côté serveur et client (Date.now(), Math.random(), accès à window). Inclure des scripts tiers qui modifient le DOM avant l'hydratation. Ne pas résoudre les warnings de mismatch en développement.
Impact business : pourquoi s'en soucier ?
Un site qui clignote ou dont les boutons ne réagissent pas tout de suite donne une impression de site « cassé » ou lent. Les utilisateurs quittent et Google pénalise l'expérience. Comprendre l'hydratation permet d'éviter les bugs subtils après déploiement et d'optimiser le chargement des composants interactifs (lazy hydration, islands).
La règle d'or
Garantir que le rendu serveur et client produisent le même HTML pour une même donnée. Utiliser useEffect pour le code dépendant du navigateur. Tester en production-like (build) pour détecter les mismatches.