Cache-Control ヘッダー ジェネレーター
わかりやすいトグルと人間向けの時間単位から、正しい HTTP Cache-Control レスポンスヘッダーを、そのままブラウザー内で組み立てます。
Cache-Control ヘッダーは、選んだオプションからブラウザー内でローカルに組み立てられ、設定した内容がサーバーにアップロードされたり保存されたりすることはありません。
サーバーを設定していますか？ nginx Config Generator をお試しください。
Cache-Control ヘッダー ジェネレーター について
この Cache-Control ヘッダージェネレーターは、わかりにくい HTTP キャッシュディレクティブの集まりを、いくつかのシンプルなトグルに変えます。public か private、no-store、no-cache、must-revalidate、proxy-revalidate、immutable を切り替え、max-age、s-maxage、stale-while-revalidate、stale-if-error などの有効期間を、秒数を数える代わりに時間・日・年といった人間向けの単位で設定します。オプションを変えると、ツールがディレクティブを正規の順序で組み立て、現在のヘッダーが正確に何をするかを平易な言葉で説明し、no-store と max-age の併用のような矛盾する組み合わせを警告します。プリセットは日常的なケースをカバーします。1年間 immutable な静的アセット、常に再検証する HTML、決して保存しない private データ、CDN とブラウザーを分けるポリシーなどです。生のヘッダーや、すぐ使える nginx・Apache・HTML meta のスニペットをコピーできます。すべてはデバイス上のブラウザー内で動作します。
機能
- public、private、no-store、no-cache、must-revalidate、proxy-revalidate、immutable のトグル
- max-age、s-maxage、stale-while-revalidate、stale-if-error に人間向けの時間入力（秒から年まで）
- 編集するそばからディレクティブをクリーンな正規の順序で組み立て
- 現在のヘッダーが正確に何をするかを平易な言葉で説明
- 相互排他ルールを強制し、矛盾する組み合わせを警告
- 静的アセット・常に再検証する HTML・private データ・CDN/ブラウザー分割キャッシュのワンクリックプリセット
- 生のヘッダー、nginx の add_header、Apache の Header set、HTML meta タグのコピー用スニペット
- すべてブラウザー内で動作するため、設定した内容がデバイスから外に出ることはありません
Cache-Control ヘッダー ジェネレーター の使い方
- プリセットを選ぶか、ゼロから始めて public か private かを選びます。
- no-cache、must-revalidate、immutable など、必要なディレクティブを切り替えます。
- max-age などの有効期間を、数値と単位（時間・日・年）で入力します。
- 生成されたヘッダー値と、その下の平易な言葉での説明を読みます。
- 生のヘッダー、または必要な nginx・Apache・HTML meta のスニペットをコピーします。
例
入力
public + immutable + max-age = 1 year
出力
Cache-Control: public, max-age=31536000, immutable
フィンガープリント付き静的アセットの定番ポリシー: 1年間キャッシュし、決して再検証しません。
よくあるエラーとトラブルシューティング
- no-store を設定したのに max-age や immutable も追加したら、それらが消えた。 — no-store は何もキャッシュしないことを意味するため、他のすべてのディレクティブを上書きします。キャッシュはするが制御したいレスポンスが欲しい場合は、no-store をオフにしてください。
- immutable が効いていないように見える。 — immutable はレスポンスがまだフレッシュな間だけ意味を持つため、ゼロでない max-age と組み合わせてください。max-age がなければ、適用されるフレッシュな期間が存在しません。
- ヘッダーが private のとき、s-maxage が CDN で無視される。 — private は共有キャッシュがレスポンスを保存することを禁じるため、共有キャッシュのみを対象とする s-maxage は適用されません。CDN にキャッシュさせたい場合は public を使ってください。
- 長い max-age を伴う no-cache が、キャッシュされていないかのように振る舞う。 — no-cache は再利用のたびにオリジンでの再検証を強制するため、max-age が与えるフレッシュさを実質的に打ち消します。目的に応じてどちらか一方を外してください。
よくある質問
- no-cache と no-store の違いは何ですか。
- no-store はレスポンスを一切キャッシュに書き込んではならないことを意味し、すべてのリクエストがオリジンに戻ります。no-cache はレスポンスの保存を許しますが、再び提供する前にキャッシュがオリジンで再検証しなければなりません。no-store はコピーを保持しないこと、no-cache は保持したコピーが最新かを常に確認することに関するものです。
- Cache-Control ヘッダーで immutable は何をしますか。
- immutable は、リソースが max-age の期間中は決して変わらないことをブラウザーに伝えるため、ユーザーがリロードしても再検証をスキップできます。app.9f2c.js のようにバージョンやフィンガープリントが付いたファイル向けで、新しいビルドは古いものを上書きせず新しい URL で配信されます。
- max-age と s-maxage はどう違いますか。
- max-age は、ブラウザーを含むあらゆるキャッシュでレスポンスがフレッシュでいる時間を設定します。s-maxage は max-age を上書きしますが、CDN やプロキシなどの共有キャッシュに対してのみ有効です。両方を設定すると、ブラウザーでは短くキャッシュしつつ CDN では長く保持できます。
- public と private はどちらを使うべきですか。
- public は、CDN やプロキシなどの共有キャッシュがブラウザーとともにレスポンスを保存することを許します。private は保存を個々のユーザーのブラウザーに限定するもので、共有キャッシュから他のユーザーに提供されてはならない、パーソナライズされた、または認証済みのレスポンスに適しています。
- stale-while-revalidate は何をしますか。
- stale-while-revalidate は、キャッシュが少し古いレスポンスを即座に提供しつつ、背後で新しいコピーを取得することを許します。ユーザーは即座に応答を得られ、キャッシュは次のリクエストに向けて自らを更新するため、リソースが期限切れになる瞬間を滑らかにつなぎます。
- 設定内容はサーバーに送信されますか。
- いいえ。ヘッダー、説明、スニペットは、オプションを切り替えるたびにすべてブラウザー内で組み立てられるため、設定はデバイス上でローカルに処理され、アップロードされるものは何もありません。
関連ツール
すべての ArrayKit ツール