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

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

概要

ネットワークを介したリソースの取得は速度が遅く、コストもかかります。ダウンロードにはクライアントとサーバーの間で複数回のラウンド トリップが必要となることがあり、処理が遅延しページ コンテンツの表示が妨げられます。また、訪問者のデータ費用も増大します。クライアントが以前に取得したレスポンスを再利用してよいかどうかやその有効期限を判断できるよう、すべてのサーバー レスポンスにキャッシュ ポリシーを指定することをおすすめします。

推奨される解決方法

各リソースに明示的なキャッシュ ポリシーを指定します。ポリシーで指定する項目は、そのリソースをキャッシュしてよいかどうか、リソースのキャッシュを許可する相手、キャッシュの有効期限、およびキャッシュ ポリシーの期限が切れた場合の効率的な再検証方法(該当する場合)などです。サーバーからレスポンスを返す際は、次のように Cache-Control および ETag ヘッダーを返す必要があります。

  • Cache-Control では、個別のレスポンスをブラウザや他の中間キャッシュで保存する場合に許可する保存方法と有効期限を定義します。詳しくは、Cache-Control によるキャッシュについての説明をご覧ください。
  • ETag では、再検証トークンを指定します。このトークンは、前回のリクエスト以降にリソースが変更されたかどうかを確認するために、ブラウザから自動的に送信されるものです。詳しくは、ETag によるキャッシュされたレスポンスの検証をご覧ください。

サイトに適したキャッシュ ポリシーを判断するには、次のガイドをご利用ください。

キャッシュ期間は少なくとも 1 週間、静的アセットや更新頻度の低いアセットについては最大で 1 年間とすることをおすすめします。リソースを無効化するタイミングを細かく管理する必要がある場合は、URL フィンガープリントやバージョニングなどの手法の使用をおすすめします。詳しくは、上記の「キャッシュされたレスポンスの無効化と更新」のガイドをご覧ください。