cachingなどを日本語訳して追加

1 files changed, 60 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 5d2e2a1706..aeaa927899 100644
--- a/files/ja/web/http/headers/cache-control/index.md
+++ b/files/ja/web/http/headers/cache-control/index.md
@@ -13,8 +13,7 @@ translation_of: Web/HTTP/Headers/Cache-Control
 
 {{HTTPSidebar}}
 
-
-HTTPヘッダーフィールドの **`Cache-Control`** には、ブラウザやshared caches(Proxy, CDN など)の[caching](/en-US/docs/Web/HTTP/Caching)を制御するためのdirective(指示)が、リクエストとレスポンスの両方に含まれています。
+HTTP ヘッダーフィールドの **`Cache-Control`** には、ブラウザーや共有キャッシュ (Proxy, CDN など) の [キャッシュ](/en-US/docs/Web/HTTP/Caching) を制御するためのディレクティブ (指示) が、リクエストとレスポンスの両方に含まれています。
 
 <table class="properties">
   <tbody>
@@ -40,13 +39,13 @@ HTTPヘッダーフィールドの **`Cache-Control`** には、ブラウザやs
 
 ## 構文
 
-Cache のディレクティブには、以下のような規則があります。
+キャッシュのディレクティブには、以下のような規則があります。
 
 - 大文字と小文字は区別されませんが、実装によっては大文字のディレクティブを認識しないものもあるので、小文字を推奨します。
 - 複数のディレクティブはカンマで区切ります。
 - いくつかのディレクティブにはオプションの引数があります。
 
-### Cache directives
+### キャッシュディレクティブ
 
 標準的な `Cache-Control` ディレクティブは以下のように定義されています。
 
@@ -76,41 +75,41 @@ Cache のディレクティブには、以下のような規則があります�
 このドキュメントでは、次の用語が使用されています。すべてではありませんが、仕様書に基づいています。
 
 - `(HTTP) cache`
-  - : リクエストとレスポンスを保持し、次のリクエストで再利用するための実装。Shared cache または Private cache のいずれかです。
+  - : リクエストとレスポンスを保持し、次のリクエストで再利用するための実装。共有キャッシュまたはプライベートキャッシュのいずれかです。
 - `Shared cache`
-  - : オリジンサーバーとクライアントの間に存在する cache (Proxy, CDN など)。1 つのレスポンスを保存し、それを複数のユーザーで再利用します。したがって、開発者は Shared cache にパーソナライズされたコンテンツを cache として保存することは避けるべきです。
+  - : オリジンサーバーとクライアントの間に存在するキャッシュ(Proxy, CDN など)。1 つのレスポンスを保存し、それを複数のユーザーで再利用します。したがって、開発者は共有キャッシュにパーソナライズされたコンテンツをキャッシュとして保存することは避けるべきです。
 - `Private cache`
-  - : クライアント内に存在する cache です。_local cache_ 、あるいは単に _browser cache_ などとも呼ばれます。ユーザーのためにパーソナライズされたコンテンツを保存し、再利用することができます。
+  - : クライアント内に存在するキャッシュです。_local cache_ 、あるいは単に _browser cache_ などとも呼ばれます。ユーザーのためにパーソナライズされたコンテンツを保存し、再利用することができます。
 - `Store response`
-  - : cache 可能な場合には、レスポンスを cache に保存します。しかし、そのまま再利用されるとは限りません。(通常、"cache" はレスポンスを保存することを意味します。)
+  - : キャッシュ可能な場合には、レスポンスをキャッシュに保存します。しかし、そのまま再利用されるとは限りません。(通常、"キャッシュ" はレスポンスを保存することを意味します。)
 - `Reuse response`
-  - : cache されたレスポンスを次のリクエストに再利用します。
+  - : キャッシュされたレスポンスを次のリクエストに再利用します。
 - `Revalidate response`
   - : オリジンサーバーに、保存されているレスポンスがまだ新しいか確認します。通常は条件付きのリクエストで行います。
 - `Fresh response`
   - : レスポンスが新しい状態であることを示します。これは通常、リクエストの指示に応じて、レスポンスを後続のリクエストに再利用できることを意味します。
 - `Stale response`
