CDNのキャッシュは実はドメインが変わると効かなくなる事実とその理由、対処方法
あるサイトでajax.googleapis.com/../jquery.min.jsなどCDNにアクセス後、自分のサイトで同じリソースをアクセスしてもなんとキャッシュは効きません。この記事ではその理由と対処方法を紹介します。
ステートパーティショニングとは
この不効率の原因はブラウザのプライバシー対策です。例を挙げます。
- ユーザーが知られたくないサイトSECRETにアクセスします
- このサイトではCDN-Aからfoo.jsファイルを読み込みます
- このユーザーがその後、調査サイトにアクセスします
- 調査サイトでは同じくCDN-Aからfoo.jsファイルを読み込みます。そしてここで時間を測ります。
- もしここで時間が早ければ、「ああ、このユーザーはSECRETサイトにアクセスしたことがあるな」と判断する
というわけです。
これはJSファイルに限らず、画像やfaviconなど多くのリソースに適用されます。
そこで、これを出来なくするポリシー仕様がステートパーティショニングというわけです。
やり方は簡単、ブラウザがキャッシュする時に、かつては
https://ajax.googleapis.com/../jquery.min.js
というキーでキャッシュしていたのを
https://ajax.googleapis.com/../jquery.min.js'読み込み元ドメイン名
のようなイメージでキーを増やしているわけです。
なのでドメインが変わるとCDNのリソースは別のリソースとして扱われるわけです。
ステートパーティショニングはユーザーにとって有益か
このステートパーティショニング、たしかに言われてみればトラッキングを防げますが、その結果はどうなっているでしょう。
おそらくユーザーのキャッシュの中は全く同じanalitics.jsやjquery.jsだらけで非常に効率の悪い状態になってそうです。
昨今ではjsは大した大きさではないのと回線速度が速いのでさほど問題ではありませんが、効率の悪いのは気持ちが悪いです。
ステートパーティショニングはオフにできるのか
これはFirefoxはできます。ステートパーティショニングを無効にするにはabout:configで以下のプロパティをfalseにします。
privacy.partition.network_state
これでCDNで一度読んだことのあるリソースは再利用されるようになります。
リスクとしては上に書いたようなトラッキングですが、そもそもトラッキングされたほうが便利じゃんという考え方もありますので。
まとめ
ということでCDNのクロスサイトでの共有時のキャッシュについて、あるサイトでajax.googleapis.com/../jquery.min.jsなどCDNにアクセス後、自分のサイトで同じリソースをアクセスしてもブラウザのstate partitioningポリシーによりトラッキング防止の為、キャッシュは効かないので不効率。気になる人はFirefoxならprivacy.partition.network_stateをfalseにしてみましょう。
リファレンス
https://developer.mozilla.org/en-US/docs/Web/Privacy/State_Partitioning
