HTTP キャッシュ: 知っておくべきことすべて

HTTP キャッシュメカニズムの詳細な説明

HTTP キャッシュは、サーバーの負荷を軽減し、クライアントの応答を高速化し、ネットワーク帯域幅を節約することにより、Web ページのパフォーマンスを向上させるテクノロジーです。 HTTP キャッシュは主に、強制キャッシュ と ネゴシエート キャッシュ の 2 つのタイプに分類されます。

強制キャッシュ

強制キャッシュを使用すると、クライアントはサーバーにリクエストを送信せずに、指定された期間内でローカルにキャッシュされたリソースを直接使用できます。強制キャッシュは、主に Cache-Control と Expires の 2 つのフィールドを通じて、サーバーによって指定された応答ヘッダーによって制御されます。

キャッシュ制御

Cache-Control は、リソースの最大有効期間 (max-age)、キャッシュを共有できるかどうか (パブリックまたはプライベート)、および変更が許可されるかどうか (no-age) を指定する一般的なヘッダーです。キャッシュまたは -store なし)。

例:

<code>Cache-Control: max-age=3600</code>

上記は、リソースが 3600 秒間有効であり、キャッシュできることを意味します。

期限切れ

Expires は、キャッシュの絶対有効期限を指定する非推奨のフィールドです。

例:

<code>Expires: Wed, 23 Aug 2024 03:36:26 GMT</code>

これは、リソースが 2024 年 8 月 23 日の午前 3:36:26 に期限切れになることを意味します。

Cache-Control と Expires の両方が存在する場合は、Cache-Control が優先されます。

ネゴシエーションキャッシュ

キャッシュのネゴシエーションでは、クライアントはリクエストごとにサーバー リソースが更新されたかどうかを確認する必要があります。更新されない場合、サーバーは 304 ステータス コードと空の応答本文を返し、クライアントはローカル キャッシュを使用し続けることができます。更新されると、サーバーはステータス コード 200 と新しいリソースを返し、ローカル キャッシュを置き換えます。キャッシュのネゴシエーションには、サーバーとクライアントのヘッダー、主に Last-Modified/If-Modified-Since と ETag/If-None-Match が関係します。

最終変更日/変更日以降

Last-Modified は、リソースの最終変更時刻を示すサーバー側のフィールドです。例:

<code>Last-Modified: Tue, 22 Aug 2024 02:36:26 GMT</code>

これは、リソースが最後に変更されたのが 2024 年 8 月 22 日の午前 2:36:26 であることを意味します。

If-Modified-Since は、リソースが最後に取得された時間を示すクライアント側のフィールドです。例:

<code>If-Modified-Since: Tue, 22 Aug 2024 02:36:26 GMT</code>

これは、クライアントが 2024 年 8 月 22 日の午前 2 時 36 分 26 秒にリソースを取得したことを意味します。

2 つのタイムスタンプが等しい場合、または Last-Modified の方が早い場合、リソースは更新されません。 Last-Modified が後の場合、リソースは更新されています。

ETag/一致しない場合

ETag は、リソースの一意の識別子を表すサーバー側のフィールドです。例:

<code>ETag: '5d3a9f6d-1f86'</code>

これは、リソースの識別子が「5d3a9f6d-1f86」であることを意味します。

If-None-Match は、リソースの予期される識別子を示すクライアント側のフィールドです。例:

<code>If-None-Match: '5d3a9f6d-1f86'</code>

これは、クライアントが「5d3a9f6d-1f86」というリソース識別子を期待していることを意味します。

2 つの値が一致する場合、リソースは更新されません。それらが異なる場合、リソースは更新されています。

HTTP キャッシュのベスト プラクティス

ネゴシエートされたキャッシュと強制キャッシュを組み合わせると、ユーザーが常に最新のコンテンツを利用できるようにしながら、不要なネットワーク要求を効果的に削減できます。

一般的な方法:

強制キャッシュ: 静的リソース (CSS、JS、画像など) の場合、キャッシュ期間を長く設定します。これにより、ブラウザはサーバーに接続せずにローカル ストレージからリソースを直接取得できるようになります。

ネゴシエーション キャッシュ: 変更される可能性のあるリソースについては、ネゴシエーション キャッシュを使用します。ブラウザは、リソースが変更されたかどうかを確認するリクエストを送信します。そうでない場合、サーバーは 304 Not Modified 応答を返し、ブラウザがローカル キャッシュを使用できるようにします。リソースが変更された場合、サーバーは 200 OK と更新されたリソースを返します。

実装例:

Express.js をバックエンド フレームワークとして使用するとします。

<code>Cache-Control: max-age=3600</code>

重要な考慮事項

• バージョニング: 強制キャッシュの効果を最大限に高めるには、リソース URL にバージョン情報 (/static/js/main.2024082301.js など) を含めます。リソースが更新された場合は、ユーザーが常に最新バージョンを取得できるようにバージョン番号を変更します。
• ネゴシエーション キャッシュのコスト: ネゴシエーション キャッシュにより不必要なデータ転送が削減されますが、それでもネットワークの往復が必要になります。めったに変更されないリソースの場合は、キャッシュを強制する方が効率的である可能性があります。

---

Leapcell: バックエンド プロジェクトをホストするための最良の選択

Leapcell は、Web ホスティング、非同期タスク、Redis 用の新世代サーバーレス プラットフォームです:

多言語サポート

• Node.js、Python、Go、または Rust を使用して開発します。

無制限のプロジェクトを無料でデプロイ

• 使用した分だけお支払いください - リクエストや手数料はかかりません。

比類のない費用対効果

• 従量課金制で、非アクティブ料金はかかりません。
• 例: 25 ドルは、平均応答時間 60 ミリ秒で 694 万件のリクエストをサポートします。

簡素化された開発者エクスペリエンス

• 直感的な UI、セットアップが簡単。
• 完全に自動化された CI/CD パイプラインと GitOps の統合。
• 実用的な洞察を得るリアルタイムのメトリクスとログ。

簡単な拡張性と高いパフォーマンス

• 自動スケーリングにより、高い同時実行性を簡単に処理できます。
• 運用上のオーバーヘッドがゼロ - 構築だけに集中します。

詳しくはドキュメントをご覧ください。

X でフォローしてください: @LeapcellHQ

---

ブログを読む

以上がHTTP キャッシュ: 知っておくべきことすべての詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。