HTTP キャッシュを使用して不要なネットワーク リクエストを防止する

ネットワーク経由でのリソースの取得は、時間とコストがかかります。

• レスポンスのサイズが大きいと、ブラウザとサーバー間で多数のラウンドトリップが必要になります。
• ページは、すべての重要なリソースのダウンロードが完了するまで読み込まれません。
• あるユーザーがモバイルデータ プランに制限のあるサイトにアクセスしている場合、不要なネットワーク リクエストが発生するたびにお金の無駄遣いになります。

不要なネットワーク リクエストを回避するにはどうすればよいでしょうか。防御の最前線は、ブラウザの HTTP キャッシュです。この方法は、必ずしも最も強力で柔軟な方法というわけではなく、キャッシュに保存されたレスポンスの存続期間を制御するのは限定的ですが、効果的で、すべてのブラウザでサポートされるため、多くの作業は必要ありません。

このガイドでは、効果的な HTTP キャッシュ実装の基本について説明します。

ブラウザの互換性

実際には、HTTP キャッシュと呼ばれる単一の API はありません。ウェブ プラットフォーム API のコレクションの総称です。これらの API は、すべてのブラウザでサポートされています。

Cache-Control

ETag

Last-Modified

HTTP キャッシュの仕組み

ブラウザが実行するすべての HTTP リクエストは、まずブラウザ キャッシュにルーティングされ、リクエストの実行に使用できる有効なキャッシュ レスポンスがあるかどうかが確認されます。一致する場合、レスポンスがキャッシュから読み取られるため、ネットワーク レイテンシと転送によって発生するデータコストの両方を排除できます。

HTTP キャッシュの動作は、リクエスト ヘッダーとレスポンス ヘッダーの組み合わせによって制御されます。リクエスト ヘッダーを決めるウェブ アプリケーションのコードとウェブサーバーの構成（レスポンス ヘッダーを決定）の両方を、ユーザーが管理できるようにすることが理想的です。

コンセプトの概要について詳しくは、MDN の HTTP キャッシュ保存の記事をご覧ください。

リクエスト ヘッダー: デフォルトのまま（通常）

ウェブアプリの送信リクエストには、多くの重要なヘッダーを含める必要がありますが、リクエストを行う際、ほとんどの場合、ブラウザがユーザーに代わってヘッダーを設定します。鮮度の確認に影響するリクエスト ヘッダー（If-None-Match や If-Modified-Since など）は、ブラウザで認識されている HTTP キャッシュの現在の値に基づいて表示されます。

これは朗報です。HTML に <img src="my-image.png"> などのタグをそのまま追加すれば、手間をかけずにブラウザが自動的に HTTP キャッシュを処理します。

<ph type="x-smartling-placeholder">

レスポンス ヘッダー: ウェブサーバーを構成する

HTTP キャッシュ設定で最も重要な部分は、ウェブサーバーが各送信レスポンスに追加するヘッダーです。以下のヘッダーはすべて、効果的なキャッシュ動作の要因となります。

• Cache-Control。サーバーは Cache-Control ディレクティブを返して、ブラウザや他の中間キャッシュに個々のレスポンスをキャッシュする方法と、キャッシュする期間を指定できます。
• ETag。ブラウザは、キャッシュに保存されている期限切れのレスポンスを見つけると、小さなトークン（通常はファイルの内容のハッシュ）をサーバーに送信して、ファイルが変更されたかどうかを確認します。サーバーから同じトークンが返された場合、ファイルは同じものであるため、再ダウンロードする必要はありません。
• Last-Modified。このヘッダーは ETag と同じ目的を果たしますが、コンテンツ ベースの戦略である ETag とは対照的に、時間ベースの戦略を使用してリソースが変更されたかどうかを判断します。

ウェブサーバーによっては、これらのヘッダーをデフォルトで設定するための組み込みサポートが組み込まれている場合や、明示的に構成しない限り、ヘッダーが完全に省略される場合もあります。ヘッダーの設定方法の詳細は、使用するウェブサーバーによって大きく異なります。最も正確な情報を得るには、サーバーのドキュメントをご覧ください。

ここでは、一般的なウェブサーバーの構成手順を説明します。

• Express
• Apache
• nginx
• Firebase Hosting
• Netlify

Cache-Control レスポンス ヘッダーを省略しても、HTTP キャッシュは無効になりません。その代わり、ブラウザは特定の種類のコンテンツに対してどのようなキャッシュ動作が最も理にかなっているかを実質的に推測します。このオファーよりも細かい制御が必要な場合は、時間をかけてレスポンス ヘッダーを設定してください。

どのレスポンス ヘッダー値を使用すればよいですか。

ファイアウォール ルールの設定時に考慮すべき 2 つの重要なシナリオがあります。 ウェブサーバーのレスポンス ヘッダー。

バージョニングされた URL の長期保存キャッシュ

「fingerprint」を含む URL のリクエストに応答するときまたはバージョニング情報で、内容が変更される意図のないファイルについては、レスポンスに Cache-Control: max-age=31536000 を追加します。

