Astroはウェブの基本に立ち返るものです

320日前原文(websmith.studio)

概要

Astro はコンテンツ重視のWebフレームワーク
Island Architecture により必要な部分だけJavaScript適用
高速表示 とSEO・UX向上に直結
柔軟な開発体験 と多彩なフレームワーク統合
ブログやマーケティングサイト に最適な選択肢

Astroとは何か

Astro は2021年登場のWebフレームワーク
コンテンツ重視・サーバー優先設計 が特徴
デフォルトで JavaScriptゼロ出荷、必要箇所のみ追加
直感的なツール群 とシンプルなセットアップ
実際のWeb制作現場に最適化された設計思想

Island Architectureの革新

Island Architecture による部分的なJavaScript適用
ページ全体をJavaScriptでハイドレートせず、 必要なウィジェットのみ JS化
例：記事本文はHTML、コメント欄やカルーセルのみJS
静的HTML中心 でページ全体の高速表示を実現
シンプルで直感的なパフォーマンス最適化

パフォーマンスと実際の効果

Astroサイトは従来比で40%高速化
パフォーマンス向上は SEO・ユーザー満足度・コンバージョン へ直結
モバイルや低速回線 でも顕著な効果
開発者だけでなく 実ユーザーへの直接的な価値

優れた開発者体験

Houston によるガイド付きプロジェクト初期化
セットアップがシンプル で迷わない設計
TypeScriptサポート やビルド時実行コードで複雑さを回避
フックや状態管理・ライフサイクルの煩雑さなし

柔軟なコンポーネント設計

Astroコンポーネント はビルド時に実行、クリーンな構造

例：

--- // ここはビルド時実行
const { title } = Astro.props;
const posts = await fetchPosts();
---
<main>
  <h1>{title}</h1>
  {posts.map(post => (
    <article>
      <h2>{post.title}</h2>
      <p>{post.excerpt}</p>
    </article>
  ))}
</main>

データ取得やロジックは ユーザー表示前に完結
TypeScript も直感的に利用可能

好きなフレームワークと組み合わせ可能

React や Vue など他フレームワークを部分利用可能
例：管理画面はReact、グラフはVue、他はAstroで統一
柔軟な統合 でプロジェクトに最適な構成が実現

便利な機能群

Markdownサポート が標準で強力
- 例：Markdownファイルを直接コンポーネントとしてimport可能
モダンなビルドパイプライン
- TypeScript・Sass・画像最適化・HMRがデフォルト
静的/サーバーレンダリング の併用も自在
Webpack等の複雑な設定不要

Astroが最適な場面

マーケティングサイト ・ ブログ ・ ECカタログ ・ ポートフォリオ
コンテンツが主役 で複雑なクライアントサイド状態管理不要な案件
高速・シンプル・拡張性 を求めるプロジェクト

注意点・トレードオフ

SPA（シングルページアプリ） や複雑な状態管理には不向き
ISR や高度なクライアントルーティング要件ならNext.js等が有利
エコシステムは発展途上 でNext.js等と比較すると小規模
ファイルベースルーティング は大規模案件で制約を感じる場合あり

クイックスタート

プロジェクト作成

npm create astro@latest my-site
cd my-site

フレームワーク追加（例：React）
```
npx astro add react
```
開発開始
```
npm run dev
```
ページは src/pages/、コンポーネントは src/components/ に配置

なぜAstroなのか

JavaScriptフレームワークの複雑化 に対するシンプル回帰
本質的なWeb体験 （速さ・アクセシビリティ・コンテンツ重視）を最優先
正しい選択が簡単 にできる設計
必要な場所だけに インタラクティブ性 を追加可能
好きなフレームワーク も柔軟に組み合わせ可能

まとめ・推奨理由

コンテンツ重視のサイト にはAstroが最適解
ユーザー体験・開発体験・パフォーマンス の全てで高水準
Core Web Vitals も大幅向上
このブログ自体もAstroで構築 されている実例

