アイランドアーキテクチャと部分ハイドレーション

なぜアイランド構成が必要になったのか

SPA/SSR/SSG のいずれを選んでも、サーバーで生成したHTMLをクライアントで「意味のある操作対象」に変える工程が要ります。これがハイドレーションです。従来型のSSRフレームワークは、ページ全体を1本のコンポーネントツリーとして扱い、サーバーが返したHTMLに対してクライアント側で同じツリーをもう一度構築し、仮想DOMを実HTMLへ突き合わせてイベントリスナーを結線します。

問題は、このハイドレーションがページ内の1要素でも動的な部分があれば、ツリー全体に対して発生することです。ブログ記事の「いいねボタン」1個のためだけに、記事本文・ナビゲーション・フッターまで含めた巨大なJSバンドルをダウンロードし、パースし、実行しなければなりません。静的な文字だけの部分にまでハイドレーションコストを払う――これがモノリシックなSSRの構造的な無駄です。

アイランドアーキテクチャは、この前提を覆します。ページの大部分は静的HTMLのままとし、インタラクティブな部分だけを独立した「島（island）」として個別にハイドレートするという構成です。

アイランドアーキテクチャの内部モデル

アイランド構成でのビルド・配信の流れは次のとおりです。

各島は互いに独立したコンポーネントツリーのルートであり、島同士でランタイムの状態やコンポーネントツリーを共有しません。したがって、ある島が壊れても別の島には波及せず、静的な地の文（ナビゲーション、記事本文、フッターなど）はそもそもJSに依存しないためハイドレーション不要です。この「静的な地」と「動く島」を明確に分離する発想は、Astroが採用するclient:ディレクティブ（client:load、client:visible、client:idleなど）に代表され、コンポーネント単位でハイドレーション方式を宣言的に指定します。

部分ハイドレーションによるJS削減の仕組み

アイランドアーキテクチャが「どこをハイドレートするか」を扱う手法だとすれば、**部分ハイドレーション（partial hydration）**は「いつハイドレートするか」を扱う手法です。両者はしばしばセットで語られますが、独立した軸です。

部分ハイドレーションの核心は、島ごとのハイドレーション実行をトリガー条件まで遅延させることにあります。代表的なトリガーは次のとおりです。

これらのトリガーは内部的にIntersection Observerやアイドルコールバック、イベントリスナーの遅延登録として実装されます。重要なのは、トリガーが発火するまでその島のJSはネットワーク上でリクエストすらされない設計になっている点です。単に実行を遅らせるだけでなく、コード分割（コードスプリッティング）と組み合わせることで、初期ロード時にダウンロードされるJSバイト数そのものを減らします。

// 概念的な例：可視化トリガーによる部分ハイドレーション
const island = document.querySelector('[data-island="comment-widget"]');
const observer = new IntersectionObserver(async (entries) => {
  for (const entry of entries) {
    if (entry.isIntersecting) {
      // ここで初めて島のJSチャンクを取得・実行する
      const { hydrate } = await import('./comment-widget.js');
      hydrate(entry.target);
      observer.unobserve(entry.target);
    }
  }
});
observer.observe(island);

この設計により、Core Web Vitals のうちTBT（Total Blocking Time）やINPに直結するメインスレッド占有時間を大きく削減できます。静的な地の文に対するJS実行コストがゼロになるため、記事本文が長いページほど効果が顕著です。ただし副作用として、defer/asyncと同様、島のスクリプト取得タイミングが遅延側に振れるほど「操作可能になるまでの遅延」がトレードオフとして生じます。トリガー選択は「初期表示速度」と「操作可能になるまでの体感遅延」のバランス設計です。

Resumability：ハイドレーションそのものを不要にする

部分ハイドレーションはJS実行の「量とタイミング」を最適化しますが、根本的な問題――サーバーで一度実行したロジックを、クライアントでもう一度実行してイベントを結線し直すという二重実行――は解消していません。この二重実行自体をなくす設計が、Qwikが採用する**Resumability（再開可能性）**です。

Resumabilityでは、サーバーがコンポーネントを実行した時点の実行状態（どのイベントリスナーがどの要素に紐づくか、クロージャが何を参照しているか等）をシリアライズしてHTML内に埋め込みます。クライアントは起動時にこの状態を「再実行して構築」するのではなく、そのまま読み取って再開します。たとえばボタンのクリックハンドラは、ページロード時には一切のJSも紐づけられていません。ユーザーが実際にクリックした瞬間、そのイベントに対応するハンドラのコードチャンクだけがネットワークから取得され実行されます。

これは部分ハイドレーションの「操作トリガー」をさらに突き詰め、コンポーネント単位ですらなくハンドラ単位まで遅延の粒度を細かくしたアプローチと理解できます。ハイドレーションという概念（サーバーの出力をクライアントで再構築する処理）自体が存在しないため、原理的には初期実行コストをアイランドアーキテクチャよりさらに切り詰められます。ただし、状態のシリアライズ量が増える、実行順序に依存するロジックの設計が難しくなるといった新たな制約も生じるため、万能な解決策ではなく設計思想の異なる選択肢です。

まとめ