Astroのビルドを速く保つための見直しポイント：遅くなる前に見る場所を決める
このサイトのビルドは2段構えです。astro build でサイト本体を生成したあと、Pagefind がその成果物を走査して検索インデックスを作ります。今のところ記事数も画像も少ないので、ビルド時間で困ってはいません。
ただ、記事と画像はこれから増える一方です。ビルドは「ある日いきなり遅くなる」というより、コンテンツの増加に引きずられて少しずつ伸びていくものなので、遅くなってから慌てて原因を探すのは効率が悪い。そこで、伸びてきたときにまず見る場所と、やる対策・やらない対策を先に決めておくことにしました。実測値の話ではなく、点検の順番を決めるメモです。
まず「どこで時間を使っているか」を分ける
体感で「なんか遅くなった」と思っても、合計の時間だけでは手の打ちようがありません。このサイトの場合は、次の順番で切り分けます。
astro buildと Pagefind を別々に実行し、それぞれtimeを付けて計る。2段構えのビルドは、合計時間だけ見てもどちらの段が伸びたのか分からないためです- Pagefind の実行結果を見る。インデックスしたページ数と所要時間がそのまま出力されるので、「ページ数がどれだけ増えたら、後段がどれだけ伸びるか」を並べて追えます
astro build側のログを追う。どの段階の処理で長く止まっているかを見て、画像処理なのかページ生成なのかの当たりを付けます（詳しいログが要る場合は--verboseフラグも使えます）- 設定や素材を変えたら、変えたのは1回に1つだけにして計り直す。複数を同時に変えると、効いたのがどれか分からなくなります
計測についての注意：最近のAstro（7.4以降）には
astro build --timingsという、ビルドの内訳を表示するフラグがあります。ただ、このサイトはAstro 5なので、そのフラグはまだ使えません。「2段に分けて計る」という地味な方法が、Astro 5での現実解です。
伸びやすい場所はだいたい決まっている
ビルドが伸びる要因は、サイトの作りからだいたい予想がつきます。このサイトで点検対象にしているのは次の5つです。
| 場所 | なぜ伸びるか | 見るべき兆候 |
|---|---|---|
| 画像の最適化 | src/ 配下に置いた画像は、ビルド時に変換・リサイズの対象になる。<Picture /> やレスポンシブ表示の設定は複数サイズ・複数フォーマットを生成するので、処理量は「画像の枚数 × 生成パターン数」で増えていく | 画像を足した変更のあとで伸びている |
| ページ生成 | 記事が1本増えると、増えるのは記事ページだけではない。一覧ページ、タグ別のページ、RSSなど、記事に連動して生成されるページも一緒に増える | 記事数の増加とほぼ同じ歩調で伸びている |
| Pagefind のインデックス | ビルド成果物のHTMLを全ページ走査して検索インデックスを作る処理なので、対象ページが増えればその分伸びる。検索に出す必要のないページまで対象に入っていると、無駄も増える | astro build は変わらないのに、後段だけ伸びている |
| フォントなどのアセット | フォントファイルもビルドで処理・配置される対象。ウェイトや文字種を無造作に増やせば、その分だけ処理するものが増える | フォントや大きな素材を足した変更で伸びている |
| 依存とインテグレーション | ビルドの過程で読み込まれて動くものが増えれば、その分だけ仕事は増える。使っていないものが残っていると、払わなくていいコストを払い続けることになる | 依存を足した変更のあとで、全体的に伸びている |
裏を返すと、このサイトのビルドの伸びしろは、ほぼコンテンツの増え方で決まります。だから対策も「ビルドの仕組みを速くする」より「処理対象を無駄に増やさない」側が中心になります。
効く対策は「対象を増やさない」側にある
画像の置き場と原画にルールを付ける
一番効くのは画像です。Astro では、画像の置き場によって扱いがはっきり分かれます。src/ 配下の画像は最適化の対象になり、public/ に置いた画像は最適化されず、そのままコピーされます（公式ドキュメントにもそう書かれています）。つまり「どの画像がビルド時に処理されるか」は、置き場の時点で決まっているわけです。置き場と最適化の基本については、Astroの画像最適化を標準の astro:assets に寄せるで整理しました。
その前提で、自分のルールはこう決めています。
- 最適化したい画像だけを
src/に入れ、<Image />などから使う - 原画は置く前に縮小しておく。上限はこのサイトのレイアウト幅を基準に決め、「表示される幅に対して過大な原画を置かない」ことをルールにする
- フォーマットやサイズの生成パターンは、必要な分だけにする。バリエーションを増やすほど1枚あたりの処理は増える
画像まわりの決めごと：原画は縮小してから置く／最適化対象にしたい画像だけを
src/に入れる／生成パターンは必要最小限にする。この3つで、画像が原因の伸びはかなり抑えられるはずです。
連動して生成されるページと、検索の対象を棚卸しする
記事が増えること自体は止めようがありません。見直せるのは、その周辺です。タグ別ページのように自動で生成されるページは、本当に使われている分類だけになっているか。Pagefind のインデックス対象は、検索結果に出したいページだけに絞れているか。Pagefind にはインデックス対象を調整する設定があるので、「全ページを対象にする」を初期状態のままにしない、というのが地味に効きます。導入手順とインデックス範囲の指定方法そのものは、Pagefindで静的サイトに検索を足す手順と注意点にまとめています。
依存は「足したら、たまに眺める」
インテグレーションやパッケージは、入れたときには必要でも、後から不要になっていることがあります。ビルドの点検のついでに依存の一覧を眺めて、使っていないものがあれば外す。これはビルド時間のためというより、保守の負債を増やさないための習慣です。
やらない方がいい対策
速くすること自体が目的になると、かえって損な手もあります。自分の線引きは次のとおりです。
| やらないこと | 理由 |
|---|---|
| キャッシュが効いた状態の時間を「ビルド時間」だと思い込む | 手元の環境で速く見えても、デプロイ先のようにまっさらな状態から始まるビルドでは同じ時間にならない。判断はクリーンな状態で計った時間でしたい |
| 画像の最適化自体を止めて速く見せる | 処理を省けばビルドは速くなるが、重い画像がそのまま配信されるだけ。ビルド時間の問題を、読み手側の表示速度の問題に付け替えている |
| 計測なしで設定をいじる | 効いたかどうか分からない変更は、次に遅くなったときの切り分けを難しくするだけ。変えるなら1つずつ、計りながら |
点検の順番をチェックリストにしておく
最後に、この記事の内容をそのまま点検手順として残しておきます。ビルドが伸びたと感じたら、上から順に見る、という使い方です。
astro buildと Pagefind を分けて計り、どちらの段が伸びたかを確認する- 画像を足した時期と重なるなら、原画の大きさと置き場（
src/かpublic/か）を見る - 記事数の増加と歩調が合うなら、連動生成されるページと Pagefind のインデックス対象を見る
- 依存を足した時期と重なるなら、使っていないものが残っていないか眺める
- 対策を入れたら、変更は1つだけにして計り直す。判断はクリーンな状態の時間でする
この順番さえ決まっていれば、ビルドが伸び始めても「どこから手をつけるか」で迷う時間は減るはずです。速さそのものより、遅くなった理由にすぐたどり着ける状態を保つ、というのがこのサイトの方針です。