Pleskウェブサーバ

HTTP キャッシュヘッダー：キャッシュ戦略を妨害する方法

HTTP キャッシュヘッダーは、ブラウザやプロキシがコンテンツをキャッシュする方法を決定します。設定を誤ると、読み込み時間が遅くなり、サーバーの負荷が著しく増加します。この記事では、小さなヘッダーの誤りがどのように キャッシュ戦略 妨害行為と、わずかな修正で測定可能なほどスピードアップする方法。.

中心点

以下の重要なポイントにより、HTTPヘッダーを迅速に確認し、常にクリーンな状態を保つことができます。.

TTL 正しい選択：静的アセットは長期間キャッシュし、HTMLは短期間かつ制御してキャッシュする。.
バリデーション 利用：ETag および Last-Modified は不要なリクエストを削減します。.
コンフリクト 避けるべきこと：Origin ヘッダーと CDN ヘッダーは一致している必要があります。.
バージョン管理 使用：ファイルハッシュは積極的なキャッシュ戦略を可能にします。.
モニタリング 確立する：HIT率を測定し、体系的に向上させる。.

HTTPキャッシュヘッダーが実際に制御するもの

Cache-Control、Expires、ETag、Last-Modified は、コンテンツが最新であるかどうか、その有効期間、およびブラウザがいつリクエストを行うかを決定します。 最高年齢 私は、public/private を使用して、ブラウザまたは共有キャッシュ内の保存場所を定義します。次のようなディレクティブ ノーストア 保存を完全に防止し、no-cache は使用前に再検証を強制します。静的ファイルには 1 年間の有効期間を設定し、HTML にはインテリジェントな再検証機能を備えた短い期間を設定します。さらに、以下も採用しています。不変, ハッシュバージョンによってファイルが変更されていないことが保証される場合。.

この制御は、レイテンシ、帯域幅、サーバー負荷に直接影響します。増加した HIT率 待ち時間を短縮し、バックエンドの作業を軽減します。さらに、以下の方法で転送を最適化します。 HTTP圧縮, これにより、転送されるバイト数が減少します。ここで明確に分離することで、CDN、プロキシ、ブラウザのキャッシュの負荷を均等に軽減することができます。これにより、スムーズな ロード時間 を通した。

実践におけるTTL計画

適切なTTLは、変更頻度、リスク、およびリカバリ戦略に基づいて決定されます。ファイルハッシュを持つ資産については、新しいファイル名による変更を管理するため、12か月を設定しています。HTMLについては、コンテンツの動的特性に基づいて設定しています。ホームページやカテゴリページは1～5分間更新されることが多いですが、コメント付きの詳細ページはそれよりも短い間隔で更新されます。重要なのは、 ロールバックパス: エラーがライブで発生した場合、ブラウザに対して迅速なパージ（エッジ）と強制的な再検証（must-revalidate）が必要です。API レスポンスには短い TTL が設定されますが、 stale-エラー発生時にユーザーが回答を確認できるよう、ディレクティブを設定します。これらのプロファイルはルートまたはファイルタイプごとに文書化し、ビルド/デプロイパイプラインに組み込むことで、「サイレント」な変更によってフレッシュポリシーが意図せず無効化されるのを防ぎます。.

設定ミスが戦略を台無しにする

短すぎる TTL CSS、JS、画像で max-age=60 秒を強制すると、頻繁に問い合わせが発生し、キャッシュの利点が失われます。グローバルな キャッシュなし CMS 設定では、ページの大部分が実際には安定している場合でも、速度が低下します。ETag または Last-Modified が存在しない場合、ブラウザはファイルを完全に再読み込みし、賢くチェックすることはありません。不要なクエリ文字列は、断片化を引き起こします。 キャッシュ・キー HIT率を大幅に低下させます。Originがno-cacheを送信すると、CDNはエッジキャッシュを無視します。その結果、経路が長くなり、サーバーの負荷が高くなります。.

その結果は、メトリクスに表れています。リクエスト数の増加、より高い CPU時間 そして応答時間の増加。トラフィックがピークになると、タイムアウトのリスクが高まります。同時に、ユーザーにメリットを感じさせることなく、帯域幅の消費量が増加します。DevTools を確認すると、このようなパターンをすぐに認識できます。まず、 キャッシュ・コントロール, サーバーリソースを増強する前に。.

コンテンツタイプごとの推奨事項：適切なディレクティブ