-  - : レスポンスが古い状態になっていることを示します。これは通常、レスポンスがそのままでは再利用できないことを意味します。Cache storage は古いレスポンスをすぐに削除する必要はありません。なぜなら、再検証によってレスポンスが古いものから再び新しい状態に変わる可能性があるからです。
+  - : レスポンスが古い状態になっていることを示します。これは通常、レスポンスがそのままでは再利用できないことを意味します。キャッシュストレージは古いレスポンスをすぐに削除する必要はありません。なぜなら、再検証によってレスポンスが古いものから再び新しい状態に変わる可能性があるからです。
 - `Age`
   - : レスポンスが生成されてからの時間です。レスポンスが新しい状態か古い状態かの基準となります。
 
 ## ディレクティブ
 
-このセクションでは、cache に影響を与えるディレクティブ (応答ディレクティブと要求ディレクティブの両方) を列挙します。
+このセクションでは、キャッシュに影響を与えるディレクティブ (応答ディレクティブと要求ディレクティブの両方) を列挙します。
 
-###　レスポンスディレクティブ
+### レスポンスディレクティブ
 
 #### `max-age`
 
-レスポンスディレクティブの`max-age=N` は、レスポンスが生成されてから _N_  秒後まで、レスポンスが新鮮なままであることを示します。
+レスポンスディレクティブの`max-age=N` は、レスポンスが生成されてから _N_ 秒後まで、レスポンスが新鮮なままであることを示します。
 
 ```
 Cache-Control: max-age=604800
 ```
 
-cache がこのリクエストを保存し、新鮮なうちに後続のリクエストに再利用できることを示す。
+キャッシュがこのリクエストを保存し、新鮮なうちに後続のリクエストに再利用できることを示す。
 
-なお、`max-age` はレスポンスを受信してからの経過時間ではなく、オリジンサーバーでレスポンスが生成されてからの経過時間であることに注意してください。したがって、他の cache (レスポンスが通ったネットワークルート上) が 100 秒間保存した場合（レスポンスヘッダーフィールドの `age` で示される）、ブラウザキャッシュはその鮮度の有効期間から 100 秒を差し引いたものになります。
+なお、`max-age` はレスポンスを受信してからの経過時間ではなく、オリジンサーバーでレスポンスが生成されてからの経過時間であることに注意してください。したがって、他のキャッシュ (レスポンスが通ったネットワークルート上) が 100 秒間保存した場合（レスポンスヘッダーフィールドの `age` で示される）、ブラウザキャッシュはその鮮度の有効期間から 100 秒を差し引いたものになります。
 
 ```
 Cache-Control: max-age=604800
@@ -119,7 +118,7 @@ Age: 100
 
 #### `s-maxage`
 
-レスポンスディレクティブの `s-maxage` も、レスポンスが新鮮である期間を示します (`max-age` に似ています)。しかし、これは shared caches 特有のもので、shared caches は `max-age` が存在する場合は無視します。
+レスポンスディレクティブの `s-maxage` も、レスポンスが新鮮である期間を示します (`max-age` に似ています)。しかし、これは共有キャッシュ特有のもので、共有キャッシュは `max-age` が存在する場合は無視します。
 
 ```
 Cache-Control: s-maxage=604800
@@ -127,19 +126,19 @@ Cache-Control: s-maxage=604800
 
 #### `no-cache`
 
-レスポンスディレクティブの `no-cache` は、caches に保存できることを示しますが、caches がオリジンサーバーから切断された場合でも、再利用の前にオリジンサーバーで検証しなければなりません。
+レスポンスディレクティブの `no-cache` は、キャッシュに保存できることを示しますが、キャッシュがオリジンサーバーから切断された場合でも、再利用の前にオリジンサーバーで検証しなければなりません。
 
 ```
 Cache-Control: no-cache
 ```
 
-caches に常にコンテンツの更新をチェックさせる一方で、保存されているコンテンツに変更がない場合再利用させたい場合は、`no-cache` を使用する必要があります。これは、caches がオリジンサーバーに各リクエストを再確認することを要求することで実現されます。
+キャッシュに常にコンテンツの更新をチェックさせる一方で、保存されているコンテンツに変更がない場合再利用させたい場合は、`no-cache` を使用する必要があります。これは、キャッシュがオリジンサーバーに各リクエストを再確認することを要求することで実現されます。
 
