前編
Astroの特徴を知る
AstroというWebフレームワークをざっくり知りたい、また、Astroの特徴や機能について、技術選定に役立つ知識を持っておきたい人のために、エンジニアが座談会形式で解説します。
目次
シェア
はじめに
AstroというWebフレームワーク。CodeGridでも頻繁に取り上げるWebフレームワークです。最近、言葉としてはよく聞くけど、特徴などはよくわからない、知っていたほうがいいとは思うけれど、触ったり、情報収集したりする時間がない……という方に向けて、Astroを使った案件や、個人プロジェクトをこなすエンジニアが集結しました。
AstroがどのようなWebフレームワークか、どんなサイト制作に向いているか、また、これらの新機能は？ など気になるトピックについて、エンジニアの知見や意見を出し合いました。
これを読むことで、ざっくりとAstroがわかるはず！
参加したエンジニアは以下のとおりです。エンジニアが執筆したAstroやその周辺知識に関するシリーズをそれぞれ併記したので、より深く知りたいという方は参考にしてください。
- 中村 享介（Jamstackエンジニア）：「Jamstackを考える」シリーズ
- 宇野 陽太（フロントエンド・エンジニア）：「CodeGridの作り方 2024年 夏」シリーズ
- 中野 祐人（Jamstackエンジニア）：「今すぐ始めるAstro入門」シリーズ
- 渡辺 由（フロントエンド・エンジニア）：「Astro+SvelteでつくるWebサイト」シリーズ
そもそも、Astroって？
💡この節のポイント💡
- AstroはWebフレームワークのひとつ
- 高速に表示されるWebサイトを作るための機能が充実
- ReactやSvelteなど、好きなUIフレームワークのコンポーネントを追加できる
- ブログやニュースメディアなど、コンテンツを持つサイトに向く
――ピクセルグリッドではAstroを実際に案件に使うことも多いですよね。まずはAstroはどんなものなのか、そしてどんなことに使えるのか、ということから話していきたいと思います。
宇野：Astroとは、いわゆるWebフレームワークの一つですね。デフォルトでは、ビルド時にJavaScriptを取り除いた「構築済みのHTMLを吐き出す」というコンセプトです。ブラウザ側では、その構築済みのHTMLを読み込んで表示するので、表示が速いというメリットがあります。
中野：向いているサイトは、WebメディアとかECサイトとかですね。Webアプリのような、ユーザーがログインしてユーザー側からいろいろ入力して、みたいなのではなくて。ユーザーがそこに訪れていろんな情報を読むようなサイトを作るのには、やはりいいフレームワークかなと僕は思っています。
――WebメディアであるCodeGridも、Astroで作られていますよね。
中村：そうですね。Astro公式サイトのトップに「The web framework for content-driven websites」、つまり、「コンテンツドリブンなWebサイトのためのWebフレームワーク」ってコピーが書いてありますよね。ブログとかニュースメディアとか、コンテンツを持っているサイトのことです。
大きな画像逆に、コンテンツじゃなくて、たとえばデータを扱うような、管理画面とかそういうもののためのフレームワークではないという感じですね。ユーザーが入力した状態を保持して、この状態だったらこうなるとか、そういったところはあんまりサポートしてくれていないのがAstroかなと思っています。
ほかのフレームワークとの違い
――最近、人気のWebフレームワークとしてAstroの名前もよく聞くようになってきましたよね。
中村：そうですね。特に、Web制作界隈の人の中で、話題になっているように感じます。でも、「Next.jsの次に流行っている、新しいやつがAstro」というような考えは違うかなと。そもそも、Next.jsとAstroでは使う用途が違うというか。
――Astroを念頭に置いたときに、Next.jsはどう捉えればいいですか。
宇野：Next.jsだったり、Solid Startだったり、SvelteKitだったりっていうのは、やっぱりデータフローっていうのをしっかりと作れるように設計されていると思います。データが主体になっているっていうことですね。
DBにあるデータを受け取って、いい感じにアプリ内で取り回して描画する。あとはユーザーからの入力を受け取って、それを逆にサーバー側に送り返す。双方向なプリケーションを作るのに向いてるかなとは思います。
そういうところを作りやすいインターフェースが揃ってるのが、Next.jsという感じじゃないかな。
中村：ただ、Astroにもいろいろと機能がついてWebアプリの制作ができないわけではないし、Next.jsだってAstroが得意とするようなWebサイトを作れないわけじゃない。機能は被ってるところもあるから、きっちりした線引は難しいところだよなと思いますね。
宇野：そうですよね。とはいえ、やっぱりクライアントサイドでのリアルタイムな変更っていうのはAstroのサポート外だとは思うし、そのためのインターフェースっていうのはいまだに提供されてないですよね。
たとえば、クライアントのレンダリングに合わせて何かをフックして処理を実行しましょうっていうものはAstroは持っていない。そういうのはUIフレームワークのコンポーネントでやってねっていうのがAstroの基本かな。
――コンポーネントとしてほかのUIフレームワークを、Astro内で使えるわけですね。
宇野：そうです。JavaScriptが必要な部分は後からオプトインできるようにしましょうっていうのが、Astroのもう一つのコンセプト。
限りなく静的なWebサイトだったとしても、ユーザーの操作を受け付ける部分っていうのは出てくると思うんですね。たとえば、CodeGridは記事というコンテンツを扱うサイトだけど、購読者として「ログインする」とか、記事を「お気に入りに登録する」という動的な機能があるわけです。
そういう機能を実装する場合に、AstroではReactやVue、Svelteなどの各種UIライブラリで作成したコンポーネントを読み込めます。
JavaScriptが必要な部分で利用するAstroアイランド
💡この節のポイント💡
- 構築済みのHTMLにJavaScriptの動的な機能を追加することを「ハイドレーション」と呼ぶ
- Astroでは「Astroアイランド」というコンポーネントごとに独立してハイドレーションできる仕組み（パーシャルハイドレーション）があり、独立してることで表示速度を向上できる
- Astroアイランドでは好きなUIフレームワークのコンポーネントを利用できる
――AstroでJavaScriptが必要な部分を実装することについて、もう少し詳しくお願いします。
中村：そうですね。ちょっと歴史的な経緯を話してみましょう。
SPA（シングルページアプリケーション）と言われている、作り方があります。1つのHTML表示されたページ上で、ユーザーの操作に対してJavaScriptでデータを取ってきて描画するので、ユーザーが画面を切り替えなくても内容を動的に変化させられます。でも、SPAはとにかく最初の表示が遅い。JavaScriptをブラウザでたくさん実行しないといけないし、HTMLも何もないところから全部構築するので。
「じゃあ、最初のHTMLだけサーバーサイドで生成して、初回の表示を速くしようよ」っていうのがサーバーサイドレンダリング、SSRです。でもこれだと、JavaScriptのイベント部分をつけることができません。
その解決策として、そのすでに生成されたHTMLに対して、JavaScriptの機能を付加するのが「ハイドレーション」です。ただ、ハイドレーションはページ単位で行われるので、たとえば、すごく重いカルーセルが1か所入っていると、それのせいでページ全体の表示が遅れてしまうなんていうケースがあります。
そこで登場したのが「パーシャルハイドレーション」です。たとえば「重いカルーセル」をUIコンポーネントとして「その他の部分」から独立させてあげることによって、カルーセルがハイドレーションされなくても、他の部分は先に表示できるようになる仕組みですね。Astroでは、「アイランド」という機能を提供しています。
――この図でいうと、appと表示されている部分はUIコンポーネントとして独立している、ということですね。そのほかのHTMLの部分は、すでに生成されているものが表示されるので速い、という。
大きな画像中村：UIコンポーネントはReactやSvelte、Vue、SolidJS、などいろいろなフレームワークが使えるし、そのアイランド単位でフレームワークの混在もできるよ、というのがAstroアイランドです。
宇野：だから、Astroでは、既存のコード資産を流用することができるという利点もあるわけですよね。
Astroアイランドとサーバーアイランド
💡この節のポイント💡
- サーバーアイランドではAstroだけで遅延するコンポーネントを書ける
- サーバーアイランドは仕組みがシンプルになり、よりパフォーマンスが向上する可能性がある
中村：同じような機能として、Astro独自の「サーバーアイランド」があります。これはAstro 5からStable（ステーブル：安定版のこと）になる機能ですね。サーバーアイランドも、基本的には同じように、ページの表示速度を改善するためのものだけど、ほかのUIフレームワークを使わずに、Astroのサーバー側の仕組みで用意しようっていうものです。
――サーバーアイランドも、Astroアイランドと同じように、先に全体を表示して、アイランドの部分はあとから表示されるわけですよね。
中村：そうです。サーバーアイランドの公式デモを見ると、わかりやすいかもしれない。
デモにアクセスすると、全体的な静的なHTMLの部分はすぐに表示されるけど、コンテンツであるアイランドの部分はプレースホルダーしか表示されていないですよね。
大きな画像そして、準備ができると、アイランド部分のコンテンツも表示されます。
大きな画像この緑色の点が表示されているアイランドの部分は、DBの問い合わせなどで時間のかかる部分という想定で遅延させているのだと思います。しかし、ページ全体としてはすぐに表示され、ユーザーの体験に影響を与えないようになっています。
サーバーアイランドも、似たような構成で作ったAstroアイランドも、非同期処理なのは同じ。だけれど、他のReactやSvelteなどのUIコンポーネントフレームワークを使わずに、サーバーのレンダリングを遅らせることができるのが、このサーバーアイランドですね。
――全部Astroで処理を書けるということの利点は、どんなことですか？
宇野：たとえばAstroアイランドで「Reactコンポーネントでクライアントからデータを取るようにします」っていう実装になると、そこでサーバーと通信するためのインターフェースが必要になる。つまり、APIを実装してFetchして取ってきて、みたいなことをやる必要があったんですけど、サーバーアイランドを使えば「インターフェースは一切実装せずに、Astroがよしなにしてくれますよ」っていうお話です。
中村：そうですね、複雑な構成にならないっていうことですね。シンプルに作れるし、場合によってはより速く表示できる可能性がある感じです。
ブラウザに処理をさせないことのメリット
ブラウザからAPIを介してデータをやり取りするなど、ブラウザ側いろいろな処理させると、コンテンツ配信者側では、ブラウザで何が起きているかを、把握しにくいという状況があります。ブラウザ側のことを配信者がなんでも把握できてしまうというのは、プライバシー的にも大きな問題になりますので、制限がかかっているわけです。ですので、エラー収集ツールなどを活用したとしても、ブラウザで起きていることをすべて把握するのは困難です。
でも、サーバーアイランドのように、サーバー側で処理するのであれば、もうちょっとわかりやすくなります。サーバーのログなりなんなり、確認する手段もあるわけです。このように、開発者が把握できる範囲内で、処理をやってくれているというのも、サーバーアイランドのメリットのように感じます。ユーザーに届ける時は、さまざまな処理が終わって、極力シンプルになってるっていうのは、開発者としてはやりやすい気がしますね。（渡辺）
――WebフレームワークとしてのAstroの特徴がわかってきました。次回はもう少しAstroの特徴を見た後、実務での技術選択に役立つように、Astroで制作するのに向いているサイト、向いていないサイトなどのお話をお願いしたいと思います。
（続く）
