シリーズ目次 ／ 次章: 02. Astroの環境構築とプロジェクト構成
Table of contents
Open Table of contents
この章のねらい
Astroは、何を優先して何を捨てるかの判断が他のフレームワークとはっきり違います。まずはその中身から見ていきます。
ここを押さえておくと、以降の章に出てくる機能が、なぜそういう設計なのかという理由つきで頭に入ります。
Astroが解こうとしている問題
2010年代後半以降、Webフロントエンドの主流はSPA（Single Page Application、シングルページアプリケーション）でした。SPAとは、最初に大きなJavaScriptをブラウザに送り、以降の画面の切り替えをJavaScriptがブラウザ上で行う方式です。
用語: SPAは「1枚のHTMLページの中身をJavaScriptで書き換え続ける」方式のWebアプリです。GmailやGoogleマップのように、画面遷移が多く操作が複雑なアプリに向いています。
SPAは、メールクライアントや管理画面のような操作が主役のアプリでは、これがよく効きます。しかし、ブログ・ニュースサイト・製品紹介ページ・ドキュメントのような読むことが主役のサイトでは、話が変わります。記事を読むだけの読者に、数百KBのJavaScriptをダウンロードさせて画面を組み立てさせるのは、明らかに過剰です。
Astroの公式ドキュメントは、この問題意識をコンテンツ駆動型（content-driven）のWebサイトに特化すると書いています。トレードオフをコンテンツ配信の側に寄せて速さを取る、という方針だそうです。
身近な例えで言うと
レストランに例えると分かりやすいかもしれません。
- SPA は、客席に食材と調理器具一式を運び込み、客が自分で調理する方式です。カスタマイズは自由自在ですが、最初に運び込む荷物が重く、食べ始めるまで時間がかかります。
- Astro は、厨房で完成させた料理を配膳する方式です。すぐ食べられます。ただし「その場で味を調整したい」部分だけは、卓上の調味料（＝少量のJavaScript）を用意しておきます。
読むことが目的の来店客にとっては、後者のほうが快適です。
客席に何が運び込まれるかを並べると、違いがはっきりします。
5つの設計原則
公式ドキュメントの「Why Astro?」では、Astroの設計が5つの原則で説明されています。
| 原則 | 意味 |
|---|---|
| Content-driven | マーケティングサイト、ブログ、ドキュメントなどコンテンツ豊富なサイトの構築に特化する |
| Server-first | クライアントサイドレンダリングよりサーバーレンダリングを優先する |
| Fast by default | 「性能の悪いサイトを作るほうが難しい」状態を目指す |
| Easy to use | .astroはHTMLの上位互換で、学習曲線をなだらかにする |
| Developer-focused | エディタ拡張、CLI、多言語ドキュメント、コミュニティで開発者を支える |
このうち、技術的な判断に最も大きく効いているのが Server-first です。
この5つは横並びの特徴ではありません。Content-drivenという目的があり、そこからServer-firstという判断が出てきて、速さはその結果です。
Server-firstとMPAモデル
Astroは、SPAではなくMPA（Multi-Page Application、マルチページアプリケーション）モデルを採用しています。MPAとは、URLごとにサーバー側でHTMLを用意し、ページ遷移のたびに新しいHTMLを読み込む従来型の方式です。
公式ドキュメントは、このMPAモデルによってSPAモデルよりも初期ロードのパフォーマンスに優れると説明しています。両者のリクエスト処理の違いを図にすると、次のようになります。
クライアントレンダリングだけで画面を組み立てるSPAでは、JavaScriptの読み込みと実行が終わるまで主要な内容を表示できません。一方、Astroではサーバーから届いたHTMLをブラウザがそのまま表示できます。なお、Next.jsやNuxtなどのフレームワークも、サーバーレンダリングや静的生成を使えば完成したHTMLを先に表示できます。
MPAには弱点もあります。インタラクティブ性が乏しく、ページを移るたびに画面がちらつきます。Astroはこれを、後の章で扱うアイランドアーキテクチャとView Transitionsで補っています。
Zero JS by default
Astroの最も特徴的な挙動が、デフォルトではクライアントにJavaScriptを一切送らないという点です。
.astroコンポーネントに書いたJavaScriptは、ビルド時やリクエスト時にサーバー側で実行され、その結果のHTMLだけがブラウザに届きます。ReactやVueのコンポーネントを使った場合でも、明示的に指示しない限り、静的HTMLとしてレンダリングされてJavaScriptは削除されます。
つまりJavaScriptは、必要な場所に自分で足すものになりました。Astroのサイトが軽いのはこの一点によります。
既定の状態と、必要な部品にだけJavaScriptを足したあとを並べると次のようになります。
必要な部分だけを対話的にする仕組みが「アイランド」で、これは08. AstroのアイランドアーキテクチャとUIフレームワークで詳しく扱います。
UIフレームワークとの関係
Astroは特定のUIフレームワークに縛られません。公式インテグレーションとして、React、Preact、Svelte、Vue、SolidJS、Alpine.jsが用意されています。
さらに、1つのAstroコンポーネントの中に、ReactのコンポーネントとSvelteのコンポーネントを同時に置くこともできます。既存の資産を持ち込みやすく、将来フレームワークを乗り換える際の負担も小さくなります。
Astroを使うためにReactを覚える必要はありません。素のHTMLとJavaScriptだけでもサイトは作れます。
他のフレームワークとの位置づけ
ざっくりした比較を表にします。優劣ではなく得意分野の違いです。
| 観点 | Astro | Next.js / Nuxtなど | 素のHTML/CSS |
|---|---|---|---|
| 主な用途 | コンテンツ中心のサイト | アプリケーション中心のサイト | 小規模な静的ページ |
| 既定のJS量 | ゼロ | レンダリング方式や構成によって異なる | ゼロ |
| UIライブラリ | 複数を混在できる | 基本的に1つに固定 | なし |
| コンポーネント化 | できる | できる | できない |
| 学習コスト | 低〜中 | 中〜高 | 低 |
管理画面やリアルタイム性の高いアプリを作るなら、アプリケーション志向のフレームワークのほうが適しています。逆に、記事や製品情報を届けるサイトであれば、Astroの土俵です。
Astro 7という現在地
このシリーズはAstro 7系を前提としています。Astro 7は2026年6月22日にリリースされたメジャーバージョンで、公式ブログでは主に次の点が挙げられています。
.astroコンパイラをRustで書き直し- Markdown / MDXの処理パイプラインをRust製の新プロセッサへ変更
- ビルドツールをVite 8へ更新
Astro.cacheAPIによるルートキャッシュ制御の追加- バックグラウンド開発サーバー（
astro dev --background）の追加
これらの変更に、レンダリングエンジンやVite 8の改善を合わせたAstro 7全体のベンチマークでは、ビルド時間が15〜61%短縮されています。
一方で、破壊的変更も含まれます。特に、新しいコンパイラは不正なHTML構文に対して以前より厳しくなり、タグの閉じ忘れなどがエラーになります。過去の記事やサンプルコードを参照するときは、対象バージョンに注意してください。
要点
- Astroは、操作が主役のアプリではなく「読むことが主役のサイト」に最適化されたフレームワークである。
- サーバー側でHTMLを完成させるMPAモデルを採用し、初期表示の速さを優先する。
- デフォルトではクライアントにJavaScriptを送らず、必要な部分にだけ後から足す方針を取る。
- React / Vue / Svelteなど複数のUIフレームワークを混在させられ、特定の技術に縛られない。
- 本シリーズは2026年6月リリースのAstro 7系を前提とする。
参考資料
- Why Astro? — Astro Docs
- Astro Islands — Astro Docs
- Front-end frameworks — Astro Docs
- Astro 7 リリースブログ
- Upgrade to Astro v7 — Astro Docs