HTTP キャッシュを使用すると、再アクセス時のページの読み込み時間を短縮できます。
ブラウザがリソースをリクエストすると、リソースを提供するサーバーは、リソースを一時的に保存またはキャッシュに保存する期間をブラウザに伝えることができます。そのリソースに対する後続のリクエストでは、ブラウザはネットワークからリソースを取得するのではなく、ローカルコピーを使用します。
Lighthouse のキャッシュ ポリシー監査が失敗する仕組み
Lighthouse では、キャッシュに保存されていないすべての静的リソースにフラグが付けられます。
Lighthouse では、以下の条件がすべて満たされていれば、リソースはキャッシュ可能と見なされます。
- フォント、画像、メディア ファイル、スクリプト、スタイルシートなどがリソースになります。
- リソースに
200
、203
、または206
の HTTP ステータス コードが含まれている。 - リソースに明示的なキャッシュなしポリシーがない。
ページの監査で不合格だった場合、Lighthouse の結果は 3 列からなるテーブルに一覧表示されます。
URL | キャッシュ可能なリソースのロケーション |
キャッシュ TTL | リソースの現在のキャッシュ期間 |
転送サイズ | フラグ済みのリソースがキャッシュに保存された場合にユーザーが保存するデータの推定値 |
HTTP キャッシュを使用して静的リソースをキャッシュに保存する方法
Cache-Control
HTTP レスポンス ヘッダーを返すようにサーバーを構成します。
Cache-Control: max-age=31536000
max-age
ディレクティブは、リソースをキャッシュに保存する時間をブラウザに指示します。この例では、期間を 31536000
に設定します。これは 1 年に相当します(60 秒 × 60 分 × 24 時間 × 365 日 = 31536000 秒)。
不変の静的アセットは長期間(1 年以上など)キャッシュに保存する必要があります。
リソースの変更と鮮度が重要ではあるものの、キャッシュによる速度のメリットを活用したい場合は、no-cache
を使用します。ブラウザは no-cache
に設定されたリソースをキャッシュに保存しますが、リソースが最新であることを確認するためにまずサーバーをチェックします。
キャッシュ期間を長くするほど良いとは限りません。最終的には、リソースに最適なキャッシュ期間を決定する必要があります。
ブラウザでさまざまなリソースをキャッシュに保存する方法をカスタマイズするためのディレクティブは多数あります。リソースのキャッシュ保存については、HTTP キャッシュ: 防御の最前線のガイドと HTTP キャッシュ動作の構成 Codelab をご覧ください。
Chrome DevTools でキャッシュに保存されたレスポンスを確認する方法
ブラウザがキャッシュから取得しているリソースを確認するには、Chrome DevTools の [ネットワーク] タブを開きます。
[コメント]: <>(以下のリストは web.dev のショートコードですが、どの言語にも英語から翻訳されていません。)1. Control+Shift+J
(Mac では Command+Option+J
)を押して DevTools を開きます。
2. [ネットワーク] タブをクリックします。
Chrome DevTools の [Size] 列は、リソースがキャッシュに保存されていることを確認するのに役立ちます。
Chrome は最もリクエストの多いリソースをメモリ キャッシュから提供します。メモリ キャッシュは非常に高速ですが、ブラウザを閉じると消去されます。
リソースの Cache-Control
ヘッダーが期待どおりに設定されていることを確認するには、HTTP ヘッダーデータを確認します。
- リクエスト テーブルの [名前] 列にあるリクエストの URL をクリックします。
- [Headers] タブをクリックします。
スタック固有のガイダンス
Drupal
[アドミニストレーション] > [構成] > [開発] ページで、[ブラウザとプロキシ キャッシュの最長経過時間] を設定します。Drupal のパフォーマンスに関するリソースをご覧ください。
Joomla
キャッシュをご覧ください。
WordPress
ブラウザ キャッシュをご覧ください。