ブラウザのマルチプロセスアーキテクチャ

ブラウザのマルチプロセスアーキテクチャとは

現代のブラウザ(Chromeなど)は1つの巨大なプログラムではなく、複数のプロセスに分かれて動いています。1つのタブがクラッシュしても他のタブに影響しない、Webページのコードとブラウザ本体を切り離してセキュリティを保つ、といった目的があります。

主なプロセス

レンダラープロセス内のスレッド分担

レンダラープロセスの中も、さらに役割ごとにスレッドが分かれています。

• メインスレッド — JSの実行、[[DOM]] 操作、レイアウト計算、ペイントの指示までを担当する。重いJS処理があるとここが詰まり、画面が固まって見える
• コンポジタスレッド — レイヤーを合成して画面に出す。メインスレッドとは別に動く

[[ブラウザレンダリングの仕組み]] で「transform や opacity の変更は軽い」と説明されるのは、この2つの変更だけならメインスレッドを介さずコンポジタスレッドだけで完結するためです。width の変更のようにレイアウトが絡む変更は、必ずメインスレッドに戻って再計算が必要になります。

初学者向けポイント

• 開発者ツールのタスクマネージャー(Shift+Esc)で、タブごとのプロセスとメモリ使用量を確認できる
• 「重いタブを閉じたらブラウザ全体が軽くなった」という体験は、プロセスが分かれている証拠
• Web Workerを使うと、ページ側のJSもメインスレッドから重い処理を切り離せる(こちらはOSのプロセス分離とは別の、JS実行環境内の仕組み)

関連技術とのつながり

• [[ブラウザレンダリングの仕組み]] — レンダラープロセス内で実際に行われる処理の中身
• [[プロセスとスレッド]] — OSレベルの概念をブラウザがどう活用しているかの具体例
• [[Webパフォーマンス最適化]] — メインスレッドを塞がない設計が高速化の鍵
• [[並行処理と非同期]] — メインスレッドと別スレッドで役割を分ける発想の類似点

Q: レンダラープロセスの説明として正しいのはどれ?
- [ ] 全タブが1つを共有する、ブラウザ全体のUIを管理するプロセス
- [x] タブごとに立ち、そのページのHTML/CSS/JSの実行を担当するプロセス
- [ ] ネットワーク通信のみを担当する専用プロセス
解説: レンダラープロセスはタブごとに立ち、そのページのレンダリングとJS実行を担当します。分離されているためタブ間の情報漏洩を防げます。

Q: transformやopacityの変更が軽いとされる理由はどれ?
- [x] メインスレッドを介さずコンポジタスレッドだけで処理が完結するため
- [ ] GPUプロセスを経由せずCPUだけで処理されるため
- [ ] ブラウザプロセスが直接処理するため
解説: transform/opacityの変更はレイアウト計算を伴わず、コンポジタスレッドだけで合成できるため軽量です。

Q: メインスレッドが担当する処理はどれ?
- [x] JSの実行、DOM操作、レイアウト計算
- [ ] レイヤーの合成のみ
- [ ] タブ間のプロセス管理のみ
解説: メインスレッドはJS実行・DOM操作・レイアウト計算・ペイントの指示までを担当し、重い処理があると画面が固まって見える原因になります。