Qu’est-ce que l’hydratation

L’hydratation est le processus par lequel l’application Angular côté client réutilise le HTML rendu par le serveur, en ajoutant les écouteurs d’événements et l’état au DOM existant au lieu de le supprimer et de le rendre à nouveau.

Le SSR ancien utilisait une hydratation destructive : le client supprimait le DOM du serveur et effectuait un nouveau rendu depuis zéro. Cela provoquait un scintillement visible et annulait le travail du serveur.

Angular moderne effectue une hydratation non destructive : il parcourt le DOM existant, le fait correspondre à l’arbre des composants et réutilise les nœuds. Il n’y a pas de scintillement, le travail est réduit et les performances sont meilleures.

La réutilisation du HTML du serveur permet de conserver affiché le contenu principal, ce qui aide le LCP, et évite les décalages de mise en page dus à un nouveau rendu, ce qui aide le CLS. L’application devient interactive sans être redessinée.

Première phase : le serveur génère le HTML et l’envoie. Deuxième phase : le navigateur télécharge le JS, démarre Angular et hydrate le balisage existant afin de le rendre interactif.

L’hydratation suppose que l’arbre des composants côté client produit la même structure que celle générée par le serveur. En cas de divergence, Angular signale une incompatibilité d’hydratation.

La manipulation directe du DOM, les branches réservées au navigateur qui modifient le balisage, l’imbrication HTML invalide et le contenu non déterministe (comme Math.random() ou Date.now() dans les modèles) provoquent des incompatibilités.

Ne manipulez pas le DOM de manière impérative (par exemple avec innerHTML en dehors d’Angular) pendant le SSR. Laissez Angular gérer le DOM afin que le client et le serveur restent cohérents.

Pour un composant qui ne peut réellement pas être hydraté, par exemple un composant tiers qui modifie le DOM, désactivez l’hydratation avec ngSkipHydration ; Angular effectuera à nouveau le rendu de ce seul sous-arbre.

L’hydratation ne s’applique que lorsqu’il existe du HTML rendu côté serveur à réutiliser. Une application purement en CSR n’a rien à hydrater ; l’hydratation constitue la partie cliente de SSR.

L’hydratation peut être complète (toute l’application est hydratée au chargement) ou incrémentale (certaines parties sont hydratées à la demande). Le choix de la bonne stratégie est essentiel pour les performances et sera abordé dans les prochaines leçons.

Vérifiez votre compréhension de l’hydratation.

L’hydratation réutilise le HTML du serveur côté client sans le remplacer de manière destructive, ce qui améliore LCP et CLS. Les incohérences proviennent de modifications manuelles du DOM ou d’un balisage non déterministe ; utilisez ngSkipHydration comme solution de contournement. L’hydratation constitue la partie cliente de SSR.