記事が300本を超えたあたりから、誤字をひとつ直すだけのデプロイに2分かかるようになる。書き手は「直したい」と思ってから公開までの待ち時間で、修正そのものを諦め始めます。
これはオウンドメディアを自社で持った会社が、だいたい2年目に踏む場所です。立ち上げ時は数十本しかないので誰も気にしません。コンテンツが資産になったころに、ビルド時間だけが静かに伸びています。
遅さの正体は、Markdownを何度も通していること
静的サイトジェネレーターがMarkdownをHTMLに変換するとき、内部では1本の記事に対して複数の処理が順番に走ります。パースして構文木を作り、その木にプラグインを次々と当てて、最後にHTMLへ書き出す。このプラグインの列が、記事の本数だけ繰り返されます。
JavaScriptで書かれた処理を1記事あたり十数回、それを数百記事分。1本あたりの差は数ミリ秒でも、掛け算の結果がビルド時間として出てきます。つまり遅さの原因は「記事が重い」ことではなく、変換の仕組みが記事数に対して線形に効いてくることにあります。
Sätteriは、この列をRustに置き換えた
Astroが採用したSätteriは、この変換部分をRustで書き直したMarkdown/MDXプロセッサです。Astroのコアコントリビューターである Erika 氏が Bruits collective のもとで、Astro組織の外で保守しているプロジェクトですが、現在はフレームワークのコア依存になっています。
中身としては、CommonMarkのパースに pulldown-cmark、MDXの式のパースに Oxc を使います。ポイントはGFMのテーブル、スマート句読点、シンタックスハイライトのフックといった「よく使う機能」を、プラグイン経由ではなくRust側でネイティブに実装したことです。速度の出どころはここにあります。
Astro自身のベンチマークでは、ビルドが15〜61%速くなったと報告されています。
| 対象 | 変更前 | 変更後 |
|---|---|---|
| astro.build | 62.70秒 | 24.24秒 |
| Cloudflare開発者ドキュメント（8,431ページ） | 386.89秒 | 261.94秒 |
規模が大きいほど効くわけではない点に注意してください。8,431ページのサイトで32%、公式サイトで61%と、削減率はページ数ではなく「何をプラグインでやっているか」に左右されます。
速くなる代わりに、確認するものがある
ここが判断の分かれ目です。Sätteriは柔軟なJavaScriptプラグインを上に乗せられる設計で、unifiedエコシステムとの互換性を保っています。それでも、自作プラグインを抱えているサイトほど、乗り換えの前に検証が要ります。
具体的な話をします。このGH Mediaのリポジトリには、自作のrehypeプラグインが2つあります。ひとつは rehype-bold-fix.mjs で、全角文字に隣接した 強調 が <strong> に変換されないケースを救済するものです。日本語のMarkdownでは、句読点や括弧の直後に強調を置くと変換が効かないことがあり、その分岐を自前で補っています。もうひとつは rehype-table-wrapper.mjs で、テーブルを横スクロール可能な要素で包んでいます。
どちらも「無くても記事は出るが、無いと表示が崩れる」種類の処理です。変換エンジンを入れ替えたときに、これらが同じ入力に対して同じ木を受け取れるかどうかは、動かしてみるまで分かりません。 日本語特有の全角文字の扱いのように、英語圏のテストケースに含まれにくい条件を踏んでいるものは特にそうです。
つまり判断材料はこうなります。プラグインをほとんど使っていないサイトなら、速度をほぼそのまま受け取れます。逆に、表示の細部を自作プラグインで整えてきたサイトほど、削減率は下がり、検証コストは上がります。 移行の可否は「Astroのバージョン」ではなく「自社が何をプラグインでやっているか」で決まります。
ビルド時間の打ち手は、変換の高速化だけではない
もうひとつ、比較しておくべき選択肢があります。そもそも変換する記事の本数を減らすことです。
このサイトはAstro 7.2の増分ビルドを有効にしており、記事1本の修正なら、再生成されるのはそのページと共通の静的ページだけで済みます。ローカルでの実測では、フルビルド34秒に対して増分ビルドが7秒でした。変換1回あたりを速くするアプローチと、変換の回数を減らすアプローチでは、後者のほうが効き方は大きいという結果です。
ただし増分ビルドには、キャッシュのキー設計を間違えると古いページが配信され続けるという固有の落とし穴があります。この作りこみについては増分ビルドの運用にまとめました。2つは排他ではないので、順番としては増分ビルドを先に検討するほうが投資対効果は読みやすくなります。
なお、ビルド時間と表示速度は別の指標です。読者が体感するのは後者で、そちらは配信するJavaScriptを減らす側の話になります。社内で「サイトが遅い」と言われたとき、それが書き手の待ち時間なのか読者の待ち時間なのかを先に切り分けてください。
次にやること
まず、自社サイトのビルドログで、Markdown変換に何秒使っているかを確認してください。 ビルド全体が遅いのか、変換だけが遅いのかで打ち手が変わります。画像処理や型チェックが支配的なら、Markdownエンジンを替えても体感は動きません。
そのうえで、使っているremark/rehypeプラグインを棚卸ししてください。 自作のものがゼロなら移行の検証は軽く済みます。1つでもあるなら、そのプラグインが何を救済しているのかを、移行を検討する前に把握しておく必要があります。書いた本人が退職している場合、これが一番時間のかかる作業になります。
オウンドメディアのビルド時間の改善、Astroサイトの構成見直し、既存プラグインの棚卸しと移行検証については、グリームハブの開発・AI・自動化のご相談で承っています。記事数と構成によって効く打ち手が変わるため、個別にご相談ください。お問い合わせからどうぞ。
