HTML-first という選択肢 — Astro と Islands

サイトが遅い・操作がもたつく、その原因を掘り下げると、多くは「JavaScript の量と実行コスト」に行き着きます。Web Almanac 2025 では、メインスレッドがふさがる総量を示す TBT が前年比 58% 増。Web 全体で JavaScript が増え続けています。

問題は、その JavaScript の多くが「実は動かす必要のない部分」にまで載っていることです。会社案内の本文や見出しは、本来ただ表示されればよく、JavaScript で動かす理由はありません。それでも従来型の作り方では、ページ全体に JavaScript が行き渡ってしまいます。

ここから生まれた発想が「そもそも JavaScript をゼロから始め、必要な部分にだけ足す」というアプローチです。これが HTML-first であり、Islands Architecture の出発点です。

Islands Architecture（アイランド・アーキテクチャ）は、ページを「動かない静的な海」と「動く小さな島」に分けて考える設計の考え方です。土台になるのは、クライアント側で JavaScript を一切動かさない静的 HTML。これが海です。

その上に、検索ボックス・画像のカルーセル・開閉するメニューといった、インタラクティブな部分だけを「島」として配置します。島はそれぞれ独立して動き、島ごとに必要な JavaScript だけが読み込まれます。

従来型のように「ページ全体を JavaScript で組み立て直す」のではなく、「ほぼ完成した HTML に、動く部品だけを後から差し込む」。この切り分けによって、読み込む JavaScript の総量を構造的に小さく保てます。

Astro は、この Islands の発想を実際のサイト制作に落とし込むための Web フレームワークです。公式が掲げるスローガンが 「HTML-first, JavaScript when necessary」—「まず HTML、JavaScript は必要なときだけ」。

Astro でページを作ると、基本は静的 HTML として書き出されます。本文も見出しもレイアウトも、JavaScript を伴わない素の HTML です。そこにインタラクティブな部品を置きたいときだけ、その部品を「島」として明示的に指定します。

つまり Astro は「JavaScript を載せる」のではなく「載せないのが既定で、載せたいときに宣言する」設計です。デフォルトが軽い側にあるため、作っているうちに自然と JavaScript が膨らむ事故が起きにくくなります。

島に JavaScript を読み込ませて「動く状態」にすることを、ハイドレーション（hydration）と呼びます。Astro の特徴は、このハイドレーションのタイミングを島ごとに指定できることです。

指定は client:load（すぐ読み込む）、client:idle（ブラウザが手すきになってから）、client:visible（その島が画面に入ってから）など。たとえばページ下部のカルーセルは、スクロールして見えてから初めて JavaScript を読めば十分です。

この「いつ動かすか」を部品単位で決められることで、最初の表示に必要な JavaScript をさらに絞れます。すぐ必要なものだけ先に、後でいいものは後で。これがハイドレーション制御の実用的な価値です。

誠実にお伝えすると、Astro や Islands は中小企業サイトに必須のものではありません。動きの少ない会社案内やサービス紹介なら、そもそも素朴な静的 HTML で十分なことも多くあります。

また「Astro は React 比で何 % 速い」といった定量的な比較は、測定条件によって大きく変わるため、ここでは数値での断定はしません。確実に言えるのは、JavaScript をゼロから始めて必要な部分にだけ足す構造は、全体に配る構造より有利だという定性的な事実です。

大切なのはツール名ではなく考え方です。「このページのこの部品は、本当に JavaScript で動かす必要があるか」と一つずつ問う。Islands の発想は、どの作り方を選んでも JavaScript を最小限に保つための指針として役立ちます。