■TBSのニュースサイトヤバない？(追記)

はてぶの上位にちょいちょい載ってるTBS系のニュースサイト、newsdig.tbs.co.jpについて。

https://b.hatena.ne.jp/site/newsdig.tbs.co.jp/

何がヤバいかって、くっそ巨大なCookie(LocalStorageとかも含むのか知らんけど)をしこたま保存してんのよ。

気付いた時点では640MBも占有してた。別に巡回チェックしてるわけでもなく、話題に挙がってたら見てみることもある程度のアクセス頻度なのだが。

Chromeユーザーはアドレスバーに↓コピペして確認してみてくれ。

chrome://settings/content/all?searchSubpage=tbs.co.jp&search=cookie

試しにCookie消去してから、ただ開いただけでサイト上で何の遷移もしてないのに279MBも保存された。

次点ではpresident.jpが553MB消費してた。(こっちも話題に挙がってたら見てみることもある程度。)

(その次にはGoogleが数百MBオーダーで消費してたけど、これはGoogleドライブのオフラインキャッシュとか考えれば妥当。他に数百MBオーダーで消費してるサイトは無かった。)

多くのサイトは数バイト～KBオーダーなのに、こいつら何保存してんのか不気味すぎる。

(追記)

各自の環境の消費量を教えてくれた方々や有意義なコメントを下さった方々ありがとうございます。

始めにお断りしておくべきだったかもしれませんが、自分はソフトウェア系ではありますが、Webエンジニアではありません。認識が浅かったり、古かったり、そもそも間違ってる可能性もあります。

CookieじゃなくてCacheStorageやんけと突っ込みもいただいていますが、「LocalStorageとかも含むのか知らんけど」と書いておいた意図は(どのような技術要素かはどうでもよくて)ユーザー端末に保存されるデータボリュームについての話を意図しています。ChromeのCookie絡みの設定画面での表示なのでこのような書き方をしましたが、解り難かったのならごめんなさいね。冗長ながらも認識齟齬を招かないように平易な表現で書くと、「ユーザの明示的な承諾なくユーザー端末に保存されるデータがデカイんだが」って話です。

で、各自の環境で「ユーザの明示的な承諾なくユーザー端末に保存されるデータ」が数GBオーダーにも及ぶという事例が少なからず報告されて、自分の環境だけではない事象だということが判りました。

さらにtbsとpresident以外にもいくつかのサイトが同様に肥大化していることも知れました。

結果的にはid:hinaloeさんの解説が解りやすかったです。ありがとうございます。

https://blog.hinaloe.net/2023/04/27/chrome-too-large-cache-storage/

CacheStorageがChromeの表示と、実際のディスク消費量と一致していないことが原因であると理解しました。

追試してみたところ私の環境ではChromeの開発者ツールでの表示が74MBで実際のWindowsのファイルシステム上は33.9MB消費されました。

実際のストレージの消費は表示値の半分程度ということになり、id:hinaloeさんの1.4GBに対して5MBのように実際の約0.3%という結果とは大きく乖離がありますので、各環境で大きく違いそうな気がします。

気になる方は↓を各自ご確認いただくとよいかと思います。

%USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default\Service Worker\CacheStorage

※配下のどのディレクトリが対象サイトのものなのか一意に特定する情報が無さそうなので、Chrome開発者ツールのApplicationタブの左上の方にあるService Workersを選択すると、右側にReceived YYYY/M/D HH:MM:SSみたいな表記が有るので当該時刻に変更されたタイムスタンプを持つディレクトリを特定するような感じになるかと思います。

ついでに開発者ツールを触っていて気付いたベースで書いておくと、

• ApplicationタブでCacheStorageの各アイテムのResponseヘッダのexpiresを見ると概ね1か月後が指定されている
• 開いてもいない記事の画像がCacheStorageに格納されている(スクロールすると下の方に載ってる)
• Networkタブで確認すると、ページのロードが一見完了したように見えても延々と動画の断片や画像らしきデータが転送され続けている(動画の断片のexpiresは即時指定のためCacheStorageには入らない模様)

といった感じで、ユーザが見たものをキャッシュしているのではなくて、先読みしてるような挙動に思えます。

ロード時間短縮でUX改善を狙ったものかもしれませんが、個人的にはそれを1か月も保持し続けるのは過剰な感じがしますが世の中的にはどうなんでしょうね？

あと、スマホの場合の挙動どうなってんすかね？

(追記2)

hinaloe氏の投稿で紹介されているStackOverflowの投稿やそのリンク先のChromiumのバグレポートのやり取りまで目を通してみると、特に理由の説明なく平均7MBがパディングされると書かれた投稿があります。

https://stackoverflow.com/questions/39109789/what-limitations-apply-to-opaque-responses

https://bugs.chromium.org/p/chromium/issues/detail?id=796060

該当するソースコードは↓のようです。

https://source.chromium.org/chromium/chromium/src/+/main:content/browser/cache_storage/cache_storage_cache.cc

この中で、ComputeRandomResponsePadding()という関数を呼び出しておりその実体は↓のようです。

https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:storage/common/quota/padding_key.cc;drc=332f92aab4a32607f7813ac1a824f6ff0d86c369;l=47

この関数は符号無し64bit整数の乱数(つまり、0～18446744073709551615のいずれか)を14431 * 1024 = 14777344で割った剰余(つまり、0～14777343≒約14MiB)を返却します。

これがパディング値として採用されることになりますが、乱数が正規分布している前提で、平均すると(最大値14MiBの半分で)約7MBになるよねってことだと思われます。

故にChromeの設定画面から確認できるCookie等(LocalStorageとかCacheStorageとか諸々含む)のサイズは、概算してCacheStorageに存在するファイル数×平均7MBが過大計上されていることになりそうです。

これでChromeの設定画面から確認できるサイズと、実際のファイルシステム上で消費されているサイズの違いは合理的に説明できますが、TBS等の特定のサイトだけデカくみえる理由の説明にはならないのです。

つまり、以下のような可能性がありそうです。

1. Chromeの設定画面から確認できるサイズほど巨大ではないが(他のサイトと比較して)相対的にデカイ？
2. ComputeRandomResponsePadding()の結果が顕著にデカくなる乱数が生成される個別要因がある？
3. それ以外

なんなんすかね？

Permalink | 記事への反応(27) | 22:10

ツイートシェア