編集可能な公開ドキュメントでは、読者が最新のコンテンツを取得でき、変更のないページは再利用できるようにしたい場合、再検証を選びます。公開要件でHTTPキャッシュへの保存を明確に除外する場合は、no-storeを選びます。

このガイドは、Macデスクトップから公開ドキュメントを管理する人を対象としています。応答ポリシーを選び、「図形ガイド、バージョン1」のような中立的なテキストだけを含む合成ページを使って、Terminalで確認します。テストページと、そのホスティング設定へのアクセスが必要です。または、応答ヘッダーを設定できるプロバイダーが必要です。

ドキュメントに適したキャッシュポリシーはどれですか？

まず、公開要件を確認します。再利用するたびにページを確認する必要がありますか。既存のコピーを短期間使えるようにしますか。それとも、HTTPキャッシュに応答を保存させない必要がありますか。これらはRFC 9111: HTTP Cachingで定められた、異なる要件です。

公開要件 候補となる応答ヘッダー HTTPキャッシュでの意味
再利用するたびに確認する Cache-Control: no-cache 保存は許可されますが、再利用には検証の成功が必要です。
短い鮮度期間を許可する Cache-Control: max-age=300, must-revalidate 新鮮な間は再利用できます。古くなった後は、検証の成功が必要です。
応答の保存を除外する Cache-Control: no-store キャッシュは応答を保存したり、別のリクエストに使用したりしてはなりません。

5分間の期間は例示であり、推奨されるデフォルト値ではありません。ドキュメントがその再利用間隔を許容できる場合に限り、選択してください。must-revalidateだけでは、応答が新鮮な間の確認は求められません。これらの違いはRFC 9111の応答ディレクティブに基づいています。

合成の図形ガイドで、「3つの例」を「4つの例」に修正した場合、次の取得時に確認したいとします。no-cacheと、動作するバリデーターを使用します。HTTPキャッシュにこのドキュメントの応答を保持させないことが要件であれば、no-storeを選びます。編集頻度が高いというだけでは、保存を除外すべき要件にはなりません。

設定を変更する前に、要件を書き出してください。たとえば、「再利用する前にドキュメントを確認する」とします。これにより、具体的な受け入れ基準ができ、設定名だけでポリシーを決めずに済みます。

再検証を機能させるには？

バリデーターは、クライアントがすでに受け取ったバージョンを識別します。ETagはエンティティタグを、Last-Modifiedは変更日時を示します。RFC 9110は、成功したドキュメント取得に利用可能なバリデーターを送信することを推奨しており、強いエンティティタグと変更日時の両方を優先しています。HTTP Semantics, validatorsと200 OKを参照してください。

以下は応答ヘッダーフィールドの例であり、サーバー設定コードではありません。応答本文が合成の図形ガイドであることを前提としています。

Cache-Control: no-cache
ETag: "shape-guide-v1"

後続のリクエストで、クライアントはIf-None-Match: \"shape-guide-v1\"を送信できます。そのタグが選択された表現と一致する場合、条件付きのGETは、応答本文なしで304 Not Modifiedを返します。一致しなくなった場合は、通常の処理で変更後のドキュメントを返せます。ルールはRFC 9110の条件付きリクエストのセクションに記載されています。

実装要件は、バリデーターがドキュメントのバージョンを追跡することです。例示のタグを恒久的な設定にコピーし、編集後も変更せずに使い続けないでください。ホスティングシステムがバリデーターを一貫して生成し、受信した条件を評価するよう依頼してください。

変更のない応答では、転送量をどれだけ減らせますか？

明示的に例示する計算を考えてみましょう。ドキュメント本文は80,000バイトで、クライアントは一切編集せずに100回取得します。最初の1回で全応答を受け取り、その後99回の検証に成功した場合、本文の転送量は8,000,000バイトではなく80,000バイトとなり、差は7,920,000バイトです。

この計算には、ヘッダー、圧縮、接続オーバーヘッド、アプリケーション側の処理は含まれません。本文の転送量だけを示しています。GoogleのHTTP caching explanationでは同じやり取りを説明しています。一致するバリデーターによって本文のない304が可能になり、クライアントは以前に受け取ったコンテンツを使います。実際の節約量は、ドキュメントの変更頻度とクライアントのリクエスト方法によって異なります。

ポリシーはどこで設定すればよいですか？

ホスティングサービス、サーバー、またはコンテンツ配信レイヤーが生成するHTTP応答を設定します。上記のヘッダー例は必要な結果を示すものであり、すべての公開プラットフォームで使える共通コマンドではありません。

エディターでドキュメントのテキストしか変更できない場合、マークアップによる回避策では同等の制御はできません。WHATWG HTML Standardでは、Cache-Controlをサポート対象のhttp-equivプラグマとして定義しておらず、これらのプラグマはHTTPヘッダーとは概ね別のものだと説明しています。HTML Standard: Pragma directivesを参照してください。

サポートされている方法は、ホストの文書化された応答ヘッダー設定を使うか、プロバイダーに実装を依頼することです。Googleのcrawler overviewでも、HTTPキャッシュの実装についてはホスティングまたはコンテンツ管理プロバイダーに問い合わせるよう公開者に案内しています。依頼には、対象ドキュメント、選択したポリシー、バリデーターの動作を明記し、配信された応答の確認方法を尋ねるとよいでしょう。