コンテンツの種類に応じて、私は別の ヘッダー, キャッシュが適切に機能し、ユーザーが最新のデータを見ることができるようにするためです。以下の表は、私がプロジェクトで使用している、実績のあるプロファイルを示しています。.

内容	推奨されるキャッシュ制御	妥当性	ヒント
JS/CSS/画像（バージョン管理）	public, max-age=31536000, 不変	12ヶ月	ハッシュを使用したファイル名（例：app.abc123.js）
フォントファイル (woff2)	public, max-age=31536000, immutable	12ヶ月	CDN からロードする場合は CORS に注意してください
HTML（公開）	public, max-age=300, stale-while-revalidate=86400	5分	ショート新鮮さ, 、バックグラウンドでのスムーズなリロード
HTML（パーソナライズ）	private、max-age=0、no-cache	再認定	共有キャッシュでの転送不可
API	public, max-age=60–300, stale-if-error=86400	1～5分	エラー発生時 stale 和らげる

これらのプロファイルは、典型的なサイトを網羅しており、一貫性のある ルール 設定することが重要です。アセットには明確なバージョン管理を行い、max-age 値が長すぎて古いファイルが配信されないようにすることが重要です。HTML は短命であり、再検証によって更新されます。API には短い時間が設定され、stale-if-error によって安全策が講じられます。これにより、障害が発生してもページは 使用可能.

エラーコードとリダイレクトを正しくキャッシュする

リダイレクトとエラーページは、独自のルールが必要です。. 301/308 (永続的) は、CDN やブラウザで非常に長期間キャッシュされる可能性があります。リダイレクトの連鎖を避けるため、ここでは数日から数週間と設定することがよくあります。. 302/307 （一時的な）TTLは短く設定しないと、一時的な状態が「凍結」されちゃうよ。404/410の場合は、ボットやユーザーが何度も問い合わせをしないように、適度な更新間隔（数分から数時間）を設定するといいね。コンテンツが頻繁に変わる場合は、404は短めに設定するよ。. 5xx-私は基本的にエラーをキャッシュせず、stale-if-error を使用して、機能するコピーを一時的に配信しています。これにより、プラットフォームの安定性が維持され、頻繁にリクエストされるものの、存在しないパスに対する再レンダリングの負荷を軽減することができます。.

検証を正しく使用する方法：ETag および Last-Modified

と一緒に イータグ そして、Last-Modified により、ブラウザはリソースを実際に再読み込みする必要があるかどうかを検証します。クライアントは If-None-Match または If-Modified-Since を送信し、サーバーは理想的には 200 ではなく 304 で応答します。これにより、転送量を節約し、 トラフィック 明確です。静的ファイルの場合は、多くの場合、Last-Modified で十分ですが、動的に生成されるコンテンツの場合は、ETag を設定します。重要：キャッシュがヒットを認識できるように、ETag を一貫して生成してください。.

私は検証を以下と組み合わせるのが好きです。 stale-ディレクティブ。stale-while-revalidate は、バックグラウンドで更新を行いながら、ページの表示速度を高速に保ちます。stale-if-error は、バックエンドの問題が発生した場合に、障害耐性を確保します。これにより、ユーザーエクスペリエンスが安定し、サーバーへの負担も軽減されます。以下のスニペットは、私が使用している典型的な設定です。.

Header set Cache-Control "public, max-age=31536000, immutable"
 /etc/nginx/conf.d/caching.conf location ~* .(css|js|png|jpg|svg|woff2)$ { add_header Cache-Control "public, max-age=31536000, immutable"; }

上級者向けディレクティブと詳細

max-age のほかに、私は意図的に Sマクサージュ, エッジキャッシュをブラウザよりも長く保持するためです。たとえば、CDN は 1 時間保持し、クライアントは 5 分後に再検証を行うことができます。. 再検証が必要 ブラウザに、使用前に期限切れのコピーをチェックするよう強制します。セキュリティ関連分野では重要な機能です。. プロキシ再検証 共有キャッシュに義務を課します。 no-transform プロキシが画像や圧縮を無断で変更するのを防ぎます。幅広い互換性を確保するため、キャッシュ制御に加えて、オプションで 期限切れ-将来（アセット）または過去（HTML）の日付。ただし、最新のキャッシュは主にキャッシュ制御を順守します。CDN 戦略では、ブラウザルールとエッジルールを分離しています。クライアントには public + max-age、エッジには s-maxage/Surrogate-Control を適用します。この分離により、エンドデバイスでのステールリスクを発生させることなく、HIT 率を最大化することができます。.

CDN およびエッジキャッシュとの連携

