Astro の第 7 系列は、機能の一覧ではなくビルドの流れそのものに力を置いた。最も遅い 2 段を Rust の実装に置き換え、残った疑問は所要時間の内訳に答えさせる。

現行の安定版は 7.4.1

現在の安定版は 7.4.1 で、2026 年 10 月 19 日に公開された。この系列には 2 つの節目がある。第 7 系列が始まったのが 2026 年 6 月 22 日、今回の更新が届いたのが 10 月 15 日だ。企画は MIT の許諾で公開され、置き場の主な言語は TypeScript である。

最も遅い 2 段を Rust が引き受けた

第 7 系列の最初の公開がやったことは 1 文に収まる。astro の部品を扱うコンパイラを丸ごと差し替え、Go 版から Rust 版へ書き直した。Markdown と MDX の処理も Rust の流れに移した。描画の仕組みは待ち行列を土台にした方針へ変え、描画待ちの断片をより効率よく並べるようにした。

公式の理由はこうだ。ビルドは 3 段に分かれ、最初の段が時間を食う。ページ、内容、ブラウザ側の部品をまず 1 つの JavaScript の束にまとめ、そのあと事前に描画するページごとに要求を出して HTML にする。遅い部分はちょうどコンパイルと Markdown の処理だったので、この 2 段が土台のコードへ移された。既定の Markdown 処理も入れ替わり、これまでの拡張の組み合わせから自前の流れになった。標準の Markdown だけを書くサイトはほとんど気づかない。構文の木を書き換える拡張をいくつも載せた企画は、1 つずつ確かめる必要がある。

Vite 8 とそれが連れてくる梱包の道具

速さのもう半分は Vite 8 から来る。あの版の最も大きな変化は、Rust で書かれた梱包の道具を内側に持ったことだ。これまで仕事を分けていた 2 つの道具を 1 つにまとめ、拡張の接点はそのまま残した。まとめたあと、公式は幅を示している。ビルド全体の時間が 15 から 61 パーセント短くなり、一部のサイトは 2 倍以上速くなる。

基準の表のほうが分布をよく示す。6 千ページあまりの文書サイトが約 115 秒から約 74 秒へ、1 万 3 千ページのものが約 386 秒から約 326 秒へ下がった。ページ数の多いサイトほど割合での利得は小さくなる。ページの描画そのものは Rust へ移っていないので、残りの時間に占める割合が上がるからだ。

どれだけ得をするかは、そのサイトの時間のどれだけがコンパイルと Markdown に使われているかで決まる。数千本の Markdown が積み上がった内容のサイトは、まさにコンパイルが大半を占める種類である。

今回の更新はビルドを 1 枚の報告にする

最初の公開が答えたのはどう速くするかだった。今回はどこが速く、どこが遅いかに答える。ビルドの命令に引数が 1 つ増え、終わると内訳を印字する。各段、拡張の種類ごと、Markdown の処理と構文の強調、ページの描画、画像の処理、統合ごとの所要時間と割合に加え、最も遅いページの中位と上位の値も付く。

公式はブログの雛形で実演している。雛形は 9 ページしかなく、全体で約 2 秒半、うちページの生成が 2 秒あまりで約 8 割を占める。最も遅いページは記事の型を当てているものにほぼ限られ、最初のページと購読の配信はミリ秒の単位に収まる。問題の指摘は明確だ。型の中で、感想の欄がまず感想を取り、そのあと各感想の書き手の情報を取る。2 往復の要求がつながり、どのページも待たされる。

一度にまとめて並行して取り、結果を下へ渡す形に変えると、ページの生成は 2 秒あまりから約 1 秒へ下がり、記事 1 本あたりの描画時間は半分になった。この例の値打ちはその 1 秒ではなく、報告がなければ見つけにくいものを示した点にある。編集画面ではコードは何の問題もなく見える。

画像の窓口がビルド時と実行時に分かれる

今回、画像の窓口を 2 組設定できるようになった。事前に描画するページ用が 1 組、要求に応じて描画するページ用がもう 1 組だ。ビルドのときは機械ごと完全な環境があるので、その場の改善役が最も適している。要求に応じた描画はサーバーや端の節点で動くので、その場の改善役が動かないことがあり、画像の配信網が理にかなった選択になる。以前はどちらか一方を選ぶか、接続役に決めてもらうしかなかった。これを成り立たせるため、ビルド中に使う画像は枠組み自身の流れで一括して追うようになり、各接続役が同じものを複製することはなくなった。

厳しくなったコンパイラが意味するもの

コンパイラの入れ替えは単なる高速化ではない。新しい Rust のコンパイラは、正しくない HTML の書き方に対して厳しい。閉じていない印はそのまま誤りになり、中身のある要素には対になる閉じる印が要る。意味の上で正しくない入れ子は自動で直されず、書かれたままブラウザへ渡される。

以前のコンパイラは黙って助けた。印を閉じ、順序を整え、置き場所の違う節点を外へ出した。この助けが、ある場合には追いにくい不具合を生んだので、新しい側は助けないことを選んだ。代償として、更新後にそれまで見たことのない誤りが出ることがあり、描画の結果が変わっていることもある。実際のやり方は素朴だ。更新したらまず 1 度ビルドし、閉じていない印があれば補い、描画が変わったら型の入れ子を確認する。型が整った企画はほとんど何も感じず、歴史の重い企画は 1 度の整理になる。

2 つの試験的な切り替えと幾つかの新しい約束

試験的な能力が 2 つ付いてくる。1 つは並行の事前描画で、静的なページの描画を複数の作業の流れに分け、既定では 1 つを除くすべての核を使う。流れが増えるほどビルドの記憶域も増えるので、記憶域が厳しいときや速くならないときは数を下げるべきだ。もう 1 つは独自の転送ページで、静的なサイトには転送の頭出しを送るサーバーがないため、転送のたびに再読み込みの指示を持つ小さなページを作る。これまでその文言、体裁、遅れは固定だったが、新しい切り替えでは自分の型で描画し、出どころ、行き先、状態の番号、遅れを引数として渡せる。

新しい約束も幾つか記しておきたい。Node の最低の版が 22 に上がる。src/fetch.ts は予約された名になり、進んだ経路の設定が自動で読み込むので、同じ名のファイルがある企画は設定を変えるか改名が要る。書体の提供元には任意の呼び戻しが増え、その書体が実際に持つ太さ、字形、部分集合、形式を宣言できる。提供元が出せない値を設定に書くと早めに警告が出る。いまは任意で、次の大きな版では必須になる。

どんな人に向くか

公式は自らを内容の駆動するサイト向けの枠組みと称し、宣伝のサイト、ブログ、販売のサイトを挙げる。中核の方針はサーバー優先で、部品はサーバー側で描画され、ブラウザへは HTML だけが渡る。余分な JavaScript の負担はゼロで、やり取りが要る部分は島として別に読み込む。広がりやすさでは、主要な画面の枠組みの部品をそのまま受け入れ、すでにある部品をそのまま持ち込める。内容の側では集合を用意し、フォルダに置いた Markdown とデータのファイルが型の安全と補完を自動で得る。

道具箱に入れる理由は普通、1 つの機能ではなく、ビルド時間と産物の大きさを同時に抑えられることにある。第 7 系列が前者を押し下げ、今回はそれを説明できるものにした。

Astro 7 の語る話は素朴だ。遅い部分をより速い言語の実装に替え、残って説明のつかない部分を読める報告にする。前者は 1 度の書き直しで済み、後者は引数 1 つで足りる。覚えておくべきは割合の数字ではなく、ビルドが遅くなったらまず報告を見て、それからどこを直すか決めるという順序のほうだ。