Progressive Hydration

サーバーレンダリングされたアプリケーションは、サーバーを使用して現在のナビゲーション用の HTML を生成します。サーバーが HTML コンテンツの生成を完了すると、静的な UI を正しく表示するために必要な CSS と JSON データも含まれたデータをクライアントに送信します。サーバーがマークアップを生成してくれるため、クライアントはこれを素早く解析して画面に表示できます。その結果、高速な First Contentful Paint が実現します！

サーバーレンダリングは高速な First Contentful Paint を提供しますが、常に高速な Time To Interactive を保証するわけではありません。ウェブサイトと相互作用するために必要な JavaScript はまだ読み込まれていません。ボタンは相互作用できるように見えるかもしれませんが、実際にはまだ相互作用できません。ハンドラは JavaScript バンドルが読み込まれて処理された後に初めてアタッチされます。このプロセスは hydration と呼ばれています。React は現在の DOM ノードをチェックし、対応する JavaScript でノードをハイドレーションします。

使用時期

• SSR アプリケーションに、すぐに相互作用が必要でない非重要なセクションがある場合に使用してください
• 初期読み込み時にページを相互作用可能にするために必要な JavaScript を削減するのに役立ちます

使用しない時期

• ページ全体が相互作用的で、すべてのコンポーネントが即座にハイドレーションが必要な場合
• ハイドレーション境界を管理する複雑さがパフォーマンス利得を上回る場合
• 総 JavaScript 量が既に最小限で、ハイドレーションが高速なページの場合

手順

• 非重要なコンポーネントを <Suspense> 境界でラップし、適切なフォールバックを提供してください
• React.lazy() とコード分割を使用して、ビューポート下部またはほとんど使用されないコンポーネントの読み込みを遅延させてください
• React 18+ では、ユーザーが相互作用した領域を自動的に優先する選択的ハイドレーションを活用してください
• Next.js では next/dynamic を { ssr: false } とともに使用して、真のクライアント専用ウィジェットを実装してください

詳細

ユーザーが画面上で相互作用できない UI を見ている時間は、不気味な谷としても参照されます。ユーザーはウェブサイトと相互作用できると思うかもしれませんが、コンポーネントにはまだハンドラがアタッチされていません。UI が凍結しているように見えるかもしれないため、これはユーザーにとって不満足な体験になる可能性があります！

サーバーから受け取った DOM コンポーネントが完全にハイドレーションされるまでに時間がかかることがあります。コンポーネントをハイドレーションする前に、JavaScript ファイルを読み込み、処理、実行する必要があります。前に行ったようにアプリケーション全体を一度にハイドレーションするのではなく、DOM ノードを プログレッシブにハイドレーション することもできます。プログレッシブハイドレーションは、ノードを時系列で個別にハイドレーションすることを可能にし、必要最小限の JavaScript のみを要求することを可能にします。

アプリケーションをプログレッシブにハイドレーションすることで、ページの重要度が低い部分のハイドレーションを遅延させることができます。このようにして、ページを相互作用可能にするために要求しなければならない JavaScript の量を削減でき、ユーザーがそれを必要とするときにのみノードをハイドレーションします。プログレッシブハイドレーションは、サーバーレンダリングされた DOM ツリーが破棄されてすぐに再構築される最も一般的な SSR Rehydration の落とし穴を回避するのにも役立ちます。

プログレッシブハイドレーションにより、特定の条件（例えば、コンポーネントがビューポートに表示されている場合）に基づいてコンポーネントのみをハイドレーションできます。

プログレッシブハイドレーション実装

React での SSR 実装に関するセクションでは、サーバーでレンダリングされるアプリケーションのクライアント側ハイドレーションについて説明しました。ハイドレーションにより、クライアント側の React はサーバーでレンダリングされた ReactDOM コンポーネントを認識し、これらのコンポーネントにイベントをアタッチできます。したがって、SSR アプリケーションがクライアントで利用可能になったら、CSR アプリケーションのように機能するための継続性とシームレスさをもたらします。

ページ上のすべてのコンポーネントをハイドレーションを通じて相互作用可能にするには、これらのコンポーネントの React コードをクライアントにダウンロードされるバンドルに含める必要があります。JavaScript によって大規模に制御される非常に相互作用的な SPA は、一度にバンドル全体が必要になります。ただし、画面上に数個の相互作用要素を持つほぼ静的なウェブサイトは、すべてのコンポーネントが即座にアクティブになる必要はありません。このようなウェブサイトでは、画面上の各コンポーネントに対して巨大な React バンドルを送信することはオーバーヘッドになります。

プログレッシブハイドレーションは、ページ読み込み時にアプリケーションの特定の部分のみをハイドレーションすることを可能にすることでこの問題を解決します。他の部分は必要に応じて段階的にハイドレーションされます。