-`no-cache` は caches にレスポンスを保存することを許可しますが、再利用する前に再確認することを要求します。もし、「caches しない」の意味が実際には「保存しない」であるなら、`no-store` が使用すべきディレクティブです。
+`no-cache` はキャッシュにレスポンスを保存することを許可しますが、再利用する前に再確認することを要求します。もし、「キャッシュしない」の意味が実際には「保存しない」であるなら、`no-store` が使用すべきディレクティブです。
 
 #### `must-revalidate`
 
-レスポンスディレクティブの `must-revalidate` は、レスポンスが caches に保存され、新鮮なうちは再利用できることを示します。古くなったレスポンスは、再利用する前にオリジンサーバで検証されなければなりません。
+レスポンスディレクティブの `must-revalidate` は、レスポンスがキャッシュに保存され、新鮮なうちは再利用できることを示します。古くなったレスポンスは、再利用する前にオリジンサーバで検証されなければなりません。
 
 通常、`must-revalidate` は `max-age` と共に使用されます。
 
@@ -147,15 +146,15 @@ caches に常にコンテンツの更新をチェックさせる一方で、保�
 Cache-Control: max-age=604800, must-revalidate
 ```
 
-HTTP では、caches がオリジンサーバーから切り離されたときに、古いレスポンスを再利用することができます。`must-revalidate` はそれを防ぐための方法で、caches は保存されたレスポンスを元のサーバーで再検証するか、それが再利用不可能な場合は 504 (Gateway Timeout) のレスポンスを生成します。
+HTTP では、キャッシュがオリジンサーバーから切り離されたときに、古いレスポンスを再利用することができます。`must-revalidate` はそれを防ぐための方法で、キャッシュは保存されたレスポンスを元のサーバーで再検証するか、それが再利用不可能な場合は 504 (Gateway Timeout) のレスポンスを生成します。
 
 #### `proxy-revalidate`
 
-レスポンスディレクティブの `proxy-revalidate` は `must-revalidate` と同等ですが、shared caches にのみ適用されます。
+レスポンスディレクティブの `proxy-revalidate` は `must-revalidate` と同等ですが、共有キャッシュにのみ適用されます。
 
 #### `no-store`
 
-レスポンスディレクティブの `no-store` は、あらゆる種類の caches (private または shared) がこのレスポンスを保存しないようにすることを指示します。
+レスポンスディレクティブの `no-store` は、あらゆる種類のキャッシュ(プライベートまたは共有) がこのレスポンスを保存しないようにすることを指示します。
 
 ```
 Cache-Control: no-store
@@ -163,7 +162,7 @@ Cache-Control: no-store
 
 #### `private`
 
-レスポンスディレクティブの `private` は、レスポンスが private cache (ブラウザの local caches など) にのみ保存されることを示します。
+レスポンスディレクティブの `private` は、レスポンスがプライベートキャッシュ(ブラウザのローカルキャッシュなど) にのみ保存されることを示します。
 
 ```
 Cache-Control: private
@@ -171,11 +170,11 @@ Cache-Control: private
 
 ユーザー個人を特定するコンテンツ、特にログイン後に受け取るレスポンスや、クッキーで管理されるセッションについては、`private` ディレクティブを追加する必要があります。
 
-パーソナライズされたコンテンツを持つレスポンスに `private` を付け忘れると、そのレスポンスが shared cache に保存され、複数のユーザーによって使用されてしまい、個人情報の漏えいに繋がる可能性があります。
+パーソナライズされたコンテンツを持つレスポンスに `private` を付け忘れると、そのレスポンスが共有キャッシュに保存され、複数のユーザーによって使用されてしまい、個人情報の漏えいに繋がる可能性があります。
 
 #### `public`
 
-ヘッダーフィールドに `Authorization` を持つリクエストに対するレスポンスは、shared cache に保存してはいけません。しかし、`public` ディレクティブはそのようなレスポンスを shared cache に保存します。
+ヘッダーフィールドに `Authorization` を持つリクエストに対するレスポンスは、共有キャッシュに保存してはいけません。しかし、`public` ディレクティブはそのようなレスポンスを共有キャッシュに保存します。
 
 ```
 Cache-Control: public
@@ -195,7 +194,7 @@ Cache-Control: public, max-age=604800
 
 #### `must-understand`
 