JavaScriptのリクエストオプションを変更した場合、影響範囲はより限定的です。WHATWGでは、HTTPキャッシュが存在しないかのように動作するFetchのno-storeキャッシュモードを定義しています。一方、no-cacheは、適切なキャッシュ応答が存在する場合に条件付きリクエストを行います。これらのモードが制御するのはそのリクエストです。スクリプトで設定しても、ドキュメントのサーバー応答ポリシーは設定されません。Fetch Standardのキャッシュモードを参照してください。

Macから再検証をテストするには？

編集可能な合成の公開テストドキュメントを使います。始める前に、コンテンツを「図形ガイド、バージョン1」にし、選択した応答ヘッダーが配信されるようにします。実際のドキュメント内容とは分けてテストしてください。そうすれば、変更が明確で元に戻せます。

Terminalを開き、同じセッション内で以下のコマンドを実行します。実際のテストURLと、そのページが返したバリデーターの入力が求められます。例のアドレスは想定していません。最初のリクエストが失敗する、リダイレクトされる、または目的のドキュメント応答以外を返す場合は、そこで停止してください。

printf '%s\n' 'Paste the full URL of your synthetic public test page:'
IFS= read -r page_url

curl --silent --show-error --connect-timeout 5 --max-time 20 \
  --dump-header - --output /dev/null --url "$page_url"

printf '%s\n' 'Paste its ETag value exactly, including quotes:'
IFS= read -r page_etag

check_page() {
  curl --silent --show-error --connect-timeout 5 --max-time 20 \
    --dump-header - --output /dev/null \
    --header "If-None-Match: $page_etag" --url "$page_url"
}

check_page

このコマンドはGETリクエストを行い、受信したヘッダーを表示して、応答本文を意図的に破棄します。タイムアウトは接続と転送に上限を設けます。エラーは表示されます。これらのオプションはcurl manualに記載されています。最初のリクエストでは、選択したCache-Controlの値とETagが確認できるはずです。タグがなければ、架空の値を入力せず、まずバリデーターへの対応を解決してください。

W/プレフィックスがある場合はそれも含め、引用符で囲まれたタグの値全体をコピーしてください。表現に変更がなく、タグが一致すれば、条件付きリクエストは304を返すはずです。304にコンテンツを含めることはできません。また、該当する場合はETagやCache-Controlなど、同等の200応答に含まれる指定メタデータを含める必要があります。RFC 9110: 304 Not Modifiedを参照してください。

古いバリデーターを保持したまま編集をテストする

合成ドキュメントを「図形ガイド、バージョン2：4つの例」に変更します。更新がテストページに反映されたら、同じTerminalセッションで古いタグを使い続け、次の継続コマンドを実行します。

check_page

この意図的に変更したドキュメントでは、通常の成功応答と更新されたバリデーターを通じて、新しい本文を取得できるはずです。次に、新しいタグを使って最初のコマンドを繰り返し、変更のないバージョンを再確認します。これにより、変更を認識する場合と変更なしを認識する場合の両方をテストできます。

観察結果 次の診断手順
最初のリクエストがリダイレクトを返す ドキュメントの最終URLを使ってテストをやり直します。
変更のない条件付きリクエストが200を返す タグを正しくコピーしたことと、条件付き処理が有効であることを確認します。
コンテンツを意図的に編集した後も、古いタグで304が返る 再検証に頼る前に、更新の配信とバリデーター生成を調べます。
配信されたポリシーが設定と異なる 最終応答を左右するホスティング設定と配信設定を調べます。
リクエストがタイムアウトする、または失敗する キャッシュ動作を解釈する前に、取得の失敗を解決します。

これらは診断の手がかりであり、特定の原因を証明するものではありません。この手順でテストできるのは応答と条件付きのやり取りです。すべてのブラウザーの動作を確定するものではありません。no-storeを評価する場合は、その応答ディレクティブを直接確認してください。手動で作成した条件付きリクエストでは、ブラウザーが応答を保存したかどうかはテストできません。

Google Searchではどうなりますか？

Googleの現在のクローラーに関する文書では、If-None-Matchと組み合わせたETag、およびIf-Modified-Sinceと組み合わせたLast-Modifiedに対応しています。GoogleのクローラーにはETagを推奨しており、個々のクローラーによってキャッシュの使い方が異なる場合があると説明しています。Overview of Google crawlers and fetchersを参照してください。

同ページでは、その他のHTTPキャッシュディレクティブはサポートされていないと説明する一方、Last-Modifiedと併せて再クロールのヒントとしてmax-ageを使える可能性があるとも述べています。この文書上の範囲を踏まえ、ブラウザー向けのno-storeやno-cacheポリシーがGooglebotの取得スケジュールを決めると想定しないでください。文書化されている条件付き取得の方法として、バリデーターを実装し、テストしてください。

Googleによると、304は処理システムにコンテンツが変更されていないと伝えます。Searchについては、それ以外のインデックス登録への影響はありません。200が成功しても、インデックス登録が保証されるわけではありません。これらはHow HTTP status codes affect Google’s crawlersに記載されています。

ドキュメント要件に合うポリシーを選び、最初の応答、変更のない条件付き応答、意図的な編集後の応答というテスト結果を保存してください。再利用前の確認が必要な公開ドキュメントでは、再検証が実用的な出発点です。HTTPキャッシュへの保存を除外すること自体が要件であれば、no-storeを選びます。

出典