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

このルールは、サーバーからのレスポンスに明示的なキャッシュ ヘッダーが含まれていないことや、リソースが短時間のみキャッシュされるよう指定されていることを PageSpeed Insights が検出した場合にトリガーされます。

概要

静的なリソースをブラウザでキャッシュすると、ユーザーがサイトに複数回アクセスした場合に時間を節約できます。キャッシュ ヘッダーは小さなサブセット(画像など)だけでなく、キャッシュできる静的なリソースにすべて適用されます。キャッシュできるリソースには、JS ファイル、CSS ファイル、画像ファイル、その他のバイナリ オブジェクト ファイル(メディア ファイル、PDF など)があります。一般に HTML は静的ではないため、デフォルトではキャッシュ可能と見なさないようにしてください。サイトの HTML にとってどのようなキャッシュ ポリシーが適しているか検討する必要があります。

推奨される解決方法

サーバーでブラウザのキャッシュを有効にします。静的なリソースのキャッシュの有効期間は 1 週間以上にしてください。広告やウィジェットなどのサードパーティ リソースの場合は、キャッシュの有効期間を 1 日以上にします。キャッシュ可能なすべてのリソースで、次のような設定をおすすめします:

  • Expires を 1 週間以上、できれば最大で 1 年間先に設定します(より広くサポートされているため、Cache-Control: max-age よりも Expires をおすすめします)。RFC のガイドラインに違反するので、1 年以上先には設定しないでください。
  • リソースの変更時期が正確にわかっている場合は、短い有効期間を設定してもかまいません。ただし、すぐに変更される可能性があるものの、変更時期がわからない場合は、長い有効期間を設定して、URL フィンガープリント(後述)を使用してください。

Expires ヘッダーと Cache-Control: max-age ヘッダー

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

Last-Modifed ヘッダーと ETag ヘッダー

これらのヘッダーでは、キャッシュする目的で、ファイルが同じかどうかをブラウザが判断する方法を指定します。Last-Modified ヘッダーでは、日付を使用します。ETag ヘッダーでは、リソースを一意に識別する値を使用します(ファイルのバージョンやコンテンツ ハッシュが一般的です)。Last-Modified は、ブラウザがキャッシュからアイテムを取得するかどうかを判断する際にヒューリスティック(経験則)を適用するという意味で、「弱い」キャッシュ ヘッダーです。

これらのヘッダーを使用すると、ブラウザでは、ユーザーが明示的にページを再読み込みした場合に条件付きの GET リクエストを発行することで、キャッシュ済みリソースを効率的に更新できます。条件付きの GET では、サーバーでリソースが変更されていない限り、完全なレスポンスは返されないため、完全な GET よりも待ち時間が短くなります。

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

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

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

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

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

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