-レスポンスディレクティブの `must-understand` は、ステータスコードに基づいて cache の要件を理解している場合にのみ、cache がレスポンスを保存すべきであると示します。
+レスポンスディレクティブの `must-understand` は、ステータスコードに基づいてキャッシュの要件を理解している場合にのみ、キャッシュがレスポンスを保存すべきであると示します。
 
 `must-understand` は、フォールバック動作のために `no-store` と組み合わせる必要があります。
 
@@ -203,17 +202,17 @@ Cache-Control: public, max-age=604800
 Cache-Control: must-understand, no-store
 ```
 
-cache が  `must-understand` をサポートしていない場合は、無視されます。`no-store` も存在する場合は、レスポンスは保存されません。
+キャッシュが `must-understand` をサポートしていない場合は、無視されます。`no-store` も存在する場合は、レスポンスは保存されません。
 
-cache  が `must-understand` をサポートしている場合、ステータスコードに基づいて cache の要件を理解してレスポンスを保存します。
+キャッシュが `must-understand` をサポートしている場合、ステータスコードに基づいてキャッシュの要件を理解してレスポンスを保存します。
 
 #### `no-transform`
 
 仲介者の中には、さまざまな理由でコンテンツを変換する人がいます。たとえば、転送サイズを小さくするために画像を変換するものがあります。場合によっては、これはコンテンツプロバイダにとって望ましくありません。
 
-`no-transform` は、仲介者が (cache を実装しているかどうかに関係なく) レスポンスの内容を変換すべきではないことを示します。
+`no-transform` は、仲介者が(キャッシュを実装しているかどうかに関係なく)レスポンスの内容を変換すべきではないことを示します。
 
-注意: [Google’s Web Light](https://support.google.com/webmasters/answer/6211428) は、そのような仲介業者の一種です。これは、cache store や低速接続のデータを最小化するために画像を変換し、オプトアウトオプションとして `no-transform` をサポートします。
+注意: [Google’s Web Light](https://support.google.com/webmasters/answer/6211428) は、そのような仲介業者の一種です。これは、キャッシュストアや低速接続のデータを最小化するために画像を変換し、オプトアウトオプションとして `no-transform` をサポートします。
 
 #### `immutable`
 
@@ -223,38 +222,38 @@ cache  が `must-understand` をサポートしている場合、ステータス
 Cache-Control: public, max-age=604800, immutable
 ```
 
-静的なリソースに対する最近のベストプラクティスは、バージョン/ハッシュをURLに含める一方で、リソースには決して手を加えず必要なときに、新しいバージョン番号/ハッシュを持つ新しいバージョンでリソースを更新し、URLも異なるものにすることです。これを **cache-busting** パターンと呼びます。
+静的なリソースに対する最近のベストプラクティスは、バージョン/ハッシュを URL に含める一方で、リソースには決して手を加えず必要なときに、新しいバージョン番号/ハッシュを持つ新しいバージョンでリソースを更新し、URL も異なるものにすることです。これを **cache-busting** パターンと呼びます。
 
 ```
 <script src=https://example.com/react.0.0.0.js></script>
 ```
 
 ユーザーがブラウザをリロードすると、ブラウザはオリジンサーバーに検証のための条件付きリクエストを送信します。しかし、これらの静的リソースは、ユーザーがブラウザをリロードしても決して変更されないため、再検証する必要がありません。
-なぜなら、それらは決して変更されないからです。 `immutable` は cache にレスポンスが新鮮な間は不変であることを伝え、サーバーへの不要な条件付きリクエストを回避します。
+なぜなら、それらは決して変更されないからです。 `immutable` はキャッシュにレスポンスが新鮮な間は不変であることを伝え、サーバーへの不要な条件付きリクエストを回避します。
 
 #### `stale-while-revalidate`
 
-レスポンスディレクティブの `stale-while-revalidate` は、cache を再検証している間、古いレスポンスの再利用が可能なことを示します。
+レスポンスディレクティブの `stale-while-revalidate` は、キャッシュを再検証している間、古いレスポンスの再利用が可能なことを示します。
 
 ```
 Cache-Control: max-age=604800, stale-while-revalidate=86400
 ```
 
-上記の例では、レスポンスは7日間（604800 s）新鮮です。7 日後、レスポンスは古くなりますが、cache は翌日 (86400 s) のリクエストに再利用することができます。ただし、バックグラウンドでレスポンスを再認識することが条件です。
+上記の例では、レスポンスは 7 日間（604800 s）新鮮です。7 日後、レスポンスは古くなりますが、キャッシュは翌日 (86400 s) のリクエストに再利用することができます。ただし、バックグラウンドでレスポンスを再認識することが条件です。
 
