Mozillaの開発者たちは数年前からFirefoxのマルチプロセス化に取り組んできた（Electrolysisプロジェクト）が、プラグインの別プロセス化を達成した時点でFirefox 4の完成を優先することにしたため、しばらくの間その歩みはゆっくりしたものになっていた。しかし、Products team blog『goals for multi-process firefox』によると、現在では本格的な開発が進んでいるという。
上記の記事ではマルチプロセス化がもたらすメリットを紹介しているのだが、それを説明する前に、そもそもマルチプロセス化とは何だろうか。『Firefoxのマルチプロセス化はフェーズ2へ』で書いたように、Webブラウザのユーザーインターフェイス（UI）を表示するプロセス（クロームプロセス）と、Webコンテンツを表示するプロセス（コンテンツプロセス）を分離することが第一歩だ。そして、コンテンツプロセスはさらに細分化される。Google Chromeはこの細分化を徹底しており、タブごと、拡張機能ごとにプロセスが割り当てられている。
約束された未来
マルチプロセス化が実現すると、FirefoxのUI応答性が向上する。シングルプロセスの場合、すべてのWebページは単一のヒープ領域を共有し、クローム側ともメモリを共有することになる。不要になったJavaScriptのオブジェクトはガーベッジコレクション（GC）と呼ばれる処理によって破棄され、C++とJavaScriptの間の循環参照はサイクルコレクションと呼ばれる処理によって破棄されるが、探索から破棄までのコストは高く、他の処理を止めてしまう。かといってGC等を行わないとメモリ消費量が膨らんでしまうため、やらないわけにもいかない。Firefox 4ではこの問題を緩和するため「Compartments」という技術を導入し、「単一のヒープ領域」の制約を脱したものの、短時間のGCも積み重なるとメインUIに影響するのだという。そこで、クロームプロセスをコンテンツプロセスから分離することが抜本的な解決策となる。
次に、マルチプロセス化によって、マルチコア化というCPUのトレンドに対応できる。最近のOSは既にマルチコアを前提にしているため、Firefox側で対応すれば、プロセスを適切にコアに割り当ててくれるはずだ。つまりパフォーマンスの向上が期待できる。主にコンテンツプロセスの細分化に関わってくる点である。
そして、マルチプロセス化は、メモリの挙動を予測可能なものにするという点でも重要だ。改良を重ねているとはいえ、Firefoxが単一のプロセスで長期間動作すれば、メモリリークがどうしても発生してしまう。プロセスが複数であれば、終了したプロセスが占有していたメモリはOSに返還されるので、この問題を小さく抑えることができる。これもコンテンツプロセスの細分化に関わる。
マルチプロセス化は、クラッシュの防止にも役立つことがよく知られている。あるWebコンテンツが原因でクラッシュしても、別のタブは無事というわけだ。加えて、Mozillaは、ユーザーからクラッシュレポートを受け取っているが、解析範囲が絞られるので原因の分析がしやすくなるという副産物もある。
セキュリティの面でもマルチプロセス化の効用は大きい。ただ、分離されたプロセスがシステムリソースへのアクセスを適切に制限されているという前提が必要だ（サンドボックス）。
プロセス・オン・デマンド
Firefoxがマルチプロセス化することのメリットは大きいが、他方で、コンテンツプロセスの細分化にはメモリ消費の増大という副作用が生じることも忘れるわけにはいかない。Chromeのように徹底することがベストとは限らないのだ。
上記『Firefoxのマルチプロセス化は〜』でも触れているように、Mozillaはメモリ効率を考慮し、「プロセス・オン・デマンド」を目指すと述べてきた経緯がある。ここで問題になるのは「オン・デマンド」の部分で、必要に応じてプロセスを割り当てるとして、その必要性をどのように判断するのか。
現在判明しているところでいえば、Add-on SDK（旧Jetpack）で作成されたアドオンは、独立したプロセスを割り当てられるようになる予定だ。『Re: "Jetpack and making the UI world adopt HTML5"について』で紹介したように、このことはかねてから計画されていた。ユーザーはアドオンがFirefox全体をクラッシュさせるのを望まないだろうだろうから、合理的な判断といえる。ただ、mozilla.dev.platform『Per-tab memory accounting』において主要開発者のBenjamin Smedberg氏は「jetpack-style addons into a separate process」と表現しており、Chromeとは違ってアドオン用プロセスが1つだけ用意されるのではないかとみられる。
ピン留めしたタブ（App Tab）や、将来的な導入が予定されているHome Tabも、ユーザーの選択やその有する機能から考えて、独立したプロセスを割り当てられるのが適当だ。Firefoxを起動中はこれらのタブが開かれ続けているはずであり、クラッシュの影響を受けないことが望ましいからだ。
それ以外となると、Firefoxがユーザーの期待を予測するのは難しい。いっそタブグループ機能（Panorama）と連動させてはどうだろうか。ユーザーが複数のタブをまとめたグループに、独立したプロセスを割り当てる。もちろん1つのタブでクラッシュが起きると、グループ内のすべてに影響は及ぶが、その数はさほど多くないだろうし、セッション復元の画面が直ちに表示されればユーザーのストレスも軽減されよう。
とはいえ、Panoramaがマルチプロセスの中にうまく溶け込むためには、自身にも改善が求められる。MozillaWiki『Firefox/Features/Panorama All Windows UI』によれば、将来的にすべてのウィンドウからすべてのタブグループを扱えるようにするそうだが、この機能は必須だろう。そして、ユーザーがもっとタブグループを使いたくなるような工夫がほしい。
ユーザーの利便性を高めるものとして、『Tab Focus: Automagically Organize Tab Groups』で紹介されているMozilla Labsの実験的アドオン「Tab Focus」に注目しておきたい。アドオンバーのアイコンをクリックすると、タブの親子関係を考慮して自動的にグループ化してくれる拡張機能だ。この機能がFirefox本体に統合されれば、今よりもずっとタブグループの利用者は増えるだろう。欲をいえば、ユーザーが意識的にグループ化の指示を出さなくてよい、インテリジェントな方法を見つけたいところだ。
最後に、仮にPanoramaをマルチプロセスと結びつけるにせよ、ユーザーが別のあり方を望むなら、すぐにそれを実現できるようにしておくべきだ。つまり、オプション画面でChromeのような1タブ・1プロセスを選ぶことも、従来どおりに近い全タブ・シングルプロセスを選ぶこともできるようにする。ユーザーの選択に柔軟に対応するのがFirefoxの良さなのだから。
