Islands Architecture

目次

• 使用場面
• 手順
• 詳細
• 出典

使用場面

• 静的コンテンツが主体で、わずかなインタラクティビティが必要なサイト（ブログ、製品ページ、ニュースサイト）に使用してください
• クライアントに送信する JavaScript の量を削減したい場合に役立ちます
• SEO と高速な初回ページロードが優先事項であり、同時に選択的なインタラクティビティが必要な場合に使用してください

手順

• 各ページの静的領域と動的領域を分けて特定する
• Islands Architecture をサポートする Astro、Marko、Eleventy などのフレームワークを使用する
• client:visible などのディレクティブを使用して、インタラクティブなコンポーネントを独立して hydrate する
• ページの大部分を、JavaScript コストがゼロの静的 HTML として保つ

詳細

過剰な JavaScript の読み込みと処理はパフォーマンスに悪影響を及ぼします。しかし、主に静的なウェブサイトであっても、ある程度のインタラクティビティと JavaScript は必要なことが多くあります。私たちは静的レンダリングの様々なバリエーションについて論じてきました。これらは以下のバランスを取ろうとするアプリケーション構築を可能にします：

1. クライアント側レンダリング (CSR) アプリケーションに匹敵するインタラクティビティ
2. SSR アプリケーションと同等の SEO の利点

SSR の基本原則は、HTML がサーバーで レンダリングされ、クライアント側でそれを rehydrate するために必要な JavaScript とともに配信されることです。Rehydration は、サーバーがレンダリング後、クライアント側で UI コンポーネントの状態を再生成するプロセスです。Rehydration にはコストがかかるため、SSR の各バリエーションは rehydration プロセスの最適化を試みます。これは主に重要なコンポーネントの部分的な hydration またはレンダリング時のコンポーネントストリーミングによって達成されます。ただし、上記の手法で最終的に配信される JavaScript の総量は同じままです。

Islands Architecture という用語は Katie Sylor-Miller と Jason Miller によって普及し、それ以外は静的な HTML の上に独立して配信できる「islands」のインタラクティビティを通じて、配信される JavaScript の量を減らすことを目的としたパラダイムを説明しています。Islands はコンポーネントベースのアーキテクチャであり、静的島と動的島を持つページの区分化されたビューを提案します。ページの静的領域は純粋な非インタラクティブな HTML であり、hydration を必要としません。動的領域は HTML とスクリプトの組み合わせで、レンダリング後に自身を rehydrate することができます。

動的コンポーネントの島

ほとんどのページは静的コンテンツと動的コンテンツの組み合わせです。通常、ページは静的コンテンツと、分離できるインタラクティブな領域が少しで構成されています。例えば：

1. ブログ記事、ニュース記事、組織のホームページは、テキストと画像を含み、ソーシャルメディア埋め込みやチャットなどのインタラクティブコンポーネントを備えています。
2. e コマース サイトの製品ページは、静的な製品説明とアプリの他のページへのリンクを含みます。画像カルーセルと検索などのインタラクティブコンポーネントはページの異なる領域で利用可能です。
3. 典型的な銀行口座詳細ページは、静的なトランザクションのリストと、いくつかのインタラクティビティを提供するフィルタを含みます。

静的コンテンツはステートレス、イベントを発火しない、レンダリング後に rehydration を必要としません。レンダリング後、動的コンテンツ（ボタン、フィルタ、検索バー）はそのイベントに再接続される必要があります。DOM はクライアント側で再生成される必要があります（仮想 DOM）。この再生成、rehydration、イベント処理機能がクライアントに送信される JavaScript に寄与します。

Islands Architecture は、すべての静的コンテンツを含むページのサーバー側レンダリングを促進します。ただし、この場合、レンダリングされた HTML には動的コンテンツのプレースホルダが含まれます。動的コンテンツプレースホルダは自己完結型のコンポーネントウィジェットを含みます。各ウィジェットはアプリのようなもので、サーバーレンダリング出力と、クライアント側でアプリを hydrate するために使用される JavaScript を組み合わせます。