-再バリデーションにより、cache は再び新鮮になるため、クライアントはその期間中は常に新鮮であったかのように見えます。これにより再バリデーションの遅延ペナルティを効果的にクライアントから隠蔽することができます。
+再バリデーションにより、キャッシュは再び新鮮になるため、クライアントはその期間中は常に新鮮であったかのように見えます。これにより再バリデーションの遅延ペナルティを効果的にクライアントから隠蔽することができます。
 
-その間にリクエストがなければ、cache は古くなり、次のリクエストは正常に再検証されます。
+その間にリクエストがなければ、キャッシュは古くなり、次のリクエストは正常に再検証されます。
 
 #### `stale-if-error`
 
-レスポンスディレクティブの `stale-if-error` は、オリジンサーバーがエラー (500、502、503、504) でレスポンスを返したときに、cache が古いレスポンスを再利用できることを指示します。
+レスポンスディレクティブの `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 s）新鮮です。7 日を過ぎると古くなりますが、サーバーがエラーでレスポンスを返した場合はさらに 1 日 (86400 s) 利用することができます。
 
 しばらくすると、保存されたレスポンスは正常に古くなりました。つまり、オリジンサーバーがエラーレスポンスを送信した場合、クライアントはそのままエラーレスポンスを受信します。
 
@@ -262,19 +261,19 @@ Cache-Control: max-age=604800, stale-if-error=86400
 
 ### `no-cache`
 
-リクエストディレクティブの `no-cache` は cache に、再利用する前にオリジンサーバでレスポンスを検証するように要求します。
+リクエストディレクティブの `no-cache` はキャッシュに、再利用する前にオリジンサーバでレスポンスを検証するように要求します。
 
 ```
 Cache-Control: no-cache
 ```
 
-`no-cache` は、cache に新しいレスポンスがある場合でも、クライアントが最新のレスポンスを要求することを可能にします。
+`no-cache` は、キャッシュに新しいレスポンスがある場合でも、クライアントが最新のレスポンスを要求することを可能にします。
 
 ブラウザは通常、ユーザーがページを **force reloading** しているときに、リクエストに `no-cache` を追加します。
 
 ### `no-store`
 
-リクエストディレクティブの `no-store` は、オリジンサーバーのレスポンスが保存される可能性がある場合でも、クライアントがリクエストと対応するレスポンスを保存しないように cache に要求することを可能にします。
+リクエストディレクティブの `no-store` は、オリジンサーバーのレスポンスが保存される可能性がある場合でも、クライアントがリクエストと対応するレスポンスを保存しないようにキャッシュに要求することを可能にします。
 
 ```
 Cache-Control: no-store
@@ -284,13 +283,13 @@ Cache-Control: no-store
 
 ### `max-age`
 
-リクエストディレクティブの `max-age=N` は、オリジンサーバで _N_  秒以内に生成される保存されたレスポンスをクライアントが許可することを示します。
+リクエストディレクティブの `max-age=N` は、オリジンサーバで _N_ 秒以内に生成される保存されたレスポンスをクライアントが許可することを示します。
 
 ```
 Cache-Control: max-age=3600
 ```
 
-上記の場合、`Cache-Control: max-age=604800` のレスポンスが3時間前に cache に保存されていた場合、cache はそのレスポンスを再利用することができません。
+上記の場合、`Cache-Control: max-age=604800` のレスポンスが 3 時間前にキャッシュに保存されていた場合、キャッシュはそのレスポンスを再利用することができません。
 
 以下で説明するように、多くのブラウザは **reloading** 時に、このディレクティブを使用します。
 
