キャッシュバスティングとは何か? アセットの再ダウンロードを強制する

キャッシュバスティングは、コンテンツが変わったときにアセットの URL を変え、ブラウザや CDN が古いキャッシュコピーではなく新しいバージョンを取得するよう強制します。

積極的なキャッシュは速度には有利ですが、デプロイで同じ URL の下に新しいコードを出荷すると、ユーザーが古いキャッシュファイルを持ち続けるため危険です。キャッシュバスティングは、コンテンツが変わるたびに URL を変えることでこれを解決します。現代的なアプローチは、ビルドでの content hashing によってこれを自動化し、デプロイとキャッシュを同期させます。

古いアセットの問題

app.js が長期間キャッシュされていて、同じ URL に新しい app.js をデプロイすると、再訪ユーザーは古いファイルを実行し続けます。キャッシュバスティングは、コンテンツの変更が URL の変更を意味するようにするため、キャッシュが古いバージョンを配信できなくなります。

content hashing がキャッシュを破る仕組み

ビルドは各ファイルのコンテンツのハッシュを、app.4f3a9b.js のようにファイル名に埋め込みます。コンテンツを変えるとハッシュが変わり、キャッシュがまだ見たことのない新しいファイル名と新しい URL が生成されます。

ハッシュがクエリ文字列に勝る理由

新しいファイル名は、キャッシュにとって明確に新しいリソースです。
古いファイルはキャッシュに残せるため、処理中のユーザーが壊れません。
変わっていないファイルは名前を保ち、キャッシュされたままになります。

HTML との連携

HTML は新しいハッシュ付きファイル名を参照する必要があるため、アセットほど長くはキャッシュできません。デプロイごとに HTML が更新されて新しいハッシュを指し、長期キャッシュされたアセットがそれに続きます。

CI/CD におけるキャッシュバスティング

ビルドは content-hash 付きのファイル名を自動的に出力し、deploy は新しいファイルを古いものと並べてアップロードします。つまり、一般的なケースではキャッシュバスティングに手動のキャッシュフラッシュは不要です。新しいコンテンツを出荷すれば新しい URL が出荷され、CDN が正しく配信します。

重要なポイント

キャッシュバスティングは、古いキャッシュを打ち破るために、コンテンツが変わったときにアセットの URL を変えます。
ファイル名の content hash が、キャッシュバスティングを自動かつ精密にします。
CI はハッシュ付きファイルを出力するため、一般的なケースではデプロイ時に手動のキャッシュフラッシュが不要です。