CDN は以下を尊重します。 Originヘッダー – 誤ったディレクティブは、グローバルキャッシュを無効にします。共有キャッシュについては、public および必要に応じて s-maxage を設定し、エッジがブラウザよりも長く保持されるようにします。Surrogate-Control は、エッジキャッシュに追加のルールを提供することができます。no-cache がオリジンに到達すると、CDN は要求を拒否します。 ストレージ. そのため、私はブラウザとCDNの戦略を意図的に調整しています。.

新しいプロジェクトでは、事前ロード戦略も検討しています。 HTTP/3 プッシュ＆プリロード重要なアセットを早期にロードし、レンダリングのブロックを軽減します。この手法はキャッシュに取って代わるものではなく、それを補完するものです。アセットの TTL を長く設定することで、起動パフォーマンスが大幅に向上します。このように、ネットワークランクを向上させるために取り組んでいます。 サーバー まったく汗をかくことがない。.

Vary戦略の詳細

可変どのリクエストヘッダーが新しいバリエーションを生成するかを決定します。私は Vary を最小限に抑えています。HTML の場合は、ほとんどの場合 Accept-Encoding（圧縮）と言語（必要な場合）、アセットの場合は理想的にはまったく使用しません。Vary が広すぎる（例：ユーザーエージェント）と、HIT 率が低下します。同時に、タグその 表現固有の バリエーションを反映する：gzip または br を配信する場合、エンコーディングバリエーションごとに ETag が適用され、Vary: Accept-Encoding を設定します。弱い ETag (W/) を使用する場合は、一貫して生成するように注意してください。そうしないと、不要な 200 が発生します。フォントや画像は、通常、Vary を使用せずに処理する必要があります。そうすることで、キーは安定します。私の原則：まず、技術的に必要なバリエーションを定義し、その後に Vary を拡張する。決してその逆を行ってはならない。.

DevTools でのモニタリングと診断

私はいつも ネットワークタブ ブラウザツール。そこで、キャッシュからの応答があるかどうか、その応答がいつのものか、どのディレクティブが有効かを確認します。Age、Cache-Control、Status の各列は、迅速なチェックに役立ちます。HIT 率が 50% 未満の場合は対応が必要であり、80% 以上の目標値が現実的です。異常値がある場合は、まず関連するヘッダーを確認します。.

PageSpeed や GTmetrix などのツールは、私のローカルでの計測. 変更前と変更後を比較して、その効果を数値化します。転送量が多い場合は、最新の圧縮技術を積極的に活用します。これにより、さらに数ミリ秒の時間を節約できます。このように、すべての調整を厳密に検証しています。数字.

自動チェックとCI

ルールが損なわれないように、ヘッダーチェックをCIに組み込んでいます。パスごとに目標プロファイルを設定し、各ビルドでステージングに対してランダムにチェックを行っています。多くの場合、単純なシェルチェックで十分です。

# 例：バージョン管理されたアセットに対する期待されるディレクティブ curl -sI https://example.org/static/app.abc123.js | grep -i "cache-control" # HTML に対する期待される短期間および再検証
curl -sI https://example.org/ | egrep -i "cache-control|etag|last-modified" # エージヘッダーとキャッシュステータス（存在する場合）を検査 curl -sI https://example.org/styles.css | egrep -i "age|cache-status|x-cache"

合成テストと組み合わせて、定期的な「ヘッダー監査」を計画しています。得られた知見はインフラストラクチャコードにフィードバックされます。これにより、 ポリシー 安定性 – CMS、CDN、サーバー設定を最後に変更した人物に関係なく。.

ホスティングの最適化：ページ、オブジェクト、オペコードのキャッシュ

ブラウザとCDNキャッシュに加えて、私は以下を利用しています。 サーバーキャッシュ. ページキャッシュは完成したHTMLページを提供し、オブジェクトキャッシュはデータベースの結果をバッファリングし、OPcacheはPHPバイトコードを処理します。ヘッダーが正しく設定されている場合、これらのレイヤーはバックエンドの負荷を大幅に軽減します。高速なエッジ、健全なTTL、サーバーキャッシュの組み合わせによって初めて、真のピーク値を実現できます。これにより、たとえ トラフィック が増える。

以下の市場概要は、私がホスティングで重視する点を示しています。高いヒット率、Redis の可用性、そして手頃な価格が選択の決め手となります。.