アプリケーション全体を一度に初期化するのではなく、ハイドレーション ステップは DOM ツリーのルートから始まりますが、サーバーレンダリングされたアプリケーションの個々の部分は一定の期間にわたってアクティブ化されます。ハイドレーション プロセスは様々なブランチに対して停止され、後でビューポートに入ったときや他のトリガーに基づいて再開される可能性があります。各ハイドレーションを実行するために必要なリソースの読み込みも、コード分割テクニックを使用して遅延されるため、ページを相互作用可能にするために必要な JavaScript の量を削減します。

プログレッシブハイドレーションの背景にある考えは、アプリケーションをチャンク単位でアクティブ化することで優れたパフォーマンスを提供することです。プログレッシブハイドレーション ソリューションは、全体的なユーザー体験にどのように影響するかも考慮する必要があります。包括的なプログレッシブハイドレーション実装の要件は以下の通りです。

1. すべてのコンポーネントに対する SSR の使用を許可します。
2. コードを個々のコンポーネントまたはチャンクに分割することをサポートします。
3. これらのチャンクのクライアント側ハイドレーションを開発者定義シーケンスでサポートします。
4. 既にハイドレーションされているチャンクでユーザー入力をブロックしません。
5. 遅延ハイドレーション用チャンクに対するローディングインジケーターの使用を許可します。

React concurrent mode は、すべてで利用可能になったら、これらすべての要件に対応します。React が複数のタスクを同時に処理し、与えられた優先度に基づいてそれらを切り替えることを可能にします。切り替え時に、部分的にレンダリングされたツリーをコミットする必要はないため、React が同じタスクに戻ったら、レンダリング タスクを続行できます。

Concurrent mode を使用してプログレッシブハイドレーションを実装できます。この場合、ページ上の各チャンクのハイドレーションは、React concurrent mode のタスクになります。ユーザー入力のような高優先度タスクを実行する必要がある場合、React はハイドレーション タスクを一時停止して、ユーザー入力を受け入れるに切り替えます。lazy()、Suspense() のような機能により、宣言的なローディング状態を使用できます。これらを使用して、チャンクが遅延読み込みされている間にローディングインジケーターを表示できます。SuspenseList() を使用して、遅延読み込みコンポーネントの優先度を定義できます。

React concurrent mode は、別の React 機能と組み合わせることもできます。

• Server Components。これにより、サーバーからコンポーネントを再フェッチして、フェッチ全体の完了を待つのではなく、ストリーミング時にクライアントでレンダリングできます。したがって、クライアントの CPU はネットワーク フェッチの完了を待つ間にも機能します。

プログレッシブハイドレーションの複数の実装が利用可能です。Preact と Next.js を使用した部分的ハイドレーションの POC は以下を使用します。

1. pool-attendant-preact: Preact x で部分的ハイドレーションを実装するライブラリ。
2. next-super-performance: このライブラリを使用してクライアント側パフォーマンスを改善する Next.js プラグイン。

pool-attendant-preact ライブラリには、より相互作用的なコンポーネントをハイドレーション用にマークできる withHydration という API が含まれています。これらが最初にハイドレーションされます。

import Teaser from "./teaser";
import { withHydration } from "next-super-performance";

const HydratedTeaser = withHydration(Teaser);

export default function Body() {
  return (
    <main>
      <Teaser column={1} />
      <HydratedTeaser column={2} />
      <HydratedTeaser column={3} />

      <Teaser column={1} />
      <Teaser column={2} />
      <Teaser column={3} />

      <Teaser column={1} />
      <Teaser column={2} />
      <Teaser column={3} />
    </main>
  );
}

コンポーネント HydratedTeaser は列 2 および 3 でまず最初にハイドレーションされます。hydrate() API を使用してクライアント上の残りのコンポーネントをハイドレーションできるようになりました。

import { hydrate } from "next-super-performance";
import Teaser from "./components/teaser";

hydrate([Teaser]);

利点と欠点

プログレッシブハイドレーションは、ハイドレーションのコストを最小化しながら、サーバー側レンダリングとクライアント側ハイドレーションを提供します。

1. コード分割を促進: コード分割はプログレッシブハイドレーションの不可欠な部分です。なぜなら、遅延読み込みされる個々のコンポーネント用のコードチャンクを作成する必要があるからです。

2. ページのあまり使用されない部分のオンデマンド読み込みを許可: ページには、ほぼ静的で、ビューポートの外にあり、または非常にあまり必要ないコンポーネントがある可能性があります。このようなコンポーネントは遅延読み込みの理想的な候補です。

3. バンドルサイズを削減: コード分割は自動的にバンドルサイズの削減をもたらします。読み込み時に実行するコードが少ないと、FCP と TTI の間の時間削減に役立ちます。

欠点として、プログレッシブハイドレーションは、画面上のすべての要素がユーザーに利用可能で、読み込み時にすぐに相互作用可能にする必要がある動的アプリケーションには適さない場合があります。これは、開発者がユーザーがどこを最初にクリックする可能性があるかを知らない場合、どのコンポーネントを最初にハイドレーションするかを特定できない可能性があるためです。

出典

• patterns.dev/react/progressive-hydration