かつて、自分は GatsbyJS が大好きでした。
React ベースで静的サイトが作れる。GraphQL でデータを柔軟に取得できる。プラグインエコシステムも充実している。
「これこそ最強のSSGだ」と思っていた時期が、確かにありました。
しかし、Astro を使い始めてからその認識は一変しました。
今回は、GatsbyJS から Astro に移行して感じた「世界が変わった」体験を書きます。
GatsbyJS を好んでいた理由
まず、なぜ GatsbyJS を使っていたのかを振り返ります。
当時の自分にとって GatsbyJS は、かなり理想に近い選択肢でした。普段から React を触っていたので、その延長でサイトを組めるのは単純に楽でしたし、マークダウンや外部 API のデータを GraphQL でまとめて扱えるのも便利でした。画像最適化や SEO まわりもプラグインで一通り揃っていて、静的サイトジェネレーターとしての完成度はかなり高かったと思います。
実際、個人ブログや LP を作るのにはかなり重宝していました。
だんだん辛くなってきた
しかし、使い込むうちにじわじわと辛さが増してきました。
GraphQL が重い
GatsbyJS では、すべてのデータ取得が GraphQL 経由です。
マークダウンの記事一覧を取得するだけでも、こんなクエリを書く必要があります。
query {
allMarkdownRemark(sort: { fields: [frontmatter___date], order: DESC }) {
edges {
node {
frontmatter {
title
date
slug
}
excerpt
}
}
}
}正直、ブログの記事一覧を出したいだけなのに、これは大げさすぎないか？とは思っていました。
ビルドが遅い
記事数が増えるにつれて、ビルド時間がどんどん伸びていきました。
Webpack ベースなので仕方ないのですが、記事を1つ追加するだけで数分待たされるのは、開発体験としてなかなかストレスです。
React ランタイムが常についてくる
SSG で静的 HTML を生成しているとはいえ、GatsbyJS はクライアントサイドで React の hydration を行います。
つまり、ただの静的ブログなのに React のランタイム JS が常にバンドルされている のです。
ページの内容を表示するだけなら、この JS は完全に不要です。
Astro との出会い
そんな中で出会ったのが Astro でした。
最初は「また新しい SSG か」程度に思っていたのですが、ドキュメントを読んで衝撃を受けました。
「何もしなければ、クライアント JavaScript をほとんど送らない」
これです。この思想が全てを変えました。
ビルドプロセスの違い
GatsbyJS と Astro では、ビルドの考え方が根本的に異なります。
GatsbyJS は React のランタイムを含んだ JS バンドルを生成しますが、Astro は特に指定しなければクライアント JS をほとんど送らない設計です。
Vite ベースなのでビルドも高速。記事を追加しても待たされることがありません。
GatsbyJS vs Astro 比較
改めて、両者の違いを整理するとこうなります。
こうして並べると、コンテンツサイトにおいては Astro の方が合理的な設計になっていることがわかります。
自分が特に大きいと感じた違いは、次のあたりです。
| 観点 | GatsbyJS | Astro |
|---|---|---|
| データ取得 | GraphQL が前提。柔軟だが、ブログ程度だと少し重い | Content Collections で素直に扱える |
| クライアント JS | React ランタイムが前提で載ってくる | 必要なところだけ読み込める |
| UI の選択肢 | React 前提 | React / Vue / Svelte などを必要に応じて選べる |
Astro の Content Collections は、マークダウンファイルを型安全に扱えるのがよくできています。GraphQL のクエリを毎回組み立てなくても、ディレクトリに記事を置いてスキーマを定義すれば済む。この素直さは、運用を続けるほど効いてきます。
それに加えて、静的なページには余計な JavaScript を載せないという前提が最初からあるのも大きいです。コンテンツを読むだけのページに React のランタイムは基本的に不要なので、その前提で設計されている Astro はかなり気持ちがいいです。
さらに GatsbyJS が React 一択なのに対して、Astro は UI フレームワークに縛られません。必要なら React を使えばいいし、もっと軽く済ませたいなら .astro ファイルだけで完結させることもできます。この自由度の高さも、実際に触るとかなり魅力的でした。
Islands Architecture の合理性
Astro の設計思想で特に感動したのが Islands Architecture です。
ページ全体を JS で制御するのではなく、インタラクティブが必要な部分だけを「島」として JS を読み込む考え方です。
たとえばブログ記事のページなら、ヘッダーや本文、フッターは静的 HTML のままで十分です。一方で、検索バーは client:load で早めに読み込み、いいねボタンは client:visible で見える位置に来たら起動し、コメントフォームは client:idle でブラウザが落ち着いたタイミングに回す、といった設計ができます。
整理すると、こんなイメージです。
| パーツ | 読み込み方 |
|---|---|
| ヘッダー、本文、フッター | 静的 HTML のまま。JS なし |
| 検索バー | client:load で即時読み込み |
| いいねボタン | client:visible で表示時に読み込み |
| コメントフォーム | client:idle で余裕があるときに読み込み |
必要な箇所に、必要なタイミングで、必要な分だけ JS を読み込む。この割り切りが、Astro の設計をかなり合理的に見せています。
GatsbyJS でも工夫の余地はありますが、Astro のほうがこうした制御をずっと自然に書けると感じました。
実際に移行してみて
このサイト自体、WordPress から Astro に移行したものです（その時の話はこちら）。
移行してみてまず感じたのは、ビルドがとにかく速いこと。
100記事を超えていても数十秒で終わるので、記事を追加したりレイアウトを微調整したりするたびに待たされる感覚がほとんどありません。
ページも軽く、余計な JS が少ないぶん表示がかなり素直です。.astro ファイル自体も読みやすく、マークダウンとの相性もいいので、日々の更新作業がかなり楽になりました。
もちろん万能ではありません。エコシステムの厚みは、さすがに GatsbyJS の全盛期ほどではないですし、最初から動的な機能をたくさん抱えたサイトにはあまり向いていません。ただ、個人ブログや技術サイトのように「コンテンツをきちんと速く届けたい」という用途であれば、この弱点が気になる場面はそこまで多くないと思います。
関連記事
今回触れた「このサイトを WordPress から Astro に移行した話」は、別記事で詳しく書いています。移行のきっかけや、実際にどんな流れで Astro へ乗り換えたのかが気になる方は、【雑記】WordPress から Astro へサイトを全面移行した話 もあわせてどうぞ。
おわりに
GatsbyJS は当時としては革新的なツールでしたし、お世話になりました。
ただ、今コンテンツサイトを作るなら、自分は迷わず Astro を選びます。
「静的サイトに不要な JS を送らない」という当たり前を、当たり前にやってくれるツール。それが Astro です。
GatsbyJS に不満を感じている方、あるいは新しくブログやドキュメントサイトを作ろうとしている方には、ぜひ一度試してみてほしいです。少なくとも自分にとっては、静的サイトの見方がかなり変わりました。
