https://www.chromium.org/developers/design-documents/process-models

Chromiumがサポートするレンダラのプロセスモデル

全体像

ブラウザで実行されるウェブコンテントは膨大な量に進化していて、ウェブサイトはもはや単なるドキュメントではなくアプリのようになっている。この進化がブラウザをOSのように変形させた。Chromiumはこれらのアプリを動かすOSのような位置づけであり、OSがプロセスでアプリを分離するようにChromiumでもサイトごとにプロセスを分離している。Chromiumのタスクマネージャでリソース使用状況を見ることもできる。

サポートされるモデル

４つのモデルをサポートしている。デフォルトではサイトのインスタンスごとにOSプロセスを持つモデル。ユーザはコマンドラインからどのモデルを使うか選択できる。ウェブサイトのすべてのインスタンスを１つのプロセスで持つモデル。関連タブグループで１つのプロセスのモデル。完全に１つのプロセスのモデル。以下ではこれらの詳細を説明。

サイトインスタンスごとにプロセスを持つモデル。

デフォルトのモデル。ユーザが訪れたサイトのインスタンスごとにプロセスを作成する。違うサイトは別々にレンダリングされることを保証する。同じサイトへの別々の訪問でもプロセス分離される。１つのレンダラの失敗（クラッシュなど）が他のレンダラに影響しない。このモデルは以下の両方を基礎にしている、すわなちスクリプトでつながっているコンテントの起源とタブ間の関連。結果として２つのタブは同じプロセスでレンダリングされることがあり得し、そのタブが他のサイトへ行けばタブのレンダリングプロセスに切り替わることもあり得る。（現在の実装には但し書きが必要で、詳しくは下の但し書き参照）

具体的にするため、サイトを登録されたドメイン名と定義する（例：google.com bbc.co.uk）それに加えてスキーム（例：https://）も加わる。これはSame Origine Policyの定義と同じ。ただしそれはサブドメイン（例：mail.google.com docs.google.com）とポート（例：http://foo.com:8080）も同じサイトになる。これはjavascriptがアクセスできる範囲。

サイトインスタンスとは同じサイトで連結されたページの集合である。２つのページがjavascriptで参照されていれば、連結とみなす。（例：１つのページがjavascriptで新しいウインドウを開いた場合）

強み

• 別々のサイトはコンテントが分離される。
• 同じサイトでも連結されていなければ分離される。

弱み

• メモリを使う。がその分安定する。
• 実装が複雑になる。

サイトごとにプロセスをもつ

コマンドラインで--process-per-siteを指定する。

強み

• 違うサイトではコンテントを分離する。
• メモリが少なくて済む。

弱み

• レンダープロセスが大きくなりえる。google.comのようなサイトではいろいろなアプリがあるので、これを１つのプロセスで扱うとそのプロセスが肥大化するし、レンダリングの失敗がすべてのgoogle.comを開いているタブに影響する。
• さらに実装が複雑。

タブごとにプロセスを持つ

上記2つはコンテントのオリジンで判断していたが、これはそれよりも単純なスクリプトでつながっているもので１つのプロセスをもつ。--process-per-tabを指定して選択。

スクリプトでつながっているサイトをブラウジングインスタンスと呼ぶ。これはHTML5では"関連するブラウジングコンテキストの単位"ともいう。

強み

• 理解しやすい。

弱み

• ブラウジングインスタンスは一度決まったら分離しないので、１つのタブが他のタブに影響することがあり得る。

シングルプロセス

コマンドライン--single-processで選択。ブラウザとレンダリングが１つのプロセス内にある。

これはマルチプロセスのオーバヘッドを測るために提供される。レンダープロセスがブラウザプロセスにまで影響するので安全でない。テストや開発支援目的である。バグがある可能性もある。