[レベル: 上級]
Google は、クローラーが HTTP キャッシュをどのように処理するかを説明するセクションをクローラーの技術ドキュメントに追加しました。
また、HTTP キャッシュの仕組みをさらに詳しく解説する記事を検索セントラルブログでも公開しました。
HTTP キャッシュの利点
キャッシングは、サーバーとクライアント（ブラウザとクローラー）の両方にいくつかの利点をもたらします。
サーバー側の利点
- コンピューティングリソースの削減: クライアントのリクエストがキャッシュされたバージョンと一致する場合、サーバーはコンテンツを生成するためのコンピューティングリソースを消費する必要がない。これはサーバーのコスト削減につながる
- データ転送量の削減: キャッシュされたバージョンが利用可能な場合、サーバーは HTTP 本体を転送する必要がないため、データ転送量を節約できる。これもサーバーのコスト削減につながる
特に、個々の URL でコンテンツがめったに変わらない大規模なサイトでは、ローカルでのキャッシングを許可すると、サイトのクロール効率が向上する場合があります。
クライアント側の利点
- 読み込み時間の高速化: キャッシングにより、再訪問時のページ読み込みが非常に高速になる——コンテンツがクライアントの内部キャッシュから取得される場合、データ転送が発生しないため、読み込みが速くなる
- リソース消費量の削減: クライアントは、コンテンツがすでにキャッシュされている場合、再度ダウンロードする必要がないため、リソースを節約できる
- 帯域幅の節約: キャッシングは、クライアントとサーバーの両方にとって貴重な帯域幅を大幅に節約する
キャッシングは、クライアントの読み込み時間の高速化にもつながり、結果としてユーザー体験を向上させます。
Googlebot がサポートする HTTP キャッシュ
Googlebot は、次の 2 種類の HTTP キャッシュの技術をサポートします。
ETagとIf-None-Matchの組み合わせLast-ModifiedとIf-Modified-Sinceの組み合わせ
Google としては、ETag / If-None-Match の構成を強く推奨しています。
こちらの方がエラーや設定ミスを起こしにくいからです。
しかしながら、可能な限り Last-Modified / If-Modified-Since との併用が望まれます。
こちらしかサポートしないシステムがウェブに存在します。
それぞれのキャッシュ方式の詳細な構成方法は技術ドキュメントとブログ記事を参照してください。
📝すずき注：この記事を書いている時点では、どちらも英語のみ