Google Chrome Helper (Renderer)のCPU使用率を下げる

アクティビティモニタにGoogle Chrome HelperやGoogle Chrome Helper (Renderer) が並んでいても、最初に決めるのはどれを終了するかではありません。Chromeはマルチプロセスのブラウザとして作られており、1つのブラウザプロセスが多数の子プロセスを束ねます。Helperが増えるのはその設計の普通の姿です。調べるべきなのは、ページが落ち着いたあともCPU、メモリ、エネルギーが高いままのHelperです。その場合は対応関係を特定する必要があります。まとめて終了すると持ち主が見えなくなり、未保存の作業も消えます。Helperが複数あることはマルウェアの証拠ではなく、アクティビティモニタで続く高負荷は調べる手がかりであって結論ではありません。

Chrome Helper (Renderer) の負荷が高い場合

1. Chromeで「ウインドウ > タスク マネージャ」を開き、CPUまたはメモリ使用量で並べ替えます。
2. 負荷の高い項目を、タブ、拡張機能、Renderer、GPUプロセス、ブラウザサービスのいずれかに対応づけます。
3. 作業を保存し、特定できた項目だけを閉じるか終了してから、アクティビティモニタをもう1分見ます。

負荷が下がったままなら持ち主を特定できています。すぐ戻る場合はプロセスを見える状態に保ち、Helperをまとめて強制終了せず、以下の確認へ進んでください。

各Chromeプロセスの役割

ブラウザプロセスはページの外側、つまりウインドウ、タブ、メニュー、アドレスバー、子プロセスの寿命を持ちます。サイトのJavaScriptの大半はここでは動きません。

レンダラープロセスはウェブ文書を扱います。Chromiumは、1つのレンダラーに1つ以上のフレームが入ること、タブが必ず1つのレンダラーになるわけではないことを明示しています。デスクトップ版Chromeのサイト分離はサイトをセキュリティ境界として扱うため、クロスサイトのiframeには別のレンダラーが必要になることがあります。その追加プロセスはセキュリティのためのコストであり、メモリも使いますが、壊れている証拠ではありません。

Chromeは別のGPUプロセスも持ちます。ChromiumのGPUアクセラレーションによる合成の設計では、通常1つのGPUプロセスがブラウザインスタンス全体に仕えます。レンダラーは描画コマンドをここに送ります。GPUタスクの急増は合成やハードウェアアクセラレーションの問題であり、タブが多すぎる問題とは限りません。

ネットワークとストレージのサービス、そのほかサンドボックス化されたユーティリティプロセスも並びます。取得、キャッシュ、範囲の決まった作業を担い、侵害されたページがブラウザ全体に届かないようにします。タブが忙しく見えなくても、アクティビティモニタではHelperとして出ることがあります。

拡張機能に決まったプロセス名はありません。Chromeのタスクマネージャーでは拡張機能が独立したタスクとして出ることがあります。同じ拡張機能がレンダラーやバックグラウンドタスクの負荷を増やすこともあります。アクティビティモニタはその多くをGoogle Chrome HelperまたはGoogle Chrome Helper (Renderer) と表示します。名前は系統であり、対応表ではありません。

そのプロセスがChromeのものか確認する

何かを終了する前に、そのHelperが調べたいChromeのインストールに属するかを確かめます。Appleのアクティビティモニタのプロセス表示は、表示名以上の情報を出せます。

プロセスを選び、情報ウインドウを開き、開いているファイルとポートを見ます。本物のChrome Helperは、インストールされた Google Chrome.app バンドルの内側、多くの場合 /Applications/Google Chrome.app の下に解決されます。ダウンロードから起動したコピー、別のChromium系アプリ、関係のないパスは別件として調べます。「Google Chrome Helper」というタイトルだけでバイナリやフォルダを削除しないでください。名前は複製できます。実行ファイルのパスと所属アプリの方が強い証拠になります。

この確認は、別のChromiumアプリをChromeのせいだと誤認するのも防ぎます。多くのブラウザやElectronアプリは似た名前のHelper実行ファイルを同梱します。違うプロセスを終了してもChromeは冷えませんし、もう一方のアプリの作業は途切れます。

Chrome側の対応表とアクティビティモニタの推移を使う

パスが Google Chrome.app の内側なら、Chrome自身の表示に切り替えます。Chromeのタスクマネージャーは その他 › その他のツール › タスクマネージャー にあります。タブ、サブフレーム、拡張機能、GPU作業、ブラウザサービスを、リソース列つきで一覧します。問題に合う指標で並べ替え、タスクの名前が言えてから行を選びます。

プロセスを終了はブラウザ全体の終了より狭い操作ですが、無害ではありません。Googleは、そのタスク内の未保存の作業が失われると警告しています。下書き、途中のフォーム、進行中のアップロードは、レンダラーと一緒に消えることがあります。先に保存し、特定した行だけ終了します。

アクティビティモニタはシステム全体の推移を見る層です。ChromeがMacのリソースの持ち主か、負荷が1つのHelperに集中しているか、コストがCPU、メモリ、エネルギーのいずれかを示します。Helperを文書や拡張機能に確実に戻すことはできません。その内部関係はChromeのタスクマネージャーが持ちます。どちらか一方ですべて答えると思わず、両方使います。

複数のレンダラーが同時に高いままなら、共通原因を探します。同じサイト群、すべてのページに注入される拡張機能、バックグラウンドでまだデコードしているメディアです。サイト分離は意図してレンダラーを増やします。役に立つ問いは、どの分離されたタスクが作業を続けているかです。

CPU、メモリ、エネルギーは別の信号

Appleはエネルギー影響と12時間電力をエネルギーの指標として文書化しており、CPU使用率の別名ではありません。訴えに合う列を読んでください。

レンダラーはCPUが静かでも、サイトが独自プロセスに残るためメモリは大きいことがあります。初回描画の短いCPU急増も結論ではありません。ページが落ち着くまで待ち、同じタスクを十分な時間見て、瞬間と持続を分けます。

設定を変える前に主指標を1つ決めます。ファンがうるさいならCPUとエネルギー影響から始めます。メモリプレッシャーなら、Chromeのタスクマネージャーのメモリ列とアクティビティモニタのメモリ画面を使います。4つの数字をまとめて「Chromeが重い」と判断すると、次の比較ができなくなります。

原因を一つずつ切り分ける

特定したタスクを1つ終了する

Chromeのタスクマネージャーで、すでに名前をつけたタブ、サブフレーム、拡張機能を終了します。アクティビティモニタのHelper一覧をまとめて消さないでください。再読み込み後に同じ行が同じコストで戻るなら、原因は捨てられる残りプロセスではなく、そのページか、そのページに働く何かです。

拡張機能を1つずつ無効にする

Googleの拡張機能の操作は その他 › 拡張機能 › 拡張機能を管理、または chrome://extensions にあります。拡張機能を1つオフにし、同じページを再読み込みし、同じ指標を同じ時間見ます。拡張機能は独自タスクとして出ることも、サイト名のままのレンダラーを膨らませることもあります。指標が動かなければ、次を試す前にその拡張機能を戻します。全部まとめて無効にすると、症状は消えても原因は特定できません。

非アクティブタブのメモリにはメモリセーバー

Chromeのパフォーマンス設定は 設定 › パフォーマンス、および chrome://settings/performance にあります。メモリセーバーは使っていないタブを休止し、戻ったときに再読み込みします。対象は非アクティブタブのメモリであり、いま忙しいCPUタスクではありません。

Googleは休止を妨げる作業も列挙しています。再生中の音声や動画、通話、画面共有、通知、ダウンロード、途中のフォーム、ピン留めしたタブ、接続中のデバイスです。高いHelperが見ているタブ、または再生やアップロード中のタブなら、メモリセーバーが意図どおりアクティブのまま残すことがあります。

ハードウェアアクセラレーションは対照試験として扱う

Googleは利用可能な場合はハードウェアアクセラレーションを使用するを、グラフィック関連の不具合向けのトラブルシューティング用スイッチとして文書化しています。CPUが高いときの万能修正ではありません。GPUタスク、動画、canvas、スクロール、描画が症状のときだけ試します。

基準を記録し、設定を変え、Chromeを再起動し、同じ作業を繰り返します。アクセラレーションを切ると描画がGPUからCPUへ移り、CPUが上がったり動画が滑らかでなくなったりすることがあります。測った問題が改善しなければ元に戻します。

プロセス一覧を短くするためにHelperのバイナリ、プラグインフォルダ、Google Chrome.app 内部を削除しないでください。それらのHelperはChromeのアーキテクチャそのものです。アプリバンドルをいじると、作業しているページや拡張機能は直らず、Chromeとその更新が壊れることがあります。

比較を再現できるようにする

急増のスクリーンショット1枚では足りません。同じ観察を2回行い、変数は1つだけ変えます。

同じページを同じウインドウ、同じメディア位置に保ちます。動画は意図して一時停止または再生し、測定のあいだ勝手に進まないようにします。電源アダプタと低電力モードを含む電源状態も揃えます。関係のない重いアプリは閉じ、別のコンパイルや書き出しが基準を変えないようにします。

表から指標を1つ選びます。最後のページの読み込みが終わってから2分など、決めた時間見ます。Chromeのタスクマネージャーの行名と、そのCPUまたはメモリを記録します。対応するアクティビティモニタのプロセスは、パスを確認してから使います。

それから変数を1つ変えます。そのタスクの終了、拡張機能1つの無効化、メモリセーバーの有効化、またはハードウェアアクセラレーションの試験と再起動です。同じ観察時間を繰り返します。指標が改善しなければ、次の試験の前に戻します。何もしなかった設定も、変えたまま残すと次の基準を汚します。

変化が効いたら、Chromeを完全に再起動してもう一度繰り返します。レンダラーと一緒に消えて、同じサイトを開くとすぐ戻るコストもあります。それでも分かることはあります。責任があるのはそのタスク、拡張機能、作業負荷であり、Chrome Helperが存在すること自体ではありません。

調査後も Helper が複数残るのは正常です。負荷の原因になったタスクを特定し、対処後に使用量が下がったことを確認できれば十分です。未保存の作業を失わないよう、確認できたタスクだけを終了してください。