Astroで、次世代の高速・シンプルなWebサイト構築を体感してみてください。

Hackerたちの意見

ほんとに賛成だわ。私にとってAstroは「ただのHTMLとCSSだけど、インクルードがある」って感じで始まった。個人のウェブサイトに使ったり、最近はMatrix Conferenceのウェブサイトを再実装する時にも使ったよ。手間いらずで、使ってて楽しいフレームワークだね。Astroの好きなところは、 - まだHTMLとCSS中心 - 一度作ったら、デフォルトでJSは必要ない - ちょっとしたインタラクティブ性のためにJSを追加することもできる - コンテンツコレクションがスッキリしてる - Astroはスピードを大幅に最適化してて、メンテナがそれを知ってる - 開発者用のバーがあって、どこを直せばウェブサイトがサクサクになるか視覚的に教えてくれる（例えば、画像が画面の下にあるときに遅延読み込みするみたいに）スピード最適化の例としては、CSSミニファイアが賢くCSSをインライン化して追加のクエリを避けることがある。彼らが提供するImageコンポーネントは、画像の幅と高さの属性を設定して、コンテンツのレイアウトシフトを避ける。レスポンシブ画像も自動生成してくれるよ。

└

まだHTMLとCSS中心 - 一度作ったら、デフォルトでJSは必要ない - ちょっとしたインタラクティブ性のためにJSを追加することもできる Astroは使ったことがないから無知を許してほしいけど、それって結局.htmlファイルと.cssファイルを作って、オプションで.jsファイルを提供するだけじゃないの？この場合、Astroは何を提供してくれるの？ファイルのディレクトリとNotepadがあれば同じ体験ができると思うんだけど。スピード最適化もさらに進んでるし、オーバーヘッドやバloatが全くないから、純粋なファイルがHTTPで送られるだけだし。 > 例えば、CSSミニファイアが賢くCSSをインライン化して追加のクエリを避けるそれって、あなたが作ったウェブページで一般的なパフォーマンスの問題なの？何百ものウェブサイトを作ってきたけど、20年間で「CSSクエリ」がボトルネックになったことは一度もないよ。ほとんどいつも他の何か（大体はネットワーク）だね。

└

私の一つの批判点は、複雑なルーティングがすぐに混乱して抽象的になっちゃうこと。これに対する真剣な解決策があるかは分からないけど、複雑さは摩擦なしには来ないから、直感的に今は別のものに切り替えようかなって思った。

伝統的なフレームワークは、JavaScriptでページ全体をハイドレートする。たとえシンプルなブログ記事にインタラクティブなウィジェットが一つあっても、ページ全体がJavaScriptの影響を受ける。Astroはこれをひっくり返す。デフォルトではページは静的HTMLで、インタラクティブが必要な部分だけがJavaScriptの「アイランド」になる。昔はこれを「プログレッシブエンハンスメント」（または単に「ウェブページ」）と呼んでいて、ダイナミックな動作を持つウェブサイトを作る唯一の方法だった。で、SPAが「発明」されて、「プログレッシブエンハンスメント」の動きはどんどん少なくなっていった。今はそれがJavaScriptのアイランドと呼ばれているけど、実際には昔ながらのウェブページに過ぎない :) 新しいウェブ開発者へのちょっとした歴史： https://en.wikipedia.org/wiki/Progressive_enhancement

└

それ自体は新しい概念じゃないと思うけど、やり方がずっとエレガントになったと思う。私は元々、PHPとjQueryがインタラクティブなウェブページの最先端だった時代にウェブ開発者として始めたんだけど、その後すぐにReactとSPAが流行り始めた。今振り返ると、アーキテクチャ的には元のアプローチが良かったけど、その頃のDXはひどかった。フロントエンドでPHPをデバッグしようとしたこと、覚えてる？あれには戻りたくないな。SPAにはその役割があるけど、特に顧客ダッシュボードやインタラクティブなアプリケーションでは、Astroはサーバーとクライアントコードを一つのコードベースに持つ素晴らしいバランスを見つけてる。どれがどれかを定義できて、PHPがやってることをJavaScriptコードにパースする必要がないのは、すごいDXの改善だよ。

