HTTP キャッシュを使用すると、再訪問時のページの読み込み時間を短縮できます。
ブラウザがリソースをリクエストすると、 そのリソースを提供するサーバーは、そのリソースに関する情報を リソースを一時的に保存またはキャッシュに保存する期間。 そのリソースに対する後続のリクエストでは ブラウザはネットワークから取得するのではなく、ローカルコピーを使用します。
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. [Network] タブをクリックします。
Chrome DevTools の [Size] 列は、リソースがキャッシュに保存されたことを確認するのに役立ちます。
Chrome はリクエストが最も多いリソースをメモリ キャッシュから提供します。これは非常に高速です。 ブラウザを閉じると消去されます。
リソースの Cache-Control
ヘッダーが想定どおりに設定されていることを確認するには、次のようにします。
HTTP ヘッダーデータを確認します。
- リクエスト表の [名前] 列で、リクエストの URL をクリックします。
- [Headers] タブをクリックします。
スタック固有のガイダンス
Drupal
[アドミニストレーション] > [ブラウザとプロキシ キャッシュの最長存続期間] を設定します。 設定 >Development ページ。Drupal のパフォーマンス リソースをご覧ください。
Joomla
キャッシュをご覧ください。
WordPress
ブラウザ キャッシュをご覧ください。