静的サイトの CI は「依存のインストール」「本体のビルド」「検証」の三層でできている。時間を計ってみると、全体二分半のうち依存インストールが一分四十秒と大半を占めていた。ここだけキャッシュすれば効果が最大になる。
キャッシュキーの設計
キャッシュはロックファイルのハッシュをキーにする。ロックファイルが変わらない限り依存ツリーは同一なので、安全に丸ごと復元できる。
- キー:
deps-${{ hashFiles('package-lock.json') }} - 復元対象: パッケージマネージャのストアディレクトリ
- ロックファイル更新時だけ full install が走り、キャッシュが差し替わる
node_modules を直接キャッシュする方式は、OS やツールチェーンの更新で壊れた実績があったのでやめた。ストア経由の復元なら整合性チェックが働く。
実測
組み替え後、依存インストールは一分四十秒から十二秒になり、CI 全体では二分半から一分弱に縮んだ。ビルド本体のキャッシュ（画像最適化の成果物など）はヒット率が読みにくいため、次の段階として保留した。
まとめ
CI 高速化は「一番遅い層を測ってから、その層だけに手を入れる」のが結局早い。全層を一気にキャッシュ化すると、壊れたときの切り分けが難しくなる。