Pleskウェブサーバ

ETagとLast-Modifiedを用いたHTTP条件付きキャッシュの仕組み

HTTPキャッシュは、リソースが実際に変更された場合にのみ再読み込みを行うことで、時間とデータ通信量を節約します。詳細については イータグ そして 最終更新日 条件付きリクエストを使用して、サーバーが304 Not Modifiedで応答するかどうかを確認します。これにより、データ転送量とサーバーの負荷が大幅に軽減されます。.

中心点

以下の要点では、Conditional Caching において私が重視している点を示しています。 イータグ そして 最終更新日 に注目してほしい。

トラフィックの減少: 変更のないファイルに対しては304を返すだけで、ボディ全体を送信しない――これにより、データ量と遅延が顕著に削減される。.
パフォーマンス向上: 待ち時間の短縮はUXとCore Web Vitalsの向上につながり、これにより ＳＥＯ が助けてくれる。
2つのメカニズム: Last-Modified/If-Modified-Since および ETag/If-None-Match により、キャッシュの有効性を確実に検証します。.
キャッシュ・コントロール: ディレクティブは、中間キャッシュにおける更新頻度、再検証、および動作を制御します。.
コンビネーション: これら2つの手法を組み合わせることで、高い精度とシンプルなフォールバックを実現できます。.

まず、どのリソースが頻繁に変更され、どのリソースがめったに変更されないかを確認します。めったに変更されないファイルには、 最終更新日-のタイミングでETagを追加します。動的なレスポンスについては、私は主に イータグ, 、コンテンツの変更が即座に反映されるためです。これにより、サーバーの負荷を軽減し、遅延を減らし、リピーターには非常に高速なページを提供できます。この戦略は、 コアウェブ・バイタル ひいては、間接的にその認知度も高まる。.

HTTP条件付きキャッシュ：有効性を確認する方法

再度リクエストを行う際、クライアントはGETに加え、サーバー側で解析する追加のヘッダーを送信します。リソースが同じ イータグ キャッシュと一致する場合（If-None-Match）、ボディなしで304 Not Modifiedを返します。タイムスタンプに変更がない場合（If-Modified-Since）、サーバーは同様に304を返します。日付や時刻が一致しなくなった場合は、新しいコンテンツと更新された 最終更新日 そしてETag。これにより、帯域幅を節約し、キャッシュを最新の状態に保ち、読み込み速度を明らかに向上させることができます。.

日常におけるLast-ModifiedとIf-Modified-Since

ヘッダー 最終更新日 ファイルの実際の変更時刻（ファイルシステムなどから取得したもの）を設定します。その後、「If-Modified-Since」を含むリクエストが届き、その時点でリソースに変更がない場合は、304を返答します。この方法はシンプルで理解しやすく、CSS、JS、画像などの静的アセットに最適です。ただし、HTTPタイムスタンプの秒単位の精度や、明確なファイル更新時刻が存在しないにもかかわらず、論理的にコンテンツが変更されるような状況では限界があります。Last-Modifiedが限界に達する場面では、 イータグ 管理。.

動的システムにおけるETagとIf-None-Match

A イータグ ハッシュやバージョンIDとして生成するか、状態の変化を示すデータベースのカラムから生成します。再度アクセスがあった際、ブラウザは If-None-Match ヘッダーを送信します。私はそのタグを現在の値と比較し、それに応じて 304 または 200 を返答します。この照合により、ファイルのタイムスタンプに依存することなく、あらゆる意味のあるコンテンツの変更を検出できます。特にAPI、複合ページ、またはパーソナライズされたフラグメントの場合、これにより非常に正確な結果が得られます。重要なのは、クラスタ環境においてETagを一貫して維持し、どのサーバーも偶然に異なる日生成される。.

Cache-Control を適切に組み合わせる

と一緒に キャッシュ・コントロール ここでは、再確認なしでコンテンツが「最新」とみなされる期間や、ブラウザが再検証を行うタイミングを定義します。変更頻度に応じて適切なmax-age値を設定し、古いデータが重大な問題を引き起こす可能性がある場合はmust-revalidateを使用します。バージョン管理されたファイルには長い有効期間が適していますが、頻繁に変更されるレスポンスは有効期間を短くし、ETagや日付を使って正確に検証できるようにします。このようにして、短いレスポンス時間と正確な最新性を両立させています。さらに詳しく知りたい方は、以下のリンクから多くのサンプルをご覧いただけます。キャッシュ制御の戦略, 私が実際に使っているものです。.

Conditional GET の手順（ステップバイステップ）

