ChromeがRAMを食う理由：食欲の正体を解説

サイトごとに1プロセス：一行で語れる全て

Chromiumはブラウザを多数のOSプロセスに分割する。タブ用のレンダラ（サイトごとに1つ。サイト分離は1つのタブの中でも別サイトを別プロセスに置く）、GPUプロセス、ネットワークサービス、ストレージサービス、そして読み込まれた拡張機能ごとに1プロセス。狙いはダメージコントロールだ——異常終了したレンダラが連れていくのは1タブでブラウザ全体ではないし、乗っ取られたレンダラは他サイトに直接アクセスできない。代償として、どのプロセスも実行時のオーバーヘッドを背負う。開いた20サイトは、ライブラリ、JITヒープ、レンダリングバッファの持ち分をそれぞれ抱えた20個の小さなChromiumというわけだ。

合計は予想より速く膨らむ。その数字はタブだけではないからだ：

サイトごとに1つのレンダラプロセス——10タブの10サイトに、他ドメインからiframeで埋め込まれた分が加わる
有効な拡張機能はすべて、アイドル時でさえ独自のバックグラウンドプロセスを走らせる
GPUプロセスはデコード済み画像、タイル、動画フレームを保持する——4KのYouTubeタブは大部分がこれ
service workerはタブを閉じた後も生存し、オフラインアプリを即応可能に保つ
オムニボックスの候補による先読みとプリレンダリングは、訪問する前にメモリを占有する

Chromeがメモリを返さない理由

2つ目の理由はChromiumのアロケータPartitionAllocだ。解放されたページをWindowsに返す代わりに、各プロセス内で即時再利用のためにキャッシュする。タスクマネージャーはこのキャッシュプールを、技術的には空きであるにもかかわらずChromeの使用量の一部として表示する。だから数字は、実際のシステムへの圧力より恐ろしく見える。ブラウザは本当の圧力下ではメモリを解放する——重いアプリを閉じた後にChromeが「復活」するのはそのためだ——が、暇なマシンでは、支払ったものを意図的に握り続ける。

保持されているメモリの一部は正真正銘のキャッシュだ。戻る/進むキャッシュは「戻る」ボタンを一瞬にするためにレンダリング済みページを保管し、ディスクキャッシュのマッピングはファイルの再読み込みを避ける。何日も動き続けたブラウザが起動直後より重く見えるのもこのため——持っておく価値のあるものをさらにキャッシュしただけだ。これが「使われないRAMは無駄なRAM」の議論で、この場合は技術的に正しい——代替案は、再訪するすべてのページの再レンダリングなのだから。

足跡を実際に縮めるもの

chrome://settings/performanceでメモリセーバーを有効化する。非アクティブなタブを休止させ、そのレンダラを解放する——多タブセッションでは最大のレバーだ。次に真犯人を調べる：Shift+EscでChrome独自のタスクマネージャーを開き、メモリでソートする。大半の場合、重いサイト1つ（Web IDE、ビデオ通話、肥大化したWebメール）か拡張機能1つが、普通のタブ40枚より重い。拡張機能は特に怪しい。1つ1つがすべてのウィンドウにプロセスを追加し、多くは常時稼働している。

その先の正直な答えは魔法ではなく算数だ。休止タブを減らし、拡張機能を減らし、誰も読まない永久固定ダッシュボードをなくす。ハードウェアアクセラレーションの切り替えはGPUメモリとCPU負荷を交換する——弱い内蔵GPUでは有利なこともあれば、逆のこともある。効かないもの：ワーキングセットを強制的に刈り取る「RAMクリーナー」。数字は下がり、刈られたものを再取得する間、ブラウザはもたつく。