└

昔は、ウェブサイトやウェブアプリを一つのまとまりとして作るための開発者体験なんてなかったよね。フロントエンドとバックエンドをカバーしながら、ハイドレーションのパフォーマンス低下を避けるなんて無理だった。今はAstroやNext.jsのRSCがあって、他にも強力な選択肢がたくさんあるよ。

└

それがAJAXって呼ばれてた頃を思い出すよ。完全に話がずれてるね。

└

この分野（ソフトウェア）、特にウェブ関連は、記憶がないみたいだね。ティーンや20代の若者たちが、同じパラダイムを違う名前で何度も再発見してる感じ。オブジェクト指向プログラミングやOOPデザインパターンの再発見がそろそろ必要だと思うけど、また別の名前で呼ばれるんだろうな。最近はメインフレームを再発見して「クラウドネイティブ」って呼んでた時代を乗り越えたばかりだし。たまにLLMや拡散モデルみたいな新しいものも出てくるけどね。

└

同意！Astroは素晴らしいけど、私が学ぶ上で一番の壁だったのは、2010年以降に職場に入った開発者たちが「ウェブの仕組み」を説明するために作り出した用語の範囲を理解することだった。

└

最初のウェブフレームワークは、ステートレスなウェブサイトとサーバーレンダリングで本当にうまくいってた。

└

君は逆の間違いをしてるよ：誰かのツールの機能の説明を見て、それを既存のやり方と混同してる。ツールが変革的かどうかも確認せずに、なんとなく似てるからって。Astroの主な価値は、JSフレームワークと統合して、HTMLのサブツリーを扱わせ、初期状態を文字列としてレンダリングし、クライアントでサーバーからのプリロードデータでハイドレートすることなんだ。TFAは、React/Svelte/Solid/Vueを使いたいけど、ページの一部だけで、サーバーでデータをプリロードしたい人にその価値を説明しようとしてる。これは必ずしもプログレッシブエンハンスメントではない。JSハイドレーションの前に読み込まれるHTMLは、全く機能する必要はないから。ハイドレートした後のJSの初期状態に一致するだけなんだ。例えば、これがJSが引き継がないと全く機能しない場合がある。こういう細かいところを見逃すのは、好奇心よりも皮肉を持っているからだよ。

「伝統的なフレームワーク」って言葉を読むと、なんだか年を感じる。SPAやバーチャルDOMフレームワークを指してるのに、実際の伝統的なフレームワーク（BackboneやjQueryなど）は、ブログ記事で説明されてる通りにちゃんと機能してたんだよね。

└

「伝統的」って、結局は自分が生まれた時期によるよね。私にとっての「伝統的」なインターネットは、56kbitモデム、vbulletinフォーラム、GTA:VCのモッディング、IRCなんだけど、年上の人にとっては「伝統的」なインターネットは多分BBSとかで、若い世代にとってはDiscordが「伝統的」なインターネットの一部なんだよね。政治的な保守派や伝統的なサークルでも同じことが言えて、基本的に若い頃は良かったけど、今は悪いって感じで、全てはその人が生まれた時期によって違う。

└

Backboneは純粋にSPAに特化してて、クライアントサイドのMVCだったのを覚えてる。

なんでAstroやNextJSみたいなSSRフレームワークが、SvelteKitのように動的パスを持つ静的ページを採用できないのか、全く理解できない。例えば、/todos/[todoId]というページがあったら、それを静的バンドルで提供できないし、NextJSはアプリを静的にビルドすることを拒否する。一方、SvelteKitは喜んでビルドして、デフォルトのレスポンスページ（Cloudflareの404.htmlみたいな）が正しいページを取得して、ユーザーの視点からは完璧に機能する。裏ではレスポンスが404だったとしても（その動的ページは実際にはコンパイルされていないから）。特にモバイル用のウェブビューとしてアプリをバンドルする時に、すごくいいよね。

