Firefox 48でマルチプロセス機能（e10s）が導入され、Firefox 50から52にかけて、RTL言語ロケールやタッチスクリーン環境でも順次e10sが有効化されるようになった。また、拡張機能をインストールしている環境でも、WebExtensionsベースのもの（Firefox 49以降）やe10s互換性のあるもの（Firefox 50以降）については、有効化を妨げないようになった。若干予想外な出来事として、Firefox 51で追加された拡張機能のホワイトリストがその後撤回され、Windows版でアクセシビリティツールが動作している場合はFirefox 55まで有効化が延期されるといったことがあったものの、2017年4月3日（米国時間）時点で、リリース版ユーザーの52.82％がe10s有効化に至っている。
こうした状況を踏まえ、MozillaはFirefoxの多プロセス化を実行に移す。その中心はcontentプロセスの複数化（e10s-multi）だ。最近までFirefox 55がそのターゲットとされていたが、Firefox 54に前倒しされる可能性が高くなってきた。
2017年1月下旬にFirefox Nightly 54で2つのcontentプロセスが（Bug 1303113）、3月中旬にFirefox Nightly 55で4つのcontentプロセスが（Bug 1336398）、それぞれ有効化され、4月上旬にはFirefox Aurora 54でも4つのcontentプロセスが有効化された（Bug 1304546）。この流れはロードマップどおりであり、あとはBeta版でのテストを経るのみとなっている。
Mozillaがe10s-multiにおいてcontentプロセスを4つまで増やす背景には、省メモリ化の進歩がある。Are they slim yet, round 2 – Eric Rahmによれば、2016年2月から1年余りの間にデスクトップ版の各プラットフォームで、多プロセス化した場合の消費メモリが顕著に低下したという。1年前にcontentプロセス×1で消費したメモリ量は、現在のWindows版だとcontentプロセス×2に相当し、macOS版に至ってはcontentプロセス×4に相当する。Chromeとの比較でも優位に立っていて、特にWindows版/Linux版では差が大きい。
e10s-multi以外の多プロセス化については、mozilla.dev.platformのAll the processesスレッドにまとめられている。既にWindows版ではGPUプロセスの導入が始まっており、今後はWebExtensionsベースの拡張機能やPDFium/Pepper API版Flashのほか、Service workerも独立したプロセスの対象となっていく。
以上のように多プロセス化が展開される一方、その基礎となるe10s有効化は完全実施の時期がFirefox 57まで延期された。当初はFirefox 53で実現する予定だったが、拡張機能のe10s対応がMozillaの想定していた以上に進まなかった。
Firefox 56まで、拡張機能をインストールしている環境では、すべてがWebExtensionsベースまたはe10s互換性ありになっていない限り、e10sは有効にならない。そのため、古い拡張機能を使い続けている場合、Firefox 57にアップデートした時点でその拡張機能が動作しなくなるばかりか、本体がいきなりe10s-multiの状態になる。一部では混乱もありそうだ。
（17/06/13追記）
Firefox 54正式版のリリースに伴いcontentプロセスの複数化（e10s-multi）が有効になるのは、「e10sが有効かつアドオンをインストールしていないユーザー」の80％にとどまる（Bug 1367244）。Mozillaは、次のFirefox 55では「e10sが有効かつ従来型アドオンをインストールしていないユーザー」全員を対象にe10s-multiを有効化しようとしている。
