ブラウザのユーザーインターフェイス（UI）を表示するプロセスと、Webコンテンツを表示するプロセスを分離する―moz.dev.planningで発表されたのはそんな計画だ。
Mozilla Wikiの『Content Processes』にプランが記載されている。それによると、UIの応答性を高め、安定性を向上させ、マルチコアのマシンでパフォーマンスを上げることが当初の目標だという。目標どおりなら、コンテンツの表示でビジー状態になってもメニューを開けるとか、クラッシュが起きてもプログラム自体は生きている場合があるとかいったことが実現する。また、最近はマルチコアのPCが大半だし、OSもマルチコアをサポートしているから、多くのユーザーがパフォーマンスアップの恩恵を受けられるだろう。
計画は4つのフェーズに分けられているが、フェーズ1のゴールが2009年7月15日、フェーズ2のゴールが2009年11月1日となっているのみで、それ以降は未定だ。ただ、Firefox.nextが2010年第2四半期以降のリリースになると予想されることからすると、その範囲には収まっている。
フェーズ1ではFirefoxのクローム（UI部分）を使わず、プラットフォームもLinuxかWindowsのどちらか一つに絞るなどとしており、Trunkとは別のリポジトリを使用するようだ。機能をかなり制限した状態でプログラムを作成し、とりあえずコンテンツのプロセスだけで動作するところまでもっていく。
フェーズ2ではクロームとの協調を図る。クロームとコンテンツのプロセスが分離された状態で、Firefoxの基本機能が一通り動作することを目指す。
フェーズ3では拡張機能の互換性を確保し、アクセシビリティを高い水準で維持し、パフォーマンスのチューニングを行う。クロームからコンテンツへアクセスする処理が大幅に変わるため、APIも変更されるだろう。Firefoxのシステムに深く関わるようなアドオンほど影響は大きいはずだ。そして、このフェーズのどこかでTrunkと統合される可能性が高い。
フェーズ4では、コンテンツのプロセスを多重化する。要求に応じて、タブごと、タブグループごと、ドメインごとといったプロセスの割り当てが可能になるそうだ。それに応じて、画像キャッシュやフォントキャッシュも分離される。ただ、Google Chromeのようにサンドボックスを実現するところまではいかず、それは将来の目標とされている。なお、プロセスの多重化により起動時間やメモリ使用量に悪影響が出る危険性があるとのこと。
この開発に当たって、ネットワークライブラリ (Necko) をChromiumのネットワークスタックに置き換えることも検討中だ。ChromiumはGoogle Chromeの開発版で、コードがオープンソースだから可能であるとはいえ、FirefoxがGoogle Chromeのコードをダイレクトに取り込むとなれば重大な決定である。なお、この点に関してはDevelopment Meetingでも議論が交わされた。そこではChromiumのネットワークスタックを使用してNeckoのAPIを実装するのは難しいかもしれないとの指摘も見られた。
実現すれば素晴らしいが、素人目にも相当の作業量が必要なことはわかる。スケジュールどおりに作業を進めるのは難しいだろう。また、アドオン開発者への負担も気になるところだ。
（09/05/09追記）Mozilla Links日本語版『Firefox がマルチプロセッササポートを予定』も参照。
