diff options
Diffstat (limited to 'files/ja/web/http/headers/cache-control/index.md')
| -rw-r--r-- | files/ja/web/http/headers/cache-control/index.md | 125 |
1 files changed, 64 insertions, 61 deletions
diff --git a/files/ja/web/http/headers/cache-control/index.md b/files/ja/web/http/headers/cache-control/index.md index c6250d1858..b7b407fc07 100644 --- a/files/ja/web/http/headers/cache-control/index.md +++ b/files/ja/web/http/headers/cache-control/index.md @@ -4,16 +4,17 @@ slug: Web/HTTP/Headers/Cache-Control tags: - Cache-Control - HTTP - - HTTP Header - - Request header - - Response header - - Reference + - HTTP ヘッダー + - リクエストヘッダー + - レスポンスヘッダー + - リファレンス +browser-compat: http.headers.Cache-Control translation_of: Web/HTTP/Headers/Cache-Control --- {{HTTPSidebar}} -HTTP ヘッダーフィールドの **`Cache-Control`** には、ブラウザーや共有キャッシュ (Proxy, CDN など) の [キャッシュ](/ja/docs/Web/HTTP/Caching) を制御するためのディレクティブ(指示) が、リクエストとレスポンスの両方に含まれています。 +**`Cache-Control`** は HTTP のヘッダーフィールドで、 [キャッシュ](/ja/docs/Web/HTTP/Caching) をブラウザーや共有キャッシュ（プロキシーや CDN など）において制御するためのディレクティブ (指示) を、リクエストとレスポンスの両方で保持します。 <table class="properties"> <tbody> @@ -49,7 +50,7 @@ HTTP ヘッダーフィールドの **`Cache-Control`** には、ブラウザー 標準的な `Cache-Control` ディレクティブは以下のように定義されています。 -| Request | Response | +| リクエスト | レスポンス | | :--------------- | :----------------------- | | `max-age` | `max-age` | | `max-stale` | - | @@ -68,34 +69,34 @@ HTTP ヘッダーフィールドの **`Cache-Control`** には、ブラウザー | - | `stale-while-revalidate` | | `stale-if-error` | `stale-if-error` | -注意: [compatibility table](#browser_compatibility) でサポートされているかを確認してください。解釈できないユーザーエージェントはこれらを無視します。 +注意: [互換性一覧表](#ブラウザーの互換性)で対応状況を確認してください。解釈できないユーザーエージェントはこれらを無視します。 ## 用語集 このドキュメントでは、次の用語が使用されています。すべてではありませんが、仕様書に基づいています。 -- `(HTTP) cache` +- `(HTTP) キャッシュ` - : リクエストとレスポンスを保持し、次のリクエストで再利用するための実装。共有キャッシュまたはプライベートキャッシュのいずれかです。 -- `Shared cache` - - : オリジンサーバーとクライアントの間に存在するキャッシュ(Proxy, CDN など)。1 つのレスポンスを保存し、それを複数のユーザーで再利用します。したがって、開発者は共有キャッシュにパーソナライズされたコンテンツをキャッシュとして保存することは避けるべきです。 -- `Private cache` - - : クライアント内に存在するキャッシュです。_local cache_ 、あるいは単に _browser cache_ などとも呼ばれます。ユーザーのためにパーソナライズされたコンテンツを保存し、再利用できます。 -- `Store response` - - : キャッシュ可能な場合には、レスポンスをキャッシュに保存します。しかし、そのまま再利用されるとは限りません。(通常、"キャッシュ" はレスポンスを保存することを意味します。) -- `Reuse response` +- `共有キャッシュ` + - : オリジンサーバーとクライアントの間に存在するキャッシュ (Proxy, CDN など)。1 つのレスポンスを保存し、それを複数のユーザーで再利用します。したがって、開発者は共有キャッシュにパーソナライズされたコンテンツをキャッシュとして保存することは避けるべきです。 +- `プライベートキャッシュ` + - : クライアント内に存在するキャッシュです。*ローカルキャッシュ*、あるいは単に*ブラウザーキャッシュ*などとも呼ばれます。ユーザーのためにパーソナライズされたコンテンツを保存し、再利用できます。 +- `レスポンスの格納` + - : キャッシュ可能な場合には、レスポンスをキャッシュに保存します。しかし、そのまま再利用されるとは限りません。（通常、「キャッシュ」はレスポンスを保存することを意味します。） +- `レスポンスの再利用` - : キャッシュされたレスポンスを次のリクエストに再利用します。 -- `Revalidate response` +- `レスポンスの再検証` - : オリジンサーバーに、保存されているレスポンスがまだ新しいか確認します。通常は条件付きのリクエストで行います。 -- `Fresh response` +- `新鮮なレスポンス` - : レスポンスが新しい状態であることを示します。これは通常、リクエストの指示に応じて、レスポンスを後続のリクエストに再利用できることを意味します。 -- `Stale response` +- `古いレスポンス` - : レスポンスが古い状態になっていることを示します。これは通常、レスポンスがそのままでは再利用できないことを意味します。キャッシュストレージは古いレスポンスをすぐに削除する必要はありません。なぜなら、再検証によってレスポンスが古いものから再び新しい状態に変わる可能性があるからです。 - `Age` - : レスポンスが生成されてからの経過時間です。レスポンスが新しい状態か古い状態かの基準となります。 ## ディレクティブ -このセクションでは、キャッシュに影響を与えるディレクティブ(レスポンスディレクティブとリクエストディレクティブの両方) を列挙します。 +このセクションでは、キャッシュに影響を与えるディレクティブ（レスポンスディレクティブとリクエストディレクティブの両方）を列挙します。 ### レスポンスディレクティブ @@ -109,7 +110,7 @@ Cache-Control: max-age=604800 キャッシュがこのリクエストを保存し、新鮮なうちに後続のリクエストに再利用できることを示します。 -なお、`max-age` はレスポンスを受信してからの経過時間ではなく、オリジンサーバーでレスポンスが生成されてからの経過時間であることに注意してください。したがって、他のキャッシュ(レスポンスが通ったネットワーク経路上) が 100 秒間保存した場合(レスポンスヘッダーフィールドの `Age` で示される)、ブラウザーキャッシュはその鮮度の有効期間から 100 秒を差し引きます。 +なお、`max-age` はレスポンスを受信してからの経過時間ではなく、オリジンサーバーでレスポンスが生成されてからの経過時間であることに注意してください。したがって、他のキャッシュ（レスポンスが通ったネットワーク経路上）が 100 秒間保存した場合（レスポンスヘッダーフィールドの `Age` で示される）、ブラウザーキャッシュはその鮮度の有効期間から 100 秒を差し引きます。 ``` Cache-Control: max-age=604800 @@ -132,9 +133,9 @@ Cache-Control: s-maxage=604800 Cache-Control: no-cache ``` -キャッシュに、保存されているコンテンツを再利用する際に、必ず更新がないかどうかをチェックさせたい場合は、 `no-cache` を使用する必要があります。これは、キャッシュがオリジンサーバーに各リクエストを再確認することを要求することで実現されます。 +キャッシュに、保存されているコンテンツを再利用する際に、必ず更新がないかどうかをチェックさせたい場合は、 `no-cache` を使用する必要があります。これは、キャッシュがオリジンサーバーに各リクエストを再検証することを要求することで実現されます。 -`no-cache` はキャッシュにレスポンスを保存することを許可しますが、再利用する前に再確認することを要求します。もし、「キャッシュさせない」の意味が実際には「保存させない」であるなら、`no-store` が使用すべきディレクティブです。 +`no-cache` はキャッシュにレスポンスを保存することを許可しますが、再利用する前に再検証することを要求します。もし、「キャッシュさせない」の意味が実際には「保存させない」であるなら、`no-store` が使用すべきディレクティブです。 #### `must-revalidate` @@ -146,7 +147,7 @@ Cache-Control: no-cache Cache-Control: max-age=604800, must-revalidate ``` -HTTP では、キャッシュがオリジンサーバーから切り離されたときに、古いレスポンスを再利用できます。`must-revalidate` はそれを防ぐための方法で、キャッシュは保存されたレスポンスを元のサーバーで再検証するか、それが検証不可能な場合は 504(Gateway Timeout) のレスポンスを生成します。 +HTTP では、キャッシュがオリジンサーバーから切り離されたときに、古いレスポンスを再利用できます。`must-revalidate` はそれを防ぐための方法で、キャッシュは保存されたレスポンスを元のサーバーで再検証するか、それが検証不可能な場合は 504 (Gateway Timeout) のレスポンスを生成します。 #### `proxy-revalidate` @@ -154,7 +155,7 @@ HTTP では、キャッシュがオリジンサーバーから切り離された #### `no-store` -レスポンスディレクティブの `no-store` は、あらゆる種類のキャッシュ(プライベートまたは共有) がこのレスポンスを保存しないようにすることを指示します。 +レスポンスディレクティブの `no-store` は、あらゆる種類のキャッシュが（プライベートであろうと共有であろうと）このレスポンスを保存しないようにすることを指示します。 ``` Cache-Control: no-store @@ -162,7 +163,7 @@ Cache-Control: no-store #### `private` -レスポンスディレクティブの `private` は、レスポンスがプライベートキャッシュ(ブラウザーのローカルキャッシュなど) にのみ保存できることを示します。 +レスポンスディレクティブの `private` は、レスポンスがプライベートキャッシュ（ブラウザーのローカルキャッシュなど）にのみ保存できることを示します。 ``` Cache-Control: private @@ -180,7 +181,7 @@ Cache-Control: private Cache-Control: public ``` -一般に、ページが Basic Auth または Digest Auth で制御されている場合、ブラウザーは `Authorization` ヘッダーを付けてリクエストを送信します。つまり、レスポンスは制限されたユーザー(アカウントを持つユーザー) のみにアクセス制御され、たとえ `max-age` がついていても基本的に共有キャッシュに保存可能ではありません。 +一般に、ページが Basic 認証または Digest 認証で制御されている場合、ブラウザーは `Authorization` ヘッダーを付けてリクエストを送信します。つまり、レスポンスは制限されたユーザー（アカウントを持つユーザー）のみにアクセス制御され、たとえ `max-age` がついていても基本的に共有キャッシュに保存可能ではありません。 その制限を解除するために `public` ディレクティブが使用できます。 @@ -202,17 +203,17 @@ Cache-Control: public, max-age=604800 Cache-Control: must-understand, no-store ``` -キャッシュが `must-understand` をサポートしていない場合は、無視されます。`no-store` も存在する場合は、レスポンスは保存されません。 +キャッシュが `must-understand` に対応していない場合は、無視されます。`no-store` も存在する場合は、レスポンスは保存されません。 -キャッシュが `must-understand` をサポートしている場合、ステータスコードに基づいてキャッシュの要件を理解してレスポンスを保存します。 +キャッシュが `must-understand` に対応している場合、ステータスコードに基づいてキャッシュの要件を理解してレスポンスを保存します。 #### `no-transform` -Intermedialies(仲介者) の中には、さまざまな理由でコンテンツを変換する人がいます。たとえば、転送サイズを小さくするために画像を変換するものなどです。場合によっては、これはコンテンツプロバイダにとって望ましくありません。 +仲介者 (intermedialies) の中には、さまざまな理由でコンテンツを変換するものがあります。たとえば、転送サイズを小さくするために画像を変換するものなどです。場合によっては、これはコンテンツプロバイダーにとって望ましくありません。 -`no-transform` は、仲介者が(キャッシュを実装しているかどうかに関係なく) レスポンスの内容を変換すべきではないことを示します。 +`no-transform` は、仲介者が（キャッシュを実装しているかどうかに関係なく）レスポンスの内容を変換すべきではないことを示します。 -注意: [Google’s Web Light](https://support.google.com/webmasters/answer/6211428) は、そのような仲介者の一種です。これは、キャッシュストアや低速接続のデータを最小化するために画像を変換し、オプトアウトオプションとして `no-transform` をサポートします。 +注意: [Google’s Web Light](https://support.google.com/webmasters/answer/6211428) は、そのような仲介者の一種です。これは、キャッシュストアや低速接続のデータを最小化するために画像を変換し、オプトアウトオプションとして `no-transform` に対応します。 #### `immutable` @@ -229,7 +230,9 @@ Cache-Control: public, max-age=604800, immutable ``` ユーザーがブラウザーをリロードすると、ブラウザーはオリジンサーバーに検証のための条件付きリクエストを送信します。しかし、これらの静的リソースは、ユーザーがブラウザーをリロードしても決して変更されないため、再検証する必要がありません。 -なぜなら、それらは決して変更されないからです。 `immutable` はキャッシュにレスポンスが新鮮な間は不変であることを伝え、サーバーへの不要な条件付きリクエストを回避します。 +`immutable` はキャッシュにレスポンスが新鮮な間は不変であることを伝え、サーバーへの不要な条件付きリクエストを回避します。 + +リソースに cache-busting パターンを使用し、長い `max-age` を適用すると、再検証を避けるために `immutable` も追加することができます。 #### `stale-while-revalidate` @@ -239,7 +242,7 @@ Cache-Control: public, max-age=604800, immutable Cache-Control: max-age=604800, stale-while-revalidate=86400 ``` -上記の例では、レスポンスは 7 日間(604800 s) 新鮮です。7 日後、レスポンスは古くなりますが、キャッシュは翌日(86400 s) のリクエストに再利用できます。ただし、バックグラウンドでレスポンスを再検証することが条件です。 +上記の例では、レスポンスは 7 日間（604800 秒間）は新鮮です。7 日後、レスポンスは古くなりますが、キャッシュは翌日（86400 秒後）のリクエストに再利用できます。ただし、バックグラウンドでレスポンスを再検証することが条件です。 再検証により、キャッシュは再び新鮮になるため、クライアントはその期間中は常に新鮮であったかのように見えます。これにより再検証の遅延ペナルティを効果的にクライアントから隠蔽できます。 @@ -247,13 +250,13 @@ Cache-Control: max-age=604800, stale-while-revalidate=86400 #### `stale-if-error` -レスポンスディレクティブの `stale-if-error` は、オリジンサーバーがエラー(500、502、503、504) でレスポンスを返したときに、キャッシュが古いレスポンスを再利用できることを指示します。 +レスポンスディレクティブの `stale-if-error` は、オリジンサーバーがエラー（500、502、503、504）でレスポンスを返したときに、キャッシュが古いレスポンスを再利用できることを指示します。 ``` Cache-Control: max-age=604800, stale-if-error=86400 ``` -上記の例では、レスポンスは 7 日間(604800 s)新鮮です。7 日を過ぎると古くなりますが、サーバーがエラーでレスポンスを返した場合はさらに 1 日(86400 s) 利用できます。 +上記の例では、レスポンスは 7 日間（604800 秒間）は新鮮です。7 日を過ぎると古くなりますが、サーバーがエラーでレスポンスを返した場合はさらに 1 日（86400 秒間）利用できます。 一定時間経過後、保存されたレスポンスは通常通り古くなります。つまり、オリジンサーバーがエラーレスポンスを送信した場合、クライアントはそのままエラーレスポンスを受信します。 @@ -269,7 +272,7 @@ Cache-Control: no-cache `no-cache` は、キャッシュに新しいレスポンスがある場合でも、クライアントが最新のレスポンスを要求することを可能にします。 -ブラウザーは通常、ユーザーがページを **force reloading** したときに、リクエストに `no-cache` を追加します。 +ブラウザーは通常、ユーザーがページを**強制再読み込み**したときに、リクエストに `no-cache` を追加します。 ### `no-store` @@ -291,17 +294,17 @@ Cache-Control: max-age=3600 上記の場合、`Cache-Control: max-age=604800` のレスポンスが 3 時間前にキャッシュに保存されていた場合、キャッシュはそのレスポンスを再利用できません。 -以下で説明するように、多くのブラウザーは **reloading** 時に、このディレクティブを使用します。 +以下で説明するように、多くのブラウザーは**再読み込み**時に、このディレクティブを使用します。 ``` Cache-Control: max-age=0 ``` -`max-age=0` は `no-cache` の回避策です。多くの古い(HTTP/1.0) キャッシュの実装は `no-cache` をサポートしていないからです。最近のブラウザーは、後方互換性のために `max-age=0` を "reloading" の際に使用し、`no-cache` を使用して "force reloading" を行うようになっています。 +`max-age=0` は `no-cache` の回避策です。多くの古い (HTTP/1.0 の) キャッシュの実装は `no-cache` に対応していないからです。最近のブラウザーは、後方互換性のために `max-age=0` を「再読み込み」の際に使用し、`no-cache` を使用して「強制再読み込み」を行うようになっています。 ### `max-stale` -リクエストディレクティブの `max-stale=N` は、クライアントが*N*秒以内に失効した保存されたレスポンスを許可することを示します。 +リクエストディレクティブの `max-stale=N` は、クライアントが *N* 秒以内に失効した保存されたレスポンスを許可することを示します。 ``` Cache-Control: max-stale=3600 @@ -335,9 +338,9 @@ Cache-Control: min-fresh=600 クライアントは、キャッシュがすでに保存済みのレスポンスを転送する必要があることを示します。キャッシュにレスポンスが保存されている場合、それが再利用されます。 -## Use Cases +## 利用例 -### Preventing storing +### 格納を防止 レスポンスをキャッシュに保存したくない場合は、 `no-store` ディレクティブを使用します。 @@ -354,16 +357,16 @@ Cache-Control: no-cache 理論的には、ディレクティブが衝突した場合、最も制限の厳しいディレクティブが尊重されるべきです。つまり、以下の例は基本的に無意味です。`private`, `no-cache`, `max-age=0`, `must-revalidate` は `no-store` と競合しているからです。 ```plain example-bad -# conflicted +# 競合 Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate -# equivalant to +# 以下のものと等しい Cache-Control: no-store ``` -### Caching static assets with “cache busting” +### “cache busting” における静的資産のキャッシュ -バージョン/ハッシュビルドを持つ静的アセットを構築する場合、ファイル名やクエリ文字列にバージョン/ハッシュを追加することは、キャッシュを管理するための良い方法です。 +バージョン/ハッシュビルドを持つ静的資産を構築する場合、ファイル名やクエリー文字列にバージョン/ハッシュを追加することは、キャッシュを管理するための良い方法です。 例： @@ -373,9 +376,9 @@ Cache-Control: no-store <img src=/assets/hero.png width=900 height=400> ``` -React ライブラリのバージョンは、ライブラリを更新すると変わりますし、`hero.png` も画像を編集すると変わります。そのため、これらは `max-age` を使ってキャッシュに保存するのは難しくなります。 +React ライブラリーのバージョンは、ライブラリーを更新すると変わりますし、`hero.png` も画像を編集すると変わります。そのため、これらは `max-age` を使ってキャッシュに保存するのは難しくなります。 -このような場合、特定の番号のついたバージョンのライブラリを使用し、画像の URL にハッシュを含めることでキャッシュの要求を満たすことができます。 +このような場合、特定の番号のついたバージョンのライブラリーを使用し、画像の URL にハッシュを含めることでキャッシュの要求を満たすことができます。 ```html <!-- index.html --> @@ -383,37 +386,37 @@ React ライブラリのバージョンは、ライブラリを更新すると <img src=/assets/hero.png?hash=deadbeef width=900 height=400> ``` -長い `max-age` 値を追加でき、コンテンツは決して変更されないので `immutable` にできます。 +コンテンツは決して変更されないので、 `max-age` を長い値や `immutable` にすることができます。 ``` # /assets/* Cache-Control: max-age=31536000, immutable ``` -ライブラリを更新したり、画像を編集したりすると、新しいコンテンツは新しい URL を持つはずなので、キャッシュは再利用されません。それを “cache busting” パターンと呼びます。 +ライブラリーを更新したり、画像を編集したりすると、新しいコンテンツは新しい URL を持つはずなので、キャッシュは再利用されません。それを “cache busting” パターンと呼びます。 -長い `max-age` を使用して、HTML レスポンス自体がキャッシュされないようにします。`no-cache` は再バリデーションを引き起こす可能性があり、クライアントは新しいバージョンの HTML レスポンスと静的アセットを正しく受信します。 +`no-cache` を使用して HTML レスポンス自体がキャッシュされないようにしてください。 `no-cache` では再検証することができるので、クライアントが HTML レスポンスや静的資産の新しいバージョンを正しく受信します。 ``` # /index.html Cache-Control: no-cache ``` -注意: `index.html` がベーシック認証またはダイジェスト認証で制御されている場合、`/assets` 以下のファイルは共有キャッシュに保存されません。もし `/assets/` のファイルが共有キャッシュに保存するのに適しているなら、 `public`、`s-maxage` または `must-revalidate` のうちの 1 つが必要です。 +注意: `index.html` が Basic 認証または Digest 認証で制御されている場合、`/assets` 以下のファイルは共有キャッシュに保存されません。もし `/assets/` のファイルが共有キャッシュに保存するのに適しているなら、 `public`、`s-maxage` または `must-revalidate` のうちの 1 つが必要です。 -### Up-to-date contents always +### コンテンツを常に最新にする 動的に生成されるコンテンツや、静的であっても頻繁に更新されるコンテンツでは、ユーザーが常に最新版を受信できるようにしたいものです。 -もし、レスポンスがキャッシュされることを意図していないからといって `Cache-Control` ヘッダーを追加しなければ、予期せぬ結果を引き起こす可能性があります。キャッシュストレージは、ヒューリスティックにキャッシュすることが許されています。したがって、キャッシュに関する何らかの要求がある場合は、常に `Cache-Control` ヘッダーで明示的に示す必要があります。 +もし、レスポンスがキャッシュされることを意図していないからといって `Cache-Control` ヘッダーを追加しなければ、予期せぬ結果を引き起こす可能性があります。キャッシュストレージは、推測でキャッシュすることが許されています。したがって、キャッシュに関する何らかの要求がある場合は、常に `Cache-Control` ヘッダーで明示的に示す必要があります。 -レスポンスに `no-cache` を追加すると、サーバーで再バリデーションが行われるので、毎回新鮮なレスポンスを提供できます。また、クライアントがすでに新しいレスポンスを持っている場合は、`304 Not Modified` とだけレスポンスを返します。 +レスポンスに `no-cache` を追加すると、サーバーで再検証が行われるので、毎回新鮮なレスポンスを提供できます。また、クライアントがすでに新しいレスポンスを持っている場合は、`304 Not Modified` とだけレスポンスを返します。 ``` Cache-Control: no-cache ``` -ほとんどの HTTP/1.0 キャッシュは `no-cache` ディレクティブをサポートしていないので、歴史的には `max-age=0` が回避策として使用されてきました。しかし、`max-age=0` だけでは、キャッシュがオリジンサーバーから切断されたときに、古いレスポンスが再利用される可能性がありました。`must-revalidate` はそれに対応するものです。そのため、以下の例では `no-cache` と同等になっています。 +ほとんどの HTTP/1.0 キャッシュは `no-cache` ディレクティブに対応していないので、歴史的には `max-age=0` が回避策として使用されてきました。しかし、`max-age=0` だけでは、キャッシュがオリジンサーバーから切断されたときに、古いレスポンスが再利用される可能性がありました。`must-revalidate` はそれに対応するものです。そのため、以下の例では `no-cache` と同等になっています。 ``` Cache-Control: max-age=0, must-revalidate @@ -421,19 +424,19 @@ Cache-Control: max-age=0, must-revalidate しかし、今のところ、単に `no-cache` を代わりに使用できます。 -### Clearing an already-stored cache +### 既に格納されたキャッシュのクリア 残念ながら、すでに保存されているレスポンスをキャッシュからクリアするためのキャッシュディレクティブはありません。 クライアントやキャッシュが、あるパスに対する新鮮なレスポンスを保存しており、サーバーへリクエストを送信しない状態を想像してください。そのパスに対してサーバーができることは何もありません。 -代替として `Clear-Site-Data` はブラウザーのキャッシュをクリアできます。しかし、これはサイトの保存されたすべてのレスポンスをクリアするので注意してください。そして、ブラウザーのみで、共有キャッシュはクリアされません。 +代替として `Clear-Site-Data` はブラウザーのキャッシュをクリアできます。しかし、これはあるサイトの保存されたすべてのレスポンスをクリアするので注意してください。そして、クリアされるのはブラウザー内のキャッシュのみで、共有キャッシュはクリアされません。 -## Specifications +## 仕様書 {{Specifications}} -## Browser compatibility +## ブラウザーの互換性 {{Compat}} @@ -441,9 +444,9 @@ Cache-Control: max-age=0, must-revalidate [RFC5861 - HTTP Cache-Control Extensions for Stale Content](https://datatracker.ietf.org/doc/html/rfc5861) [RFC8246 - HTTP Immutable Responses](https://datatracker.ietf.org/doc/html/rfc8246) -## See also +## 関連情報 -- [HTTP Caching FAQ](/ja/docs/Web/HTTP/Caching) +- [HTTP キャッシュの FAQ](/ja/docs/Web/HTTP/Caching) - [Caching Tutorial for Web Authors and Webmasters](https://www.mnot.net/cache_docs/) - [Caching best practices & max-age gotchas](https://jakearchibald.com/2016/caching-best-practices/) - [Cache-Control for Civilians](https://csswizardry.com/2019/03/cache-control-for-civilians/) |