Chromeではキャッシュの効率改善を目的とした「Cache Transparency」という仕組みが検討されているようです。
これは、「Double-keyed HTTP cache」によってキャッシュヒット率低下を緩和します
まだまだ実験を行っている段階ですが、簡単にメモとして残しておく
背景: Double-keyed HTTP cache
Double-keyed HTTP cacheは、ユーザのプライバシーを保護するために、HTTPのキャッシュをサイトごとに分離する仕組みです。
簡単な例で見ていきましょう
- https://a.example のサイトは、https://cdn.exampleより js, css, 画像などのファイルを読み込みます
- https://b.example のサイトは、https://cdn.exampleより js, css, 画像などのファイルを読み込みます
この時、https://cdn.exampleから読み込んだリソースをキャッシュするわけでが、同一のリソースであったとしてもa.example用とb.example用でキャッシュ領域を分けます。
こうしておかないと、a.example側はアクセスしたユーザがb.exampleにすでにアクセスしたことがあるのか、リソースの読み込み速度から類推することができしていまいます。
この時、キャッシュのキーが 『読み込んだサイト(URLバーに表示されてるURL)』+『読み込んだリソースのURL』と２つのキーになることからDouble-keyed HTTP cacheと呼ばれています。
Chromeの分析では、Double-keyed HTTP cacheによりキャッシュのヒットミスが3%増えたという分析がなされています。
Cache Transparency
Cache Transparencyは、Blink-devメーリングリストの下記のスレッドで議論されています
groups.google.com
主な目的は、Double-keyed HTTP cache導入によって上がったキャッシュのヒットミス率の低減があげられています。
その方法としては、一般に広く利用されているリソースであれば、Single-Keyキャッシュで扱ってもユーザのプライバシーには影響しないという仮説に基づいています。
"一般に広く利用されているリソース" は、Google独自の方法(Chromeのテレメトリ, クローラー)で調査され、Pervasive Payloads listとしてリスト化されます。Pervasive Payloads listには、リソースのURLとペイロードのハッシュ値が含まれ、それに一致するリソースはSingle-Keyキャッシュとして保存されます。
まだ事前の効果測定を行う段階で、実験として以下の条件を満たすリソースを対象にすることが議論されていますが。まだFixはしてなさそうです。
- 少なくとも500のサイトに含まれる
- 月に少なくとも1,000万回フェッチされたもの
