ブラウザのキャッシュを活用する Google Developers

Leverage Browser Caching   |   PageSpeed Insights   |   Google Developers

Expires と Cache-Control

これらのヘッダーでは、ウェブ サーバーから新しいバージョンが提供されているかどうか確認せずに、ブラウザでキャッシュ済みのリソースを使用できる期間を指定します。無条件で適用される「強いキャッシュ ヘッダー」です。設定後にリソースがダウンロードされると、有効期限や最大期間に達するかユーザーがキャッシュを消去するまで、ブラウザはそのリソースに対する GET リクエストを発行しません。

Last-Modified と ETag

Last-Modified は、ブラウザがキャッシュからアイテムを取得するかどうかを判断する際にヒューリスティック（経験則）を適用するという意味で、「弱い」キャッシュ ヘッダーです。

どちらのキャッシュ ヘッダーを使用すべきか

キャッシュできるすべてのリソースで、Expires と Cache-Control: max-age のいずれか、Last-Modified と ETag のいずれかを指定することが大切です。Expires と Cache-Control: max-age の両方、または Last-Modified と ETag の両方を指定すると冗長になります。

URL フィンガープリントの使用

ときどき変更されるリソースの場合、サーバー上でリソースが変更され、サーバーがブラウザに新しいバージョンが提供されたことを通知するまで、ブラウザでリソースをキャッシュしておくことができます。リソースの各バージョンに一意の URL を指定すると、この方法を実現できます。たとえば、「my_stylesheet.css」というリソースがあるとします。このファイル名を「my_stylesheet_fingerprint.css」に変更できます。リソースが変更されると、フィンガープリントも変更されるため、URL も変わります。URL が変更されるとすぐに、ブラウザはリソースの再取得を強制されます。フィンガープリントを使用すると、頻繁に変更されるリソースでも、有効期限をそれより先の方の日付に設定できるようになります。

フィンガープリントの一般的な方法として、ファイルのコンテンツのハッシュをコード化した 128 ビットの 16 進数が使用されます。

もう 1 つの方法は、アプリケーションの 新しいバージョンごとに新しいリリース ディレクトリを作成 して、各バージョンのすべてのアセットをバージョン別のディレクトリに格納することです。この方法にはバージョン間でアセットに変更がない場合でも、URL が変わるため再ダウンロードが強制されるという欠点があります。コンテンツ ハッシュを使用するとこの問題の影響を受けなくなりますが、やや複雑になります。