このルールは、サーバーからのレスポンスにキャッシュ ヘッダーが含まれていないことを PageSpeed Insights が検出した場合、またはリソースが短期間のみキャッシュされるように指定されている場合にトリガーされます。
概要
ネットワーク経由でリソースを取得すると、低速でコストが高くなります。ダウンロードではクライアントとサーバー間で複数のラウンドトリップが必要になる場合があり、処理が遅れ、ページ コンテンツのレンダリングがブロックされるほか、訪問者のデータ費用も発生します。すべてのサーバー レスポンスで、キャッシュ ポリシーを指定する必要があります。これは、以前に取得したレスポンスをクライアントが再利用できるかどうかと、その再利用のタイミングをクライアントが判断できるようにするためです。
推奨事項
各リソースには、リソースをキャッシュに保存できるかどうか、誰によってどれくらいの期間、キャッシュ ポリシーの有効期限が切れた場合に効率的に再検証する方法（該当する場合）という疑問に答える、明示的なキャッシュ ポリシーを指定する必要があります。サーバーはレスポンスを返すときに、Cache-Control ヘッダーと ETag ヘッダーを指定する必要があります。
Cache-Controlは、ブラウザやその他の中間キャッシュで個々のレスポンスをキャッシュに保存できる方法と期間を定義します。詳細については、 Cache-Control を使用したキャッシュをご覧ください。ETagは再検証トークンを提供します。再検証トークンはブラウザから自動的に送信されます。このトークンにより、リソースが前回のリクエスト以降に変更されたかどうかを確認できます。詳細については、 ETag によるキャッシュに保存されたレスポンスの検証をご覧ください。
サイトに最適なキャッシュ ポリシーを決定するには、次のガイドをご覧ください。
キャッシュ期間は、最小で 1 週間にすることをおすすめします。静的アセットや変更頻度の低いアセットの場合は、最大 1 年をおすすめします。リソースを無効にするタイミングを正確に制御する必要がある場合は、URL フィンガープリントまたはバージョニングの手法を使用することをおすすめします。上記の「キャッシュに保存されたレスポンスの無効化と更新」のリンクをご覧ください。
フィードバック
このページはお役に立ちましたか？