カバー画像を全記事に義務づけた途端、ビルド時間が一分台から四分台に伸びた。画像最適化はビルド時に一度だけ払うコストとはいえ、執筆のたびに待つ四分は重い。画質を落とさずにどこまで戻せるか、要因を分解して一つずつ測った。
時間の内訳を測る
まず疑うべきは「どの変換に時間が消えているか」で、ログを足すと内訳は明快だった。
- 変換幅のバリエーション生成が全体の六割
- AVIF エンコードが三割
- 残りがメタデータ処理とファイル IO
つまり「幅 × フォーマット」の組み合わせ爆発が主犯で、コードの遅さではない。
変換幅を間引く
レイアウト上、カバーが表示される最大幅は決まっている。デバイスピクセル比 2 を掛けても、用意すべき幅は三種で足りた。既定で六種生成していた設定を三種に絞るだけで、生成時間はほぼ半減した。
フォーマットとキャッシュ
フォーマットは AVIF 単独をやめ、閲覧環境の分布を見て WebP との併用に戻した。さらに変換結果をコンテンツハッシュでキャッシュし、変更のない画像の再変換をスキップする。この二手で、二回目以降のビルドは画像点数に関わらずほぼ一定時間になった。
まとめ
最終的にフルビルドは四分十秒から二分五秒へ、差分ビルドは一分十秒前後まで戻った。目視での画質差は見つけられていない。「全部の幅・全部のフォーマット」という初期設定は安心のための過剰装備で、レイアウトの実測から逆算すれば大胆に間引ける——という、当たり前だが測るまで確信できなかった話。