最初のリクエストに対して、サーバーは Cache-Control を含む 200 OK を返します。, 最終更新日 そしてETagにより、ブラウザはすべてを保存します。次回のアクセス時には、キャッシュ内の有効期限に基づいて再検証が必要かどうかが判断されます。再検証が必要な場合、ブラウザはIf-None-Matchおよび／またはIf-Modified-Sinceを使用してリクエストを送信します。値が現在の状態と一致する場合、私は 304 Not Modified を送信し、クライアントはキャッシュを引き続き使用します。一致しなくなった場合は、新しいボディと更新された 検証データ.

比較：ETag 対 Last-Modified

どちらの方法も管理を確実なものにしますが、手間、精度、適性において異なります。. 最終更新日 正確なタイムスタンプさえあれば、実装が簡単で意味論が明確である点が魅力です。ETagはコンテンツを非常に正確に反映しますが、生成には多少のロジックが必要です。多くの設定では、この2つを組み合わせており、シンプルさと正確な識別というメリットを享受しています。以下の表は、それぞれの典型的な特性をまとめたもので、選択の参考にしてください。.

アスペクト	最終更新日	イータグ	ヒント
アイデンティティ	最終更新日時	コンテンツハッシュまたはバージョンID	時間対コンテンツベースの識別子
変更の検出	秒単位の分解能（間接的）	内容に直結した	ETagはごくわずかな差分
実装	非常に軽量で、ファイルシステムがあれば十分	生成と一貫性が求められる	クラスターには同じものが必要だタグ
用途	静的アセット	動的な回答	この組み合わせは多くの事例より
回答	304（タイムスタンプは変更なし）	304（日付が同一の場合）	変更がある場合は200 価値

実践：静的アセットを効率的に配信する

CSS、JS、画像などの静的ファイルは変更されることがほとんどなく、長期的な運用に適しています 最高年齢- 有効期限。バージョン管理されたファイルについては、最大1年という長い有効期限を設定し、ブラウザが確認を求めずに読み込めるよう「immutable」としてマークします。バージョン管理されていないアセットについては、有効期限を短く設定し、ETagとLast-Modifiedによる再検証に依存しています。これにより、古いコンテンツを回避し、トラフィックを低く抑えています。注意すべき点は、キャッシュヘッダの妨害そうすることで、キャッシュでのヒット率を高めることができます。.

実践：APIと動的ページ

APIに関しては、私はたいていタグ, これは、シリアライズされた結果やバージョン列から生成したものです。データセットが変更されると、新しいタグを生成し、クライアントはそれを即座に認識します。タイムスタンプの信頼性が低いコンテンツについては、最新性について誤った印象を与えないよう、Last-Modifiedを省略することがよくあります。その代わりに、Cache-Controlで有効期間を制御し、期限切れ後は再検証を強制します。これにより、レスポンスを不必要に大きくすることなく、データを確実に最新の状態に保つことができます。.

キャッシュヒット率のテストと監視

次のようなヘッダーを確認しています イータグ, 、Last-Modified、If-None-Match、If-Modified-Since をデベロッパーツールで確認します。その際、レスポンスコード、特に 304 と 200 の違いに注目し、再検証の有効性を確認します。 304がめったに返ってこない場合は、Cache-Control、有効期間、およびETagの生成を調整します。ログとメトリクスから、どのパスが不必要に大きなレスポンスを返しているかがわかります。一括して改善を行う際には、 Conditional-Requests パッケージ, 設定とテストを統合するものです。.

ホスティングアーキテクチャとETagの落とし穴

マルチサーバー構成では、 イータグ インスタンスに依存しないようにする必要があります。そうしないと、再認識が機能しなくなります。私は、すべてのノードが生成に際して同じロジックと同じキーを使用するようにしています。リバースプロキシやCDNはETagを変更してはならず、Conditionヘッダーを正しく転送する必要があります。アセットフィンガープリントを使用したデプロイでは、ファイルにすでにバージョン管理されたURLが付与されている場合、サーバー側でのETagの再計算は避けています。統一されたルールを適用することで、不整合なレスポンスを防ぎ、キャッシュヒット率を高く維持します。.

「フレッシュ」対「バリデーション」：ディレクティブを的確に活用する

私は次の2つを明確に区別している。 新鮮さ （キャッシュは、確認なしにコピーをどのくらいの期間使用できるのか？）および バリデーション （有効期限が切れていないかどうかの確認方法は？）。について キャッシュ・コントロール 私は両方をきめ細かく制御しています： 最高年齢 クライアントでの有効期間を設定します。, Sマクサージュ プロキシなどの共有キャッシュ用。. 公開分割キャッシュへのキャッシュ保存を許可し、, プライベート それをエンドブラウザに限定する。. 再検証が必要 期限切れ時に確認を強制する一方で、不変バージョン管理されたアセットにおいて、不要な再検証を防ぐ。. キャッシュなし キャッシュを禁止するのではなく、常に再検証を要求します；; ノーストア 一方、保存は一切禁止されています。古い 期限切れ-ヘッダーはあくまでフォールバックとしてのみ使用し、ロジックは一貫してCache-Controlに移行しています。また、障害の影響を緩和したい場合には、 有効期限切れ そして もしエラーなら, 、バックグラウンドで更新やエラーの処理を行っている間も、期限切れ間近のコンテンツをユーザーに提供し続けるためです。.

