ガンバラナイ

Astro 7にしたらビルドは速くなり、devは遅くなった

2026-06-28

技術BLOG

AstroViteBenchmark

Astro 7にしたらビルドは速くなり、devは遅くなった

はじめに

2026-06-22にAstro 7がリリースされました。当ブログはAstro 6.4.8で運用していたので、リリース直後にAstro 7.0.3へアップグレードしてビルド時間を実測してみました。結果はタイトルの通りで、本番ビルドは大幅に速くなったのに対して、devサーバーの起動だけは逆に遅くなる、という意外な結果になりました。

本記事では、計測条件、実測値、そして「なぜdevが遅くなったか」「なぜビルドが速くなったか」の順に掘り下げていきます。

アップグレードと計測の準備

公式のアップグレードツールを試したら、いきなり詰まりました。

npx @astrojs/upgrade@latest

これを実行するとastro本体と@astrojs/mdxの破壊的変更を検出してSome packages have breaking changes. Continue?と対話プロンプトが出ます。Claude CodeなどのCLIエージェント越しに作業していたため、標準入力に応答できずここで停止してしまいました。

回避策として、ツールが識別した最新メジャー版をそのままnpm installで指定しました。

npm install astro@^7.0.3 @astrojs/mdx@^7.0.0

@astrojs/sitemapは3.7.3のままで動作するので変更不要です。

当ブログでは破壊的変更へのコード修正は一切不要で済みました。これは元の構成が最小限だったためで、内訳は次の通りです。

Astro 7の破壊的変更 当ブログの状況
Vite 8化 astro.config.mjsにviteカスタム設定なし
Rustコンパイラ厳格化 .astro/.mdxに書式ミスなし
compressHTMLデフォルトが’jsx’に HTML差分は出るが視覚影響なし（後述）
Sätteriが新Markdownデフォルト remark/rehypeプラグイン未使用
@astrojs/dbの削除 未使用
astro:transitions内部API削除 未使用
experimental flag一斉撤去 未指定

計測条件は以下の通り。

  • 規模: 記事56本、画像379枚、生成ページ99
  • 環境: Node 22.22.2、WSL2上のDebian 13、dev container内
  • 各フェーズN=5ラン+ウォームアップ1ラン（集計対象外）
  • Build cold: rm -rf dist .astro node_modules/.astro node_modules/.vite後にnpm run build
  • Build warm: 直前のキャッシュを残したまま連続実行
  • Dev cold: .astroとVite キャッシュ削除後、astro dev起動からポート確立まで

WSL2上のI/Oはばらつきが出やすいので、min/median/mean全部を集計対象にしています。特にbuild warmは時々2秒台の極端な外れ値が出ましたが、傾向が両バージョンで共通だったので結論には影響しないと判断しました。

結果

Astro 6 vs 7 ビルド時間比較

5ラン分の集計値です。

指標 Astro 6.4.8 Astro 7.0.3 差分
Build cold (median, s) 14.30 13.60 -4.9%
Build cold (mean, s) 15.14 12.53 -17.2%
Build warm (median, s) 6.74 4.90 -27.3%
Build warm (mean, s) 6.32 4.35 -31.2%
Dev cold (mean, s) 4.91 5.95 +21.2%
distファイル数 652 652 ±0
dist合計サイズ 52.75 MB 52.73 MB -0.04%
Layout CSSサイズ 135,595 B 133,276 B -1.7%

本番ビルドはmeanで2〜3割短縮、devだけ1秒ほど悪化、という結果です。

出力差分も見ました。HTMLは652ファイル中101ファイルが差分を持ちますが、全部がAstro 7の既知変更で説明可能で、視覚的な崩れはありませんでした。

  • <meta name="generator">のバージョン表記更新
  • <link rel="stylesheet">のCSSハッシュ更新
  • compressHTMLのデフォルトがtrueから'jsx'になり、要素間のホワイトスペースが詰まる（例: </a> <li> → </a><li>）
  • インラインscriptのminify識別子の変化（Vite 8の新ミニファイヤ）

CSSは中身の最小化アルゴリズム自体も変わって-1.7%。dist全体のサイズはほぼ同等で、画像最適化結果に変化は出ていません。

なぜdevが遅くなったか

タイトルの主役なので先に書きます。

実は計測中、最初はdev起動時間の数値すら取れませんでした。Astro 6のdevサーバー出力にはastro v6.4.8 ready in 4129 msのような行があり、ベンチスクリプトではready inを正規表現で拾っていました。ところがAstro 7では起動ログがJSON形式に置き換わり、ready inの文字列ごと消えていました。

{
  "message": "Dev server running at http://localhost:4322 (pid 485411)\n  Network:\n    http://172.17.0.2:4322/\n  Stop:   astro dev stop\n  Status: astro dev status\n  Logs:   astro dev logs",
  "label": "SKIP_FORMAT",
  "level": "info"
}

messageフィールドは改行を埋め込んだ1つの文字列です。実際にターミナルでこれを展開した見た目はこうなります。

Dev server running at http://localhost:4322 (pid 485411)
  Network:
    http://172.17.0.2:4322/
  Stop:   astro dev stop
  Status: astro dev status
  Logs:   astro dev logs

判定文字列をAstro 6/7共通のhttp://(localhost|127.0.0.1):に切り替えて再計測しました。

ログを見ると分かりますが、Astro 7のdevサーバーは起動直後にastro dev stop astro dev status astro dev logsという新しいサブコマンド群を案内しています。Astro 7からdevサーバーがバックグラウンドdaemonとして動く設計に変わり、フォアグラウンドのターミナルを長時間専有しなくて良くなりました。CLIエージェント（Claude Codeなど）からの利用を想定した変更だと思われます。

dev cold startが1秒ほど悪化しているのは、おそらくこのdaemon化に伴う初期化処理（プロセスフォーク、JSONロガー初期化、新サブコマンドの常駐準備など）が増えたためと推察します。ただ当ブログでの実測はN=2と少なく、原因の特定までは至っていません。リリースノートにも明示はなく、今回のところは「事実として遅くなった、設計変更が大きい」までで止めておきます。

なぜビルドが速くなったか

こちらは公式リリースノートでも目玉として挙がっている領域で、3つの要因が重なっています。

  1. Vite 8化: Astro 7はバンドラとして使うViteをv7からv8に上げました。Vite 8では各種依存更新やバンドル戦略の改善が入っており、esbuild/lightningcssの新版も同時に取り込まれます。当ブログのLayout CSSが-1.7%小さくなったのは、おそらくこのCSS最小化の改善が効いた結果です。

  2. Rustコンパイラ統一: Astroの.astroファイルをパースするコンパイラが、Go実装からRust実装（@astrojs/compiler-rs）に統一されました。Astro 6ではexperimental扱いだったRust版がデフォルトかつ唯一の実装になり、コンパイル自体が高速化されています。同時にエラーチェックも厳格化され、未閉じタグなどは黙って自動修正されずエラー扱いになります。

  3. Sätteri Markdownデフォルト化: 従来はremark/rehypeベースのパイプラインがデフォルトでしたが、Astro 7からはネイティブ実装の「Sätteri」がデフォルトMarkdownプロセッサになりました。remark/rehypeプラグインを使っているプロジェクトは別途@astrojs/markdown-remarkを入れる必要があります。当ブログは標準Markdownのみ使用なので、Sätteriへの切り替えがそのまま速度向上に効いていると思われます。

ただし、当ブログのベンチでは「Vite 8単体・Rustコンパイラ単体・Sätteri単体」までの切り分けはしていません。あくまで合算効果としての-17〜31%です。

まとめ

個人ブログ規模（記事56本）でWSL2上、N=5の小さな実測なので、数字をそのまま大規模サイトに当てはめるのは無理がありますが、当ブログの環境では以下のような結果でした。

  • 本番ビルドは確かに速くなった（cold mean -17.2%、warm mean -31.2%）
  • devコールドスタートは1秒ほど悪化（+21.2%）、ただし新しいdaemon化の副作用と推察
  • アップグレード自体はnpm installだけで、コード変更ゼロで完了

総合判断としてはアップグレードを取り込んだ価値はあったと考えています。dev体験についてはAstro 7のdaemon化の意図（エージェント連携）が定着していくうちに最適化されると思うので、しばらく様子を見ます。

参考リンク