ホスティングプロバイダー	PageSpeed スコア	Redisのサポート	価格（スターター）
webhoster.de	98/100	噫	4,99 €
その他1	92/100	オプション	6,99 €
その他2	89/100	いいえ	5,99 €

無効化とパージ戦略

キャッシュの構築は、その半分にすぎない。 無効化 セキュリティと俊敏性を決定します。アセットについては、ファイルハッシュで変更を解決するため、パージは必要ありません。HTML および API については、デプロイ後（重要なルート）、公開後（影響のあるページのみ）、または機能フラグ後に、ターゲットを絞ったパージを計画しています。エッジキャッシュについては、タグ/キーを使用して、全体をサポートしています。 グループ パスを個別に処理するのではなく、空にする。可能な場合は、「ソフトパージ」を使用します。コンテンツはすぐに「古い」とマークされ、次回のリクエスト時に再検証されます。これにより、同時再取得による負荷のピークを回避できます。重要なのは、整理されたマッピングです。どのイベントがどのパージをトリガーするのか？このロジックは、プラットフォームにバージョン管理される必要があります。.

セキュリティとデータ保護：公共と民間

パーソナライズされたページは、 プライベートキャッシュ ブラウザのキャッシュに保存され、共有キャッシュには保存されません。そのため、このようなコンテンツには private、max-age=0 または no-cache を設定しています。公開 HTML ページは、短い有効期間で public を設定することができます。リクエスト内のクッキーに注意することで、コンテンツは明確に分離されたままになります。これにより、外部ユーザーが意図せずに データ 他の人を見る。.

同時に、支払いやアカウントの分野では厳しいルールを適用しています。no-store は、機密性の高い回答が保存されるのを防ぎます。サイトのその他の部分については、パフォーマンスを確保するため、寛大な設定を維持しています。この明確な分離により、プラットフォームは高速かつ安全に保たれています。私は、 プロフィール, 関係者全員が一貫性を保てるようにするためです。.

ヒューリスティック・キャッシングについて理解する

キャッシュ制御と有効期限がない場合、キャッシュは以下にアクセスします。 ヒューリスティック 戻る – ラスト変更からの時間の割合。これにより、再現性の低い結果や更新のばらつきが生じます。私は、関連するすべてのルートに明示的に Cache-Control を指定することで、このような自動化を避けています。Last-Modified が不正確な場合（動的テンプレートなど）、私は ETag を優先します。これにより、鮮度を積極的に制御し、すべてのクライアントで安定したメトリクスを取得することができます。.

レンジリクエストと大きなファイル

メディアとダウンロードを再生する レンジ-リクエスト（206 パーシャルコンテンツ）が重要な役割を果たします。私は Accept-Ranges を有効にし、ブラウザが部分を適切に再利用できるように、一貫性のある ETag/Last-Modified を提供しています。バージョン管理されたビデオセグメント（HLS/DASH）では、長い TTL を設定しています。マニフェスト自体は短命のままです。重要：変更時に部分領域が古い混合状態にならないよう、If-Range を正しく扱うこと。機密性の高いコンテンツについては、Range が関係する場合でも、no-store による保存は引き続き行わないこと。.

よくあるエラーを素早く解決する：私のプレイブック

ヘッダーのインベントリから始めましょう：どの指令 Origin は何を配信し、CDN は何を変更するのでしょうか？その後、コンテンツタイプごとに TTL プロファイルを定義します。バージョン管理されたアセットには 1 年、HTML には 5 分と再検証を設定します。ETag/Last-Modified は、意味がある場所ではすべて有効にします。その後、不要な Vary パラメータやクエリパラメータが HIT率 押す。.

次のステップでは、キャッシュ外のネットワークの詳細を処理します。誤った文字セットヘッダー圧縮がない場合も同様に時間がかかります。その後、DevTools、合成テスト、および必要に応じて実ユーザーモニタリングで再度測定します。値が正しい場合は、設定ファイルにルールを固定し、バージョン管理を行います。これにより、品質ステップ・バイ・ステップ。

簡単にまとめると

正しい HTTPヘッダー どこに、どれだけの期間、何を保存するかを管理することで、時間とリソースを節約できます。バージョン管理されたアセットには長い TTL を、HTML には短い時間と再検証、そして適切な stale ディレクティブを設定することで、スピードと回復力を実現します。クリーンなキャッシュキー、一貫したバージョン管理、パブリック/プライベートの明確なルールにより、典型的な障害を回避します。モニタリングにより証拠が提供され、残りのギャップが明らかになります。この方法を採用することで、 パフォーマンス 顕著かつ安定している。.