2024 年 12 月 9 日（月曜日）
Google がキャッシュ保存をできるようにしてください。ぜひともお願いします。
インターネットの成長に伴い、Google によるクロールも増加しています。Google のクロール インフラストラクチャは、ヒューリスティックなキャッシュ保存のメカニズムをサポートしています。これは以前からそうです。ただ、ローカル キャッシュから返されるリクエストの数は 10 年前と比較して減少しています。10 年前はフェッチ全体の約 0.026% がキャッシュに保存できました。この数値も決して高いわけではありませんが、現在では 0.017% にまで下がっています。
キャッシュ保存が重要である理由
キャッシュ保存は大きなパズルと言えるインターネットの重要なピースです。キャッシュ保存により、再度ページにアクセスしたときに高速でページが読み込まれます。また、コンピューティング リソースを節約でき、結果として天然資源の節約にもつながります。クライアント側とサーバー側の両方において費用のかかる帯域幅の使用量も大幅に削減されます。
大規模なサイトで、個々の URL のコンテンツが滅多に変更されない場合は特に、ローカルでのキャッシュ保存を可能にするとより効率的にサイトがクロールされるようになります。Google クローラーのインフラストラクチャは、HTTP キャッシュ標準で定義されているヒューリスティックな HTTP キャッシュ保存をサポートしています。具体的には ETag レスポンスおよび If-None-Match リクエスト ヘッダーと、Last-Modified レスポンスおよび If-Modified-Since リクエスト ヘッダーを使用します。
エラーとミスが発生しにくい ETag を強くおすすめします（Last-Modified 値とは異なり値が構造化されていません）。可能であれば両方を設定してください。きっと、インターネットも喜ぶはずです。
どのような変更をクライアントがキャッシュを更新する必要がある変更と捉えるかは、個別の判断です。コンテンツに対して重大な変更を行った場合に、キャッシュの更新を求めるようにすることをおすすめします。たとえば、ページの一番下にある著作権の日付を更新しただけでは重大な変更とは言えないでしょう。
ETag と If-None-Match
Google クローラーは HTTP キャッシュ標準の定義のとおり、ETag ベースの条件付きリクエストをサポートしています。つまり、Google クローラーにキャッシュ保存の設定を伝えるには、アクセスされた URL でホストされているコンテンツを一意に示す任意の ASCII 文字列を Etag 値として設定します（通常はコンテンツのハッシュまたはバージョン番号を使用しますが、円周率でも何でも構いません）。たとえば、同じ URL で同じコンテンツの複数のバージョンをホストしている場合（モバイル版と PC 版など）、各バージョンの一意の ETag 値を設定します。
キャッシュ保存をサポートしている Google クローラーはその URL の以前のクロールで返された If-None-Match header の ETag 値を送信します。クローラーが送信した ETag 値が、サーバーが生成した現在の値と一致する場合、サーバーは HTTP 304（変更なし）のステータス コードを HTTP 本文なしで返します。この最後の「HTTP 本文なし」という点が、次の観点から重要となります。
- サーバーはコンピューティング リソースをコンテンツの生成に充当する必要がないため、費用を抑えられる
- サーバーは HTTP 本文を転送する必要がないため、費用を抑えられる
ユーザーのブラウザまたは Googlebot のようなクライアント サイドでは、その URL に含まれるコンテンツはクライアントの内部キャッシュから取得されます。データ転送を伴わないため、この処理は速やかに完了します。ユーザーの満足度向上につながると同時に、ユーザー用にリソースを節約できる可能性もあります。
Last-Modified と If-Modified-Since
ETag と同様に、Google クローラーは HTTP キャッシュ標準の定義のとおり、Last-Modified based の条件付きリクエストもサポートしています。これは結果からみると ETag と同様に機能します。つまり、識別子はリソースがキャッシュ保存の対象となるかどうかを判断するために使用されます。また、クライアント サイドでも ETag と同じ効果をもたらします。
ただ、キャッシュ ディレクティブとして Last-Modified を使用する場合には、いくつかの推奨事項があります。
-
Last-Modifiedヘッダーの日付は HTTP 標準に従った形式とします。解析に関する問題が発生しないように、「Weekday, DD Mon YYYY HH:MM:SS Timezone」という日付形式を使用することをおすすめします（「Fri, 4 Sep 1998 19:15:56 GMT」など）。 -
必須ではないものの、
Cache-Controlヘッダーのmax-ageフィールドを設定して、クローラーが特定の URL を再クロールするタイミングを判断できるようにすることも検討してください。max-ageフィールドの値には、コンテンツが変更されない想定期間を秒単位で設定します。たとえば、Cache-Control: max-age=94043と設定します。
例
私のように、ヒューリスティックなキャッシュ保存の仕組みを理解するのが難しい方は、一連のリクエストとレスポンスの例を確認すると理解が深まります。こちらでは、1 つは ETag / If-None-Match、もう 1 つは Last-Modified / If-Modified-Since という 2 つの流れについて、その仕組みをまとめています。
ETag / If-None-Match |
Last-Modified / If-Modified-Since |
|
|---|---|---|
クロールに対するサーバーのレスポンス: これは ETag と Last-Modified のどちらの前提条件のヘッダー フィールドをクローラーが保存できるかについてのレスポンス。 |
HTTP/1.1 200 OK Content-Type: text/plain Date: Fri, 4 Sep 1998 19:15:50 GMT ETag: "34aa387-d-1568eb00" ... |
HTTP/1.1 200 OK Content-Type: text/plain Date: Fri, 4 Sep 1998 19:15:50 GMT Last-Modified: Fri, 4 Sep 1998 19:15:56 GMT Cache-Control: max-age=94043 ... |
後続のクローラーによる条件付きリクエスト: 条件付きリクエストは以前のリクエストで保存された前提条件のヘッダー値に基づく。値はサーバーに返送され、If-None-Match および If-Modified-Since リクエスト ヘッダーが検証される。 |
GET /hello.world HTTP/1.1 Host: www.example.com Accept-Language: en, hu User-Agent: Googlebot/2.1 (+http://www.google.com/bot.html) If-None-Match: "34aa387-d-1568eb00" ... |
GET /hello.world HTTP/1.1 Host: www.example.com Accept-Language: en, hu User-Agent: Googlebot/2.1 (+http://www.google.com/bot.html) If-Modified-Since: Fri, 4 Sep 1998 19:15:56 GMT ... |
条件付きリクエストに対するサーバーのレスポンス: クローラーが送信した前提条件ヘッダーの値はサーバーサイドで検証されているため、サーバーは 304 HTTP ステータス コード（空の HTTP 本文）をクローラーに返す。これは後続のリクエストごとに、前提条件の検証が失敗するまで（サーバーサイドで ETag または Last-Modified の日付が変更されるまで）実行される。 |
HTTP/1.1 304 Not Modified Date: Fri, 4 Sep 1998 19:15:50 GMT Expires: Fri, 4 Sep 1998 19:15:52 GMT Vary: Accept-Encoding If-None-Match: "34aa387-d-1568eb00" ... |
HTTP/1.1 304 Not Modified Date: Fri, 4 Sep 1998 19:15:50 GMT Expires: Fri, 4 Sep 1998 19:15:51 GMT Vary: Accept-Encoding If-Modified-Since: Fri, 4 Sep 1998 19:15:56 GMT ... |
ユーザーの満足度を高め、ホスティング費用を少しでも節約したい場合は、ホスティング プロバイダ、CMS プロバイダ、デベロッパーと、サイトで HTTP キャッシュ保存を有効にする方法について検討してください。少なくとも、ユーザーのサービス満足度が少し上がるはずです。
キャッシュ保存について話がしたい場合は、最寄りの検索セントラルのヘルプ コミュニティにアクセスしてください。Google によるキャッシュ保存についてご意見がある方は、このブログ投稿と一緒に公開しているキャッシュ保存に関するドキュメントにフィードバックをお寄せください。