プログレッシブ hydration では、ページの hydration アーキテクチャはトップダウンです。ページは個々のコンポーネントのスケジューリングと hydration を制御します。Islands Architecture では各コンポーネントは独自の hydration スクリプトを持ち、ページ上の他のスクリプトとは独立して非同期で実行されます。1 つのコンポーネントのパフォーマンス問題は他のコンポーネントに影響しません。

Islands の実装

Island Architecture はさまざまなソースから概念を借用し、それらを最適に組み合わせることを目的としています。Jekyll や Hugo などのテンプレートベースの静的サイトジェネレータは、ページへの静的コンポーネントのレンダリングをサポートしています。ほとんどの最新 JavaScript フレームワークは isomorphic rendering もサポートしており、サーバーとクライアントで同じコードを使用して要素をレンダリングできます。

Jason のポストは、コンポーネントを hydrate するためのスケジューリング アプローチを実装するために requestIdleCallback() の使用を提案しています。静的 isomorphic rendering とコンポーネント レベルの部分的な hydration のスケジューリングはフレームワークに組み込むことができ、Islands Architecture をサポートします。したがって、フレームワークは以下をサポートすべきです：

1. JavaScript がゼロのサーバーでのページの静的レンダリング。
2. 静的コンテンツのプレースホルダを通じた独立した動的コンポーネントの埋め込み。各動的コンポーネントはそのスクリプトを含み、メインスレッドが空き次第 requestIdleCallback() を使用して自身を hydrate できます。
3. サーバーでのコンポーネントの isomorphic rendering と、両端で同じコンポーネントを認識するためのクライアントでの hydration を許可します。

フレームワーク

今日、異なるフレームワークが Islands Architecture をサポートすることができます。その中で注目されるものは：

1. Marko: Marko は eBay が開発・保守しているオープンソースフレームワークで、サーバーレンダリングパフォーマンスを改善します。ストリーミングレンダリングと自動的な部分的 hydration を組み合わせることで Islands Architecture をサポートしています。HTML およびその他の静的アセットは、準備ができ次第クライアントにストリーミングされます。自動的な部分的 hydration により、インタラクティブコンポーネントは自身を hydrate できます。Hydration コードはインタラクティブコンポーネントのみに配信され、ブラウザの状態を変更できます。Isomorphic であり、Marko コンパイラは実行される場所（クライアントまたはサーバー）に応じて最適化されたコードを生成します。

2. Astro: Astro は React、Preact、Svelte、Vue などの他のフレームワークで構築された UI コンポーネントから軽量な静的 HTML ページを生成できる静的サイトビルダーです。クライアント側の JavaScript が必要なコンポーネントは、その依存関係とともに個別に読み込まれます。したがって、組み込みの部分的 hydration を提供します。Astro は、表示されるタイミングに応じてコンポーネントを遅延ロードすることもできます。

3. Eleventy + Preact: Markus Oberlehner は、Eleventy（静的サイトジェネレータ）と、部分的に hydrate できる isomorphic Preact コンポーネントの使用を実証しています。遅延 hydration もサポートしています。コンポーネント自体は、そのコンポーネントの hydration を宣言的に制御します。インタラクティブコンポーネントは WithHydration ラッパーを使用して、クライアント側で hydrate されます。

Marko と Eleventy は Jason が提供した Islands の定義より前に存在しますが、それをサポートするために必要な機能のいくつかを含んでいます。しかし、Astro はこの定義に基づいて構築されており、Islands Architecture を本来的にサポートしています。

サンプル実装

以下は Astro を使用して実装されたサンプルブログページです。ページ SamplePost は 1 つのインタラクティブコンポーネント SocialButtons をインポートしています。このコンポーネントはマークアップを通じて必要な位置で HTML に含まれます。

// Component Imports
import { SocialButtons } from '../../components/SocialButtons.js';

<html lang="en">
 <head>
   <link rel="stylesheet" href="/blog.css" />
 </head>

 <body>
   <div class="layout">
     <article class="content">
       <section class="intro">
         <h1 class="title">Post title (static)</h1>
         <br/>
         <p>Post sub-title (static)</p>
       </section>
       <section class="intro">
           <p>This is the post content with images that is rendered by the server.</p>
           <p>The next section contains the interactive social buttons component which includes its script.</p>
       </section>
       <section class="social">
           <div>
           <SocialButtons client:visible></SocialButtons>
           </div>
       </section>
     </article>
   </div>
 </body>
</html>

// SocialButtons.js
import { useState } from "preact/hooks";

export function SocialButtons() {
  const [count, setCount] = useState(0);
  const add = () => setCount((i) => i + 1);
  const subtract = () => setCount((i) => i - 1);
  return (
    <>
      <div>{count} people liked this post</div>
      <div align="right">
        <button onclick={add}>Like</button>
        <button onclick={subtract}>Unlike</button>
      </div>
    </>
  );
}

SocialButtons コンポーネントは、その HTML と対応するイベントハンドラを含む Preact コンポーネントです。

コンポーネントは実行時にページに埋め込まれ、クライアント側で hydrate されるため、クリックイベントが必要に応じて機能します。

Astro は HTML、CSS、スクリプト間のクリーンな分離を可能にし、コンポーネントベースの設計を推奨しています。このフレームワークでサイト構築を簡単に開始できます。

長所と短所

Islands Architecture は、サーバー側レンダリング、静的サイト生成、部分的 hydration などのさまざまなレンダリング手法から考え方を組み合わせています。islands を実装することの潜在的な利点のいくつかは以下の通りです。

1. パフォーマンス: クライアントに送信される JavaScript コードの量を削減します。送信されるコードは、インタラクティブコンポーネントに必要なスクリプトのみで構成され、ページ全体の仮想 DOM を再作成し、ページ上のすべての要素を rehydrate するために必要なスクリプトよりはるかに少ないです。JavaScript のサイズが小さいほど、自動的にページロードが高速化され、Time to Interactive (TTI) が改善されます。

2. SEO: すべての静的コンテンツはサーバー側でレンダリングされるため、ページは SEO フレンドリーです。

3. 重要なコンテンツの優先順位付け: キーコンテンツ（特にブログ、ニュース記事、製品ページの場合）はほぼすぐにユーザーが利用できます。インタラクティビティのための機能はキーコンテンツの利用後に必要となり、段階的に利用可能になります。

4. アクセシビリティ: 標準的な静的 HTML リンクを使用して他のページにアクセスすることは、ウェブサイトのアクセシビリティの向上に役立ちます。

5. コンポーネントベース: このアーキテクチャは、再利用性と保守性などのコンポーネントベースのアーキテクチャのすべての利点を提供します。

利点にもかかわらず、この概念はまだ初期段階にあります。サポートが限定されているため、いくつかの欠点があります。

1. 開発者が Islands を実装するために利用可能な唯一の選択肢は、利用可能ないくつかのフレームワークのいずれかを使用するか、アーキテクチャを自分で開発することです。既存のサイトを Astro または Marko に移行するには、追加の努力が必要になります。
2. Jason の初期ポストの他に、このアイデアについては議論がほとんどありません。
3. 新しいフレームワークは Islands Architecture をサポートすることを主張しており、どれがあなたに適しているのかをフィルタリングするのが困難です。
4. このアーキテクチャはソーシャルメディアアプリなどの非常にインタラクティブなページには適していません。それらはおそらく数千の islands を必要とします。

Islands Architecture の概念は比較的新しいですが、パフォーマンスの利点のために速度を上げる可能性が高いです。これは静的コンテンツをレンダリングするために SSR を使用しながら、ページのパフォーマンスに最小限の影響を持つ動的コンポーネントを通じたインタラクティビティをサポートすることを強調しています。この分野により多くのプレイヤーが登場し、より広い選択肢の実装オプションが利用可能になることを期待しています。

出典

• patterns.dev/vanilla/islands-architecture

参考資料

• Islands Architecture
• Is 0KB of JavaScript in your future
• Modernizing Etsy's codebase with React