└

静的なものが好きなんだけど、Next.jsもそれに対応してるよね。https://nextjs.org/docs/app/api-reference/functions/generate...

└

Next.jsでそれができるよ。アプリルーターではgenerateStaticParamsって呼ばれてて、ページルーターではgetStaticPropsだよ。

└

もしかしたら誤解してるかもしれないけど、これってAstroのgetStaticPaths[0]関数のことじゃないの？ [0]: https://docs.astro.build/en/guides/routing/#static-ssg-mode

└

あんまり理解できてないかもしれないけど（フレームワークについても）、Astroのサーバーアイランドが求めてるものなのかな？ https://docs.astro.build/en/guides/server-islands/

└

ちょっと同意するけど、それは欠点を伴うデザインの選択だよね。URL /todos/123 はSPAではハードリロードで解決できない。つまり、ユーザーが /todos/123 をブックマークしたり、ブラウザでリロードした場合、最終的にはそのファイルを取得するためにHTTPサーバーに問い合わせることになる。君が言ったように、それを取得するためには404ページを設定する必要があるけど、それにはHTTPサーバー（nginxとか）の設定が必要なんだ。だから、単なる静的なhtml+js+css+画像のデプロイじゃなくて、常にサーバーのサポートが必要になる。もう一つの問題は、HTTP仕様の4xxエラーは2xxとは異なる扱いを受けること。特に、ブラウザはどんなレスポンスヘッダーがサーバーから送られても404レスポンスをキャッシュすることが許可されていない。これが意味するのは、/todo/123のブックマークやハードリロードは、キャッシュにあっても常にページのフルダウンロードを引き起こすってこと。また、404ページを上書きするためには常にウェブサーバーのサポートが必要になる。今のNextJSの出力は、github-pagesや他のウェブスペースソリューションにデプロイできるから、これが考えられる限界なんだけど、もっとあるかもしれない。正直なところ、もしクエリパラメータを使えばいいなら、/todo?id=123にすればいいのに。これで上記の解決策のすべての問題が解決するし、サーバーサイドアプリ（JSなし）ってPHPとかの形になる。

Astroについて少し調べたけど、Denoチームが作ったFreshフレームワークとの違いがわからなかった…？Freshはすでにこのアイランドアーキテクチャを持ってるし、AstroのウェブサイトのベンチマークにはDeno+Freshとの比較が含まれてない。だから、Deno+AstroとDeno+Freshを使うメリットが何なのか、まだ疑問に思ってる。

└

AstroとFreshはどちらも、アイランドのアイデアにインスパイアされてるんだよね。確かEtsyのフロントエンドアーキテクトが提唱したんだっけ。それで、Preactのクリエイターがさらに詳しく説明してる。私の理解では、Astroは人気のフレームワークのコンポーネントをほぼそのままレンダリングできるけど、Freshは現在Deno経由でPreactに限られてる。制限があるのは、ビルドステップが不要になるように最適化するためだと思うし、Astroみたいにフレームワーク自体を調整しなくて済むからじゃないかな。私は関係者じゃないけど、両方のツールを見たことがあるだけだよ。

└

違いはたくさんあるよ。例えば、FreshはDenoでしか動かないし、Preactしか使えない。

最近、Astroを使って医療クリニックのウェブサイトを作ったんだけど、数年前にWordPressでやった時と比べてめっちゃ簡単だったのに驚いたよ。Netlifyみたいなところで無料でホスティングできるし、WPみたいにハッキングの心配もないから安心。クライアントが自分でコンテンツを更新できるように、シンプルなgitベースのCMSも作ったんだ。ウェブ開発は本当に進化してるね、みんなが言うほど悪くないよ。

└

友達に依頼されたの？医療クリニックのウェブサイトを作る仕事って、どうやって見つけるの？

└

Netlifyには気をつけてね。彼らの帯域幅料金はVercelよりもひどいから。

私にとっては、違うかな。いくつかのユースケースにはうまくいくけど、もしオフラインでJSをレンダリングして静的HTMLを生成するだけが必要だったなら、最初からそんなにJSはいらなかったと思う。アイランドは機能するけど、機能しなくなることもあるし、いろんなものがインライン化されることも多いよね。最終ビルドにこだわらなくなるなら、それでもいいのかもしれないけど。Astroに関する盛り上がりは、他の何よりもviteに関係してる気がする。で、確かにviteはすごいよね。

└

アイランドは機能するけど、機能しなくなることもあるそれって、いつのこと？

フロントエンドの会話の場が壊れてるのは明らかだね。エコシステムが混乱してるだけじゃなくて。記事で見かける会話を要約すると、ブラウザをHMIとして見るか、アプリケーションランタイムとして見るかって感じ。やりたいことによっては、どちらが合うかは変わるかも。でも、出てくるポイントは「新鮮な空気」みたいなふわっとした議論だったり、「読み込みが速い」っていう感じ。どれだけこの議論の場が壊れてるかを言葉にするのは難しいし、私自身も特に強い主張をしてるわけじゃないけど、フレームワークをブランドみたいに扱う会話には反発し続けることが大事だと思う。ファッション業界みたいにね。

└

「ロードが速くなる」って、ただの言葉遊び？どういうこと？

└

ファッション業界みたいなもんだね。ファッション業界はフロントエンドフレームワークの最良のアナロジーだと思う。何かを「コンテンツ駆動型」や「サーバー優先」と宣言するのに必要な技術的な厳密さはほとんどゼロだってことは明らかだ。

主な利点は、ReactやVueのような他のライブラリやフレームワークを使わなくてもいいことだと思う。HTMLやWebコンポーネントをそのまま使えるから。ただ、AstroはNextやNuxtと同様のタスクもこなせる、SSR、ISR、静的サイト生成、ミドルウェアなど。Astroのもう一つの違いと利点は、他のフレームワークと比べてアイランドアーキテクチャがあること。これにより、マイクロフロントエンドを実装できる。アイランドアーキテクチャやマイクロフロントエンドは、複数のチームがある企業やプロジェクトにとって必要な機能かもしれない。例えば、一つのチームがチェックアウトプロセスに取り組んで、別のチームがショッピングカート、また別のチームが商品リストに取り組むことができる。今、Astroを使えば、これらのコンポーネントを一つのルートやページで組み合わせられる。そして、これらのコンポーネントのレンダリング方法をコントロールできる。Astroは、これらのアイランド間でグローバルステートを共有することも可能だ。このアプローチは、チームが単一の機能を開発して出荷し、それに対して完全な責任を持つことができるので有益だ。ただし、欠点もあって、非アイランドアーキテクチャでも同様の結果を得ることができる。例えば、全てのチームがReactを使う場合、各チームが異なるバージョンのReactを使うことが一般的で、ブラウザがこれらのバージョンをすべて読み込むことになる。同じ問題は、一つのチームがVueを使い、別のチームがAngular、また別のチームがReactや他のフレームワークを使う場合にも発生する。ウェブが変わるとは完全には納得していない。基本的には、ライブラリやフレームワークのログインなしのNextやNuxtみたいなもんだし、アイランドアーキテクチャは通常、非常に大きなプロジェクトにしか有益じゃない。でも、試してみる価値はあるよ。私はAstroを最初のリリースから数年間使ってるし、試してみることをおすすめする。ReactやVueをやめてWebコンポーネントに移行したい人や、NextやNuxtを置き換えたい人にはいいツールだよ。Astroを使えば、ステップバイステップでそれができる。

Astroを試してみたけど、私には合わなかったな。数年前に自分のウェブサイトをJekyllからAstroにアップグレードしようとしたんだけど、学ぶことが多くて大変だった。フォルダもいっぱいあったし、すぐに何かが壊れちゃうことも多かった。結局、素のHTMLとCSSに戻ったよ。

ハクソク