
Partial Hydration(部分的ハイドレーション)は、SSR/SSGで返した静的HTMLのうち、ページ全体ではなく一部のコンポーネントだけをHydrateしてインタラクティブ化する技法の総称です。従来のHydrationが「ページの全コンポーネントをまとめて起こす」のに対し、Partial Hydrationは「対話が必要な部分だけ起こす」という発想で、JSの実行コストを大幅に下げます。Preactチームのジェイソン・ミラー氏が2020年の記事で詳説し、AstroやFresh、Marko 6で具体的実装が広まりました。
この記事の目次
- Partial Hydrationの仕組み
- Partial Hydrationが効くパターン
- Partial Hydrationを支える3つの戦略
- 全体Hydrationとの違い
- まとめ
Partial Hydrationの仕組み

Partial Hydrationの動作は4段階で説明できます。1段階目はサーバが完成HTMLをブラウザに返すところまでで、これは通常のSSR/SSGと同じです。2段階目では、フレームワークがHTMLに埋め込んだマーカー(data-hydrate属性やカスタム要素など)を読み取り、「Hydrationが必要なコンポーネント」だけを識別します。対話を含まない見出し・段落・画像は対象から外れ、サーバHTMLそのままの状態で残ります。
3段階目は、識別された各コンポーネント専用のJavaScript片を別便でダウンロードする処理です。従来のフルHydrationが「ページ全体のJSを1つの大きなバンドル」で送るのに対し、Partial Hydrationでは島ごと・コンポーネントごとに小さなチャンクを送ります。4段階目で、そのJSが該当DOMサブツリーに対してのみHydrateを実行し、ボタンやフォームが動き始めます。「初回JSが軽い」「コンポーネント単位で失敗が局所化される」という二つの大きな利点が生まれます。
Partial Hydrationが効くパターン

Partial Hydrationが特に効くのは、ページの大部分が静的で、対話要素が局所的なケースです。ブログ記事のヘッダ・本文・フッタは静的HTMLのままで配信し、コメント欄や「いいねボタン」だけJSで動かせば、ユーザーは記事を読み始めるのに重いHydrationを待つ必要がなくなります。ECの商品詳細でも、説明文・スペック表・画像は静的、カート追加ボタンと在庫表示だけ動的、という構成にできます。
Below the Fold(スクロールしないと見えない領域)の遅延起動も典型的なパターンです。Intersection Observerで可視判定を行い、ユーザーがその要素に近付いたタイミングで初めてJSを評価する設計は、Astroでclient:visible、Vue/NuxtでLazyHydrationプラグインなどとして提供されています。実験的UIの段階導入(A/Bテストの片側だけJS化、新機能フラグごとのHydrate)にも使え、全画面の挙動を変えずに局所的な改善を試せるため、運用フェーズでのリスク管理にも向いています。
Partial Hydrationを支える3つの戦略

Partial Hydrationを実装する上での核は3つの戦略です。1つ目は「選択」で、どのコンポーネントを対話化するかを明示的に宣言する仕組みです。Astroのclient:* ディレクティブ、Marko 6のreactiveマーカー、Reactの'use client'などがその役割を担い、デフォルトは静的、明示した部分だけ動的という安全側の方針が採用されています。
2つ目は「分割」で、選択された各コンポーネントを独立したJSバンドルに分けて配信することです。ViteやRollupのコード分割機能と組み合わせ、コンポーネント単位でチャンクを生成します。3つ目は「遅延」で、いつそのバンドルを評価するかをコントロールします。ページ読込直後(client:load)、メインスレッドが空いてから(client:idle)、画面に入ったら(client:visible)など、起動タイミングを使い分けることでTTIへの影響を最小化します。選択・分割・遅延の三位一体で、Partial Hydrationの実効性が生まれます。
全体Hydrationとの違い

Partial Hydrationと従来のフルHydrationの差は、対象範囲とパフォーマンス特性の両方に現れます。フルHydrationでは、ページの全コンポーネントをまとめてJSで起こすため実装はシンプルですが、数百KB単位のバンドルが評価される間、画面が見えても操作できない時間が長く続きます。Partial Hydrationは選択した一部だけを起こすため、初回JSのサイズが小さく、TTIが大幅に短縮されます。
代わりにPartial Hydrationでは「どこを対話化するか」を開発者が宣言する必要があり、コンポーネント設計に若干の手間がかかります。とはいえAstroやNext.jsのApp Router、Marko 6など主要フレームワークがこの宣言を一級市民として扱うため、学習コストは数日程度で済むレベルです。Core Web Vitalsを重視する現代のWeb開発では「フルHydrationよりPartial Hydrationを基本にする」というガイドラインが定着しつつあり、Server ComponentsやIslands Architectureと組み合わせて使われるのが標準的になっています。
まとめ
Partial Hydrationは「ページ全体ではなく必要部分だけJS化する」中間アプローチで、JS配信量とTTIを劇的に減らせる現代Webの定石技法です。Astro・Marko 6・Next.js App RouterなどがIslandsやServer Componentsとあわせて実装を整え、選択・分割・遅延の3戦略を組み合わせることでコンテンツ中心サイトの体感速度を大きく改善できます。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。

コメント