ブラウザが毎年重くなり続ける理由

毎年同じ不満。かつてネットブックで動いたブラウザが、今はタブ数枚に2GBを要求する。これは手抜き設計ではない——効果が複利で積み上がる3つの決断の結果だ。セキュリティのためのプロセス分離、機能を捨てられないプラットフォーム、そしてRAMが安くなるより速く重くなったWebサイト。

分離がすべてを倍にした

Spectre時代の強化以降、Chromiumは各サイトを専用プロセスで実行し、Firefoxも同様のサイト単位分割に続いた。拡張機能をいくつか入れた15タブのセッションは、軽く25以上のプロセスになる——ブラウザ本体、GPUプロセス、ネットワークサービス、そしてサイトごとのレンダラ。サイト分離は紛れもないセキュリティ向上だ。乗っ取られたレンダラは他サイトのデータを読めない。ただ、どのプロセスもレンダリングスタックの全額を支払う。2014年に1つのプロセスを分け合っていた15タブが、今は入場料を15回払っている。

拡張機能もプロセスだ。Manifest V3以降、イベント駆動のservice workerとして動き、ルールが必要なときに目を覚まし、開くすべてのページにcontent scriptを注入し続ける。「小さい」拡張機能の12個は、追加タブ数個分のメモリ重量であり、1個の暴走が全員を食い尽くすこともある。Chrome内蔵のタスクマネージャー（Shift+Esc）は、タブごと・拡張機能ごとのコストを名前付きで表示する。そこで5分過ごす方が、どんな一般論よりも役に立つ。

プラットフォームは増える一方

ブラウザは全員に同じバイナリを配り、現代のウェブにできることすべてを積んで出荷する：WebGPU、WebAssembly、WebRTC、WebCodecs、service worker、インストール可能なアプリ。機能の削除はほぼ不可能だ——どこかの銀行やイントラネットが今も2013年のAPIに依存している——だからエンジンは溜まる一方。リリースごとにコーデック、ネットワークスタック、安全ブラウジングリストもバックグラウンドで更新される。昨日再起動しなかったブラウザは、自分で3回パッチを当てている。

Webページ自身も同じ速さで太った。平均的なページはコンテンツが見える前にメガバイト単位のJavaScriptを積み込み、広告とアナリティクスはそれに便乗し、「軽い」ニュースサイトですら100個のスクリプトを軽く読み込む。ブラウザは誰の重さを運んでいるか率直に教えてくれる——内蔵タスクマネージャーを開いて、ドキュメントのページとショッピングサイトを比べてみればいい。エンジンは重くなった。だが積み荷の方が速く膨らんだ。

JIT付きの完全なJavaScriptエンジン——コンパイラのコストはスクリプト重いサイトだけでなく全プロセスが支払う
GPUコンポジットとコーデック——各レンダラはグラフィックスパイプラインの持ち分を背負う
service worker——サイトは見えるタブなしに裏でロジックを動かし続ける
インストール可能なPWA——Webアプリは専用のランタイムを持ち、小さなブラウザと区別がつかない
拡張機能——1個1プロセスに加え、開くすべてのページに注入されるcontent script

実際に請求書を減らすもの

正直な第一歩はタブのサスペンドで、それは最初から組み込まれている。Edgeのスリーピングタブは、こちらで制御できるタイマーでバックグラウンドタブを凍結し、Chromeのメモリセーバーは非アクティブなタブを解放してクリックで復元する。どちらも実際のメモリを回収し、常に生存させておきたいサイトを固定例外にできる。第二歩は拡張機能の監査だ。見覚えのないものは削り、毎時ではなく週1の利用のものは無効化し、タスクマネージャーの数値を前後で比べる。

効かないもの：「軽い」ブラウザ探し。同じエンジンで動くものは何でも、同じプロセスごとのアーキテクチャと同じプラットフォームの重さを背負う——互換性かセキュリティ更新を、誤差レベルの節約と引き換えに失うだけだ。放置されたエンジンの古いフォークは重いより悪い。パッチの当たらない攻撃面だ。RAM増設こそ、トレンドラインに実際に合う地味な解決策——ブラウザはWebのためのOSであり、OSを最小構成で回す人はいない。