強力なETagと弱いETag、圧縮、およびバリエーション

私は、影響力の強い検証者と弱い検証者を意識的に区別しています。. 強力なETags バイト単位で完全に同一の表現を特定する――私が レンジリクエスト 効率的に操作したい。. 弱いETags (接頭辞 W/) で十分です。これは、意味的な同一性が満たされればよい場合、例えば、些細で重要でない書式変更などにおいてです。重要なのは、圧縮: gzipおよびbrotliで圧縮されたコンテンツの両方を配信する場合、単一のETagをすべてのバリエーションに適用してはなりません。圧縮されていない形式に基づいてETagを生成するか、さらに適切な Vary: Accept-Encoding, 、あるいはバリエーションごとに一貫性はあるものの異なるETagを生成します。そうすることで、本来304であるべきところでの誤検出や200レスポンスを防ぐことができます。 イフ・レンジ リーチクエリとバリデータを活用しています。ETagまたは日付が一致する場合は206 Partial Contentを返します。一致しない場合は、クライアントが一貫性のある基盤を持てるよう、本文をすべて含む200を返します。.

Varyヘッダーとコンテンツネゴシエーションを確実にマスターする

サーバーが要件に応じて異なる表現を返す場合は、常に可変その通りです。典型的な例としては Accept-Encoding （圧縮）、, Accept-Language （ローカライズ）や特定の機能フラグ。私は、次のような揮発性のヘッダーの使用は避けています ユーザーエージェント あるいは、ましてや クッキー 変更しないようにしています。そうしないと、キャッシュのヒット率が大幅に低下してしまうからです。パーソナライズが必要な場合は、回答に プライベート 或いは ノーストア そして、それらをパブリックキャッシュ可能なリソースとは明確に区別します。重要：バリエーションはETagにも影響します。各バリエーションには、それぞれ独自の、一貫性のあるバリデータが必要です。これにより、ブラウザ、プロキシ、CDNが同じロジックを適用し、あるバリエーションが誤って別のものと混同されることがないよう確実にします。.

GET以外の条件付きリクエスト

条件付きリクエストは読み取り時だけでなく、書き込みメソッドでも有効です。書き込みメソッドでは、私は イフ・マッチ 或いは If-Unmodified-Sinceのために 更新情報 を防ぐ。クライアントがPUTまたはDELETEの際、最後に確認されたETagを イフ・マッチ の場合、サーバーの状態が依然として同一である場合にのみ変更を実行します。そうでない場合は、 412 前提条件を満たしていません. クライアントを管理するために、サーバーはさらに 428 前提条件が必要 確立する。ボディを使わずに素早くテストを行うには、私は HEAD, 、これはGETリクエストと同じヘッダーを返してくれるので、メタデータをテストしたい時に最適だ。そして、 304-レスポンスには、キャッシュに関連するすべてのヘッダー（Cache-Control、ETag、Expires、Last-Modified）を再度含めるようにしています。これにより、クライアントはボディを送信することなくメタデータを更新できるようになります。.

セキュリティ、データ保護、コンプライアンス

個人情報や機密性の高いコンテンツは、公開キャッシュには保存しません。ここでは、 キャッシュ制御：プライベート 或いは ノーストア, これにより、ブラウザやインスタンス自体がコンテンツを永続化しないようになります。ユーザーアカウントやダッシュボードについては注意が必要です： クッキーの設定 或いは認証誤ってキャッシュ可能になってはいけません。ETag自体は、長期間にわたって変化しない場合、追跡手段として悪用される可能性があります。私は、キャッシュが意図されている場所でのみバリデータを活用し、ユーザー固有のルートでは無効にするか、有効期間を短く設定することで、この問題に対処しています。このようにして、パフォーマンスとプライバシー保護の要件を両立させています。.

実装の詳細とパフォーマンスへの影響

