Astroの仕組みを理解する | Astroに入門してみる

#高速表示を支えるアーキテクチャの核心

Astroが高速なWebサイトを実現できる理由は、HTML生成とJavaScript配信の分離にあります。この仕組みを把握しておくと、コンポーネント設計やディレクティブの使い分けに迷わなくなります。

Astroはデフォルトで 静的サイトジェネレーター（SSG: Static Site Generator） として動作します。

通常のReactアプリ（SPA）とAstro（SSG）の動作フローを比較してみましょう。

最大の特徴は、ページの描画処理がすべてビルド時に完結している点にあります。ブラウザは完成したHTMLを受け取るだけで即座にページを表示できるため、初回表示が極めて高速です。

Astroで作ったページは、特に何も指定しなければ JavaScriptを1バイトもクライアントに送りません。

たとえば以下のような .astro ファイルを書いた場合：

---
const greeting = "こんにちは！";
---

<h1>{greeting}</h1>
<p>Astroで作ったページです。</p>

ビルドすると、出力されるのは純粋なHTMLだけです。

<h1>こんにちは！</h1>
<p>Astroで作ったページです。</p>

フロントマター内の const greeting = "こんにちは！" はビルド時に解決され、出力には含まれません。ブラウザには「結果」だけが届きます。

Islands Architectureを理解するために、Webフレームワークの歴史を簡単に振り返りましょう。

第1世代：サーバーサイドレンダリング（2000年代）

PHP、Ruby on Rails、Djangoなどが主流でした。サーバーでHTMLを生成してブラウザに送るシンプルな仕組みです。ページ遷移のたびにサーバーに問い合わせが発生し、全画面が再読み込みされていました。

第2世代：SPA — Single Page Application（2010年代前半〜）

Angular、React、Vueの登場により、ブラウザ側でJavaScriptがすべてのUI描画を担うようになりました。ページ遷移が高速になり、リッチなユーザー体験が可能になった一方で、初期ロード時に大量のJavaScriptをダウンロードする必要があるという問題が生まれました。

第3世代：SSR + Hydration（2010年代後半〜）

Next.js、Nuxtが登場し、サーバーでHTMLを事前生成（SSR）した後、ブラウザ側でJavaScriptが「引き継ぎ」を行う Hydration（ハイドレーション） という手法が主流になりました。

初期表示は速くなりましたが、ページ全体をHydrationするためにやはり大量のJavaScriptが送られるという本質的な問題は残っていました。

第4世代：Islands Architecture（2020年代〜）

ここでAstroの出番です。「ページ全体をHydrationする必要があるのか？」という問いに対する答えが Islands Architecture です。

ページの大部分は静的なHTMLとして送り、インタラクティブな操作が必要な箇所だけを独立した「島（Island）」として個別にHydrationします。

このアーキテクチャの利点は明確です。

Astro製サイトのJS転送量がどれだけ少ないかは、ブラウザのDevToolsで実際に確認できます。

一般的なSPAと比較すると、JavaScript転送量に大きな差があることがわかるはずです。

とはいえ、Astro公式サイト自体にもインタラクティブな要素があるため、ゼロにはなりません。Islands Architectureでは、必要なところにだけJSを送ることが重要なのであって、JSを完全に排除することが目的ではありません。

Astroは SSG（静的生成） がデフォルトですが、SSR（サーバーサイドレンダリング） にも対応しています。

多くのコンテンツサイトでは SSGで十分 です。SSRが必要になるのは、ログイン機能やユーザーごとに異なるコンテンツを表示する必要がある場合です。

また、SSRモードでも個別のページに export const prerender = true を指定すれば、そのページだけをビルド時に静的生成できます。つまり、SSGとSSRを同一プロジェクト内でページごとに使い分けられます。

本章で押さえておくべき設計原則は次の3点です。

次章では開発環境をセットアップし、実際にAstroプロジェクトを立ち上げます。