@@ -298,19 +297,19 @@ Cache-Control: max-age=3600
 Cache-Control: max-age=0
 ```
 
-`max-age=0` は `no-cache` の回避策です。多くの古い (HTTP/1.0) cache の実装は `no-cache` をサポートしていないからです。最近のブラウザは、後方互換性のために `max-age=0` を "reloading" の際に使用し、`no-cache` を使用して "force reloading" を行うようになっています。
+`max-age=0` は `no-cache` の回避策です。多くの古い (HTTP/1.0) キャッシュの実装は `no-cache` をサポートしていないからです。最近のブラウザは、後方互換性のために `max-age=0` を "reloading" の際に使用し、`no-cache` を使用して "force reloading" を行うようになっています。
 
 ### `max-stale`
 
-リクエストディレクティブの `max-stale=N` は、クライアントが_N_秒以内に失効した保存されたレスポンスを許可することを示します。
+リクエストディレクティブの `max-stale=N` は、クライアントが*N*秒以内に失効した保存されたレスポンスを許可することを示します。
 
 ```
 Cache-Control: max-stale=3600
 ```
 
-上記の場合、3時間前に `Cache-Control: max-age=604800` を持つレスポンスが cache に保存されていた場合、cache はそのレスポンスを再利用することができません。
+上記の場合、3 時間前に `Cache-Control: max-age=604800` を持つレスポンスがキャッシュに保存されていた場合、キャッシュはそのレスポンスを再利用することができません。
 
-クライアントは、オリジンサーバーがダウンしているときや遅すぎるときにこのヘッダーを使うことができ、多少古くても cache されたレスポンスを cache から受け入れることができます。
+クライアントは、オリジンサーバーがダウンしているときや遅すぎるときにこのヘッダーを使うことができ、多少古くてもキャッシュされたレスポンスをキャッシュから受け入れることができます。
 
 主要なブラウザは `max-stale` を指定したリクエストに対応していないことに注意してください。
 
@@ -322,7 +321,7 @@ Cache-Control: max-stale=3600
 Cache-Control: min-fresh=600
 ```
 
-上記の場合、51分前に `Cache-Control: max-age=3600` を持つレスポンスが cache に保存されていた場合、cache はそのレスポンスを再利用することができません。
+上記の場合、51 分前に `Cache-Control: max-age=3600` を持つレスポンスがキャッシュに保存されていた場合、キャッシュはそのレスポンスを再利用することができません。
 
 クライアントがこのヘッダーを使用できるのは、ユーザーのレスポンスが新鮮であることだけでなく、一定期間更新されないことも要求する場合です。
 
@@ -334,7 +333,7 @@ Cache-Control: min-fresh=600
 
 ### `only-if-cached`
 
-クライアントは、cache がすでに cache されたレスポンスを取得する必要があることを示します。cache にレスポンスが保存されている場合は、再利用されます。
+クライアントは、キャッシュがすでにキャッシュされたレスポンスを取得する必要があることを示します。キャッシュにレスポンスが保存されている場合は、再利用されます。
 
 ## Use Cases
 
@@ -364,7 +363,7 @@ Cache-Control: no-store
 
 ### Caching static assets with “cache busting”
 
-バージョン/ハッシュ機構を持つ静的資産を構築する場合、ファイル名やクエリ文字列にバージョン/ハッシュを追加することは、cache を管理するための良い方法です。
+バージョン/ハッシュ機構を持つ静的資産を構築する場合、ファイル名やクエリ文字列にバージョン/ハッシュを追加することは、キャッシュを管理するための良い方法です。
 
 例：
 
@@ -374,9 +373,9 @@ Cache-Control: no-store
 <img src=/assets/hero.png width=900 height=400>
 ```
 
-Reactライブラリのバージョンは、ライブラリを更新すると変わりますし、`hero.png` も画像を編集すると変わります。そのため、これらは `max-age` を使って cache に保存するのは難しくなります。
+React ライブラリのバージョンは、ライブラリを更新すると変わりますし、`hero.png` も画像を編集すると変わります。そのため、これらは `max-age` を使ってキャッシュに保存するのは難しくなります。
 
-このような場合、特定の番号のついたバージョンのライブラリを使用し、画像のURLにハッシュを含めることでcache の必要性に対応することができます。
+このような場合、特定の番号のついたバージョンのライブラリを使用し、画像の URL にハッシュを含めることでキャッシュの必要性に対応することができます。
 
 ```html
 <!-- index.html -->
@@ -391,22 +390,22 @@ Reactライブラリのバージョンは、ライブラリを更新すると変
 Cache-Control: max-age=31536000, immutable
 ```
 
-ライブラリを更新したり、画像を編集したりすると、新しいコンテンツは新しいURLを持つはずなので、cache は再利用されません。それを “cache busting” パターンと呼びます。
+ライブラリを更新したり、画像を編集したりすると、新しいコンテンツは新しい URL を持つはずなので、キャッシュは再利用されません。それを “cache busting” パターンと呼びます。
 
-長い `max-age` を使用して、HTML レスポンス自体が cache されないようにします。`no-cache` は再バリデーションを引き起こす可能性があり、クライアントは新しいバージョンの HTML レスポンスと静的アセットを正しく受信します。
+長い `max-age` を使用して、HTML レスポンス自体がキャッシュされないようにします。`no-cache` は再バリデーションを引き起こす可能性があり、クライアントは新しいバージョンの HTML レスポンスと静的アセットを正しく受信します。
 
 ```
 # /index.html
 Cache-Control: no-cache
 ```
 
-注意: `index.html` が基本認証またはダイジェスト認証で制御されている場合、`/assets` 以下のファイルは shared cache に保存されません。もし `/assets/` のファイルが shared cache に保存するのに適しているなら、 `public`、`s-maxage` または `must-revalidate` のうちの1つが必要です。
+注意: `index.html` が基本認証またはダイジェスト認証で制御されている場合、`/assets` 以下のファイルは共有キャッシュに保存されません。もし `/assets/` のファイルが共有キャッシュに保存するのに適しているなら、 `public`、`s-maxage` または `must-revalidate` のうちの 1 つが必要です。
 
 ### Up-to-date contents always
 
 動的に生成されるコンテンツや、静的であっても頻繁に更新されるコンテンツでは、ユーザーが常に最新版を受信できるようにしたいものです。
 
-もし、レスポンスが cache されることを意図していないからといって `Cache-Control` ヘッダーを追加しなければ、予期せぬ結果を引き起こす可能性があります。Cache storage は、ヒューリスティックに cache することが許されています。したがって、cache に関する何らかの要求がある場合は、常に `Cache-Control` ヘッダで明示的に示す必要があります。
+もし、レスポンスがキャッシュされることを意図していないからといって `Cache-Control` ヘッダーを追加しなければ、予期せぬ結果を引き起こす可能性があります。キャッシュストレージは、ヒューリスティックにキャッシュすることが許されています。したがって、キャッシュに関する何らかの要求がある場合は、常に `Cache-Control` ヘッダで明示的に示す必要があります。
 
 レスポンスに `no-cache` を追加すると、サーバーで再バリデーションが行われるので、毎回新鮮なレスポンスを提供できます。また、クライアントがすでに新しいレスポンスを持っている場合は、`304 Not Modified` とだけレスポンスを返します。
 
@@ -414,7 +413,7 @@ Cache-Control: no-cache
 Cache-Control: no-cache
 ```
 
-ほとんどの HTTP/1.0 cache は `no-cache` ディレクティブをサポートしていないので、歴史的には `max-age=0` が回避策として使用されてきました。しかし、`max-age=0` だけでは、cache がオリジンサーバーから切断されたときに、古いレスポンスが再利用される可能性がありました。`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
@@ -424,11 +423,11 @@ Cache-Control: max-age=0, must-revalidate
 
 ### Clearing an already-stored cache
 
-残念ながら、すでに保存されているレスポンスを cache からクリアするための cache ディレクティブはありません。
+残念ながら、すでに保存されているレスポンスをキャッシュからクリアするためのキャッシュディレクティブはありません。
 
 クライアント caches が、あるパスに対する新鮮なレスポンスを保存し、サーバーへのリクエストフライトがない状態を想像してください。そのパスに対してサーバーができることは何もありません。
 
-また、`Clear-Site-Data` はブラウザの cache をクリアすることができます。しかし、これはサイトの保存されたすべてのレスポンスをクリアするので注意してください。そして、ブラウザのみで、shared cache はクリアされません。
+また、`Clear-Site-Data` はブラウザのキャッシュをクリアすることができます。しかし、これはサイトの保存されたすべてのレスポンスをクリアするので注意してください。そして、ブラウザのみで、共有キャッシュはクリアされません。
 
 ## Specifications
 
@@ -450,4 +449,4 @@ Cache-Control: max-age=0, must-revalidate
 - [Cache-Control for Civilians](https://csswizardry.com/2019/03/cache-control-for-civilians/)
 - {{HTTPHeader("Age")}}
 - {{HTTPHeader("Expires")}}
-- {{HTTPHeader("Pragma")}}
\ No newline at end of file
+- {{HTTPHeader("Pragma")}}