ETagの生成にかかるコストは、そのメリットを上回ってはならない。大容量のファイルや処理負荷の高いレンダリングの場合、私はそのタグをメタデータ（ファイルのチェックサム、ビルドハッシュ、データベースの行バージョン) を使用し、リクエストごとに再計算しないようにします。複合ページの場合、 バージョン構成戦略: ETagは、安定した部分ETag（例：テンプレート、データフラグメント、設定）から構成しているため、わずかな変更でも的を絞った、かつ再現性のある新しい値が生成されます。クラスタ環境では、生成ロジックを共通ライブラリで同期させ、CIで検証することで、どのインスタンスも逸脱しないようにしています。非常に大きなBlobについては、ボディをオンザフライでハッシュ化する代わりに、高速なチェックサム（CRC64）を使用するか、ビルドハッシュを保存します。バイト単位での完全な一致が不要な場合は、 有効期限が短いETag 現実的な妥協案として。.

よくある間違いとその回避方法

ランダムなETag: リクエストのたびにタグが再生成されるようでは、再検証は意味をなさなくなります。私は、実際に変更があった場合にのみ更新される、確定的な値を保証します。.
ディレクティブの組み合わせが間違っている: ノーストア ETagを使っても意味がない――ブラウザはそもそもキャッシュしないからだ。私は、意図した動作が得られるように一貫性のある組み合わせを選んでいる。.
過度なVary: CookieやUser-Agentのバリエーションはキャッシュを分散させてしまいます。私はVaryを、真の表現の変更に限定しています。.
圧縮トラップ: gzipとbrでETagが共通していると、誤検出が発生します。私はETagを具体的なバリエーションと適切に紐付け、Varyを正しく設定しています。.
時刻のずれ: サーバーの時刻が正確でない場合、「Last-Modified」が不正確になります。私は時刻ソースを同期させておき、「If-Modified-Since」が正しく機能するようにしています。.
no-cache の混同: 多くの人が「キャッシュしない」と読みます。実際には「常に再検証する」という意味です。完全に禁止するには、私は ノーストア.

トラブルシューティング、メトリクス、およびワークフロー

トラブルシューティングを行うため、ネットワークタブから開始します：正しい キャッシュ・コントロール？リハビリテーションの際に 304 200ではなく？いいですよ イータグ そして 最終更新日 質問から回答までの間？確認してみます可変, 、バリエーションが正しく認識されているか確認するために。ログでは、 当たり外れ- パスごとのクォータ、304率、および平均レスポンスサイズを出力します。304率が上昇すると、通常、データ量とTTFBは目に見えて低下します。負荷テストでは、転送コストではなく再検証コストを測定するために、リクエストの繰り返しをシミュレートします。異常が見られた場合は、Set-Cookie、過度に厳格なVaryルール、Pragmaのような矛盾したヘッダーなど、妨げとなる要因を段階的に排除します。これにより、ヒット率を低下させているボトルネックを迅速に特定できます。.

補完的なキャッシュ層としてのService Worker

サービスワーカーを導入する場合、私はそれを追加のレイヤーとして利用し、既存のレイヤーと競合させることはありません。同じ キャッシュ・コントロール-シグナルを尊重し、次のような戦略を組み合わせる 有効期限切れ ETagおよびLast-Modifiedを用いたHTTP検証を意図的に行っています。オフラインの場合、ワーカーは一時的に古いリソースを提供し、バックグラウンドで再検証を行うことができます。重要なのは、条件ヘッダーを正しく転送することです。そうしないと、ネットワーク経路における304の利点が失われてしまいます。これにより、PWAシナリオでも、メカニズムを回避するのではなく、適切なHTTPキャッシュの恩恵を受けることができます。.

SEO効果とCore Web Vitals

回答の迅速化 UX さらに、ユーザーの行動データもランキング向上に寄与します。特にリピーターは、ブラウザが多くのファイルをキャッシュから直接読み込むか、304ステータスで応答するため、恩恵を受けます。この遅延の低減はFCP、LCP、TTFBに好影響を与え、私は適切な再検証を行うことでこれらの指標をさらに改善しています。さらに、サーバーの処理時間を節約できるため、そのリソースをトラフィックのピーク時や処理負荷の高いリクエストに充てることができます。これにより、コンテンツを正確かつ迅速に配信しつつ、高いパフォーマンスを維持しています。.

要約：私の行動計画

私は明確なものを頼りにしている。 コンビネーション Cache-Control、Last-Modified、ETag に基づいて設定します。静的アセットについては、有効期間を長く設定し、ファイルにバージョン管理が施されていない場合は再検証を行うことで確実性を高めています。動的なレスポンスについては、信頼性の高いETagを生成し、クラスタの一貫性を維持します。その後、ツール、メトリクス、ログを用いて304レスポンスが十分に発生しているかを確認し、設定を調整します。これにより、効果的なキャッシュ管理を通じて、高速な配信、負荷の低減、そしてより良いユーザー体験を確保しています。 HTTPキャッシュ.