この値を設定すると、ブラウザでは今後 1 年間（サポートされている最大値の 31,536,000 秒）に同じ URL を読み込む必要がある場合、ウェブサーバーに対してネットワーク リクエストを行わなくても、HTTP キャッシュ内の値をすぐに使用することができます。すばらしい。ネットワークを使わないと得られる信頼性とスピードがすぐに得られるということです。

webpack などのビルドツールを使用すると、ハッシュ フィンガープリントをアセット URL に割り当てるプロセスを自動化できます。

<ph type="x-smartling-placeholder">

バージョン管理されていない URL のサーバー再検証

残念ながら、読み込むすべての URL がバージョン管理されているわけではありません。ウェブアプリをデプロイする前にビルドステップを含めることができず、アセット URL にハッシュを追加できない場合もあります。また、すべてのウェブ アプリケーションには HTML ファイルが必要です。これらのファイルにバージョニング情報が含まれることはほとんどありません。アクセスする URL が https://example.com/index.34def12.html であることを覚えておく必要があれば、誰もウェブアプリを使用する必要がなくなるからです。では、それらの URL に対してどうすればよいでしょうか。

これは失敗を認める必要があるシナリオの 1 つです。ネットワークを完全に回避するには、HTTP キャッシュだけでは不十分です。（心配は無用です。Service Worker については後ほど説明します。Service Worker は、戦いを有利に進めるために必要なサポートを提供します）。ただし、ネットワーク リクエストを可能な限り迅速かつ効率的に行うために実行できるステップがいくつかあります。

次の Cache-Control 値は、バージョニングされていない URL をキャッシュする場所と方法を微調整するのに役立ちます。

• no-cache。これにより、キャッシュされた URL を使用する前に、毎回サーバーで再検証を行うようブラウザに指示します。
• no-store。これにより、ブラウザとその他の中間キャッシュ（CDN など）にファイルのどのバージョンも保存されなくなります。
• private。ブラウザはファイルをキャッシュに保存できますが、中間キャッシュはできません。
• public。レスポンスは任意のキャッシュに保存できます。

使用する Cache-Control 値を決定するプロセスを視覚化するには、付録: Cache-Control フローチャートをご覧ください。Cache-Control には、ディレクティブのカンマ区切りのリストを指定することもできます。付録: Cache-Control の例をご覧ください。

ETag または Last-Modified の設定も役立ちます。レスポンス ヘッダーで説明したように、ETag と Last-Modified はどちらも同じ目的を果たし、期限切れのキャッシュ ファイルをブラウザが再ダウンロードする必要があるかどうかを判断します。より正確な ETag の使用をおすすめします。

ETag または Last-Modified を設定すると、リクエスト ヘッダーに記載されている If-Modified-Since または If-None-Match リクエスト ヘッダーを、再検証リクエストからトリガーできるため、効率性が大幅に向上します。

適切に構成されたウェブサーバーは、これらの受信リクエスト ヘッダーを認識することで、ブラウザにすでに HTTP キャッシュに保存されているリソースのバージョンがウェブサーバー上の最新バージョンと一致するかどうかを確認できます。一致するものがある場合、サーバーは 304 Not Modified HTTP レスポンスで応答できます。これは、「すでに持っているものを使い続ける」と同等です。このタイプのレスポンスを送信する際、転送するデータはほとんどないため、通常はリクエストされた実際のリソースのコピーを実際に返送するよりもはるかに高速です。

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">

をご覧ください。

概要

HTTP キャッシュを使用すると、不要なネットワーク リクエストを減らせるため、読み込みパフォーマンスの改善に効果的です。すべてのブラウザでサポートされているため、それほど手間のかからない設定です。

まずは、次の Cache-Control 構成をおすすめします。

• Cache-Control: no-cache: 使用前にサーバーで再検証する必要があるリソース。
• Cache-Control: no-store: キャッシュに保存してはならないリソース。
• バージョニングされたリソースの場合は Cache-Control: max-age=31536000。

また、ETag ヘッダーまたは Last-Modified ヘッダーは、期限切れのキャッシュ リソースをより効率的に再検証するのに役立ちます。

<ph type="x-smartling-placeholder">

その他の情報

Cache-Control ヘッダーの基本的な使用方法については、Jake Archibald のキャッシュのベスト プラクティスと最大年齢の注意点のガイドをご覧ください。

リピーターのためにキャッシュの使用を最適化する方法については、キャッシュの活用に関する記事をご覧ください。

付録: その他のヒント

時間があれば、以下の方法で HTTP キャッシュの使用を最適化できます。

• 一貫した URL を使用する。同じコンテンツを複数の URL で提供すると、そのコンテンツは複数回取得、保存されます。
• チャーンを最小限に抑える。リソースの一部（CSS ファイルなど）は頻繁に更新され、ファイルの残りの部分（ライブラリ コードなど）は更新されないので、頻繁に更新されるコードを別のファイルに分割し、頻繁に更新されるコードには短期のキャッシュ戦略を、頻繁に変更されないコードには長期のキャッシュ戦略を使用することを検討してください。
• Cache-Control ポリシーである程度の未更新が許容される場合は、新しい stale-while-revalidate ディレクティブを確認してください。

付録: Cache-Control フローチャート

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">

付録: Cache-Control の例