ハイドレーションとは

ハイドレーションとは、クライアント側のAngularアプリがサーバーレンダリング済みのHTMLを再利用し、既存のDOMを破棄して再度レンダリングするのではなく、そこにイベントリスナーと状態を結び付ける処理です。

従来のSSRでは、破壊的なハイドレーションが使われていました。クライアントがサーバーのDOMを消去し、最初から再レンダリングしていたため、目に見えるちらつきが発生し、サーバーの処理結果も破棄されていました。

最新のAngularは非破壊的なハイドレーションを実行します。既存のDOMを走査してコンポーネントツリーと照合し、ノードを再利用します。ちらつきがなくなり、処理量が減ってパフォーマンスが向上します。

サーバーのHTMLを再利用すると、最大のコンテンツが描画された状態を保てるため、LCP の改善につながります。また、再レンダリングによるレイアウトシフトを避けられるため、CLS にも役立ちます。再描画せずにアプリを操作可能にできます。

第1段階では、サーバーがHTMLをレンダリングして送信します。第2段階では、ブラウザーがJavaScriptをダウンロードし、Angularを起動して既存のマークアップをハイドレーションし、操作可能にします。

ハイドレーションでは、クライアントのコンポーネントツリーがサーバーと同じ構造を生成することが前提になります。異なる場合、Angularはハイドレーションの不一致を報告します。

DOMの直接操作、マークアップを変更するブラウザー専用の分岐、無効なHTMLの入れ子、Math.random() やテンプレート内の Date.now() のような非決定的なコンテンツが不一致の原因になります。

SSR中に命令型でDOMを操作しないでください（たとえばAngularの外部で innerHTML を使用するなど）。AngularにDOMの管理を任せ、クライアントとサーバーの内容が一致するようにします。

DOMを変更するサードパーティ製ウィジェットなど、どうしてもハイドレーションできないコンポーネントには、ngSkipHydration を使って対象外にできます。Angularはそのサブツリーだけを再レンダリングします。

Hydration は、再利用するサーバーレンダリング済み HTML がある場合にのみ適用されます。純粋な CSR アプリには hydration の対象がありません。hydration は SSR の仕組みにおけるクライアント側の処理です。

Hydration には、完全（アプリ全体を読み込み時に hydration）と段階的（必要に応じて一部を hydration）の2種類があります。パフォーマンスに適した戦略を選ぶことが重要です。詳しくは後のレッスンで扱います。

Hydration についての理解度を確認しましょう。

Hydration は、サーバーの HTML をクライアント側で破壊せずに再利用し、LCP と CLS を改善します。ミスマッチは、手動による DOM の編集や非決定的なマークアップによって発生します。回避策として ngSkipHydration を使用できます。Hydration は SSR の仕組みにおけるクライアント側の処理です。