ブログに戻る
·9分で読める·productdevbook

macOSでChromeのタブ別通信量を見る方法

macOSでChromeのタブ別通信量を分解する方法。ヘルパープロセス問題への各ツールの対応と、見落としがちなポイントを解説します。

  • App-specific
  • macOS
  • Bandwidth
  • Browser

Chromeタブを40個開いていて、ファンが回り、明らかな犯人なしに1時間で600MB食らっています。アクティビティモニタは「Google Chrome Helper (Renderer)」と呼ばれる行を38回表示。どれもどのタブがどれか教えません。macOSでChromeのタブ別通信量を見るには、Chromeがどうタブをプロセスにマップするか、Chrome自身のツール経由でデータをどう読むか、加えてヘルパー行に溺れないアプリ別モニターを知る必要があります。

これがプロセスモデルから実行可能なステップまでの実用的なセットアップです。

macOSでのChromeのプロセスモデル

Chromeは設計上マルチプロセス。各タブは——通常——独自のレンダラープロセスで動きます。また:

  • ブラウザプロセス — メインChromeプロセス、UI、調整。
  • GPUプロセスGoogle Chrome Helper (GPU)、合成。
  • レンダラープロセスGoogle Chrome Helper (Renderer)、サイトフレームグループごとに1つ、Chromeのプロセス上限で抑えられる。
  • プラグイン / ユーティリティプロセス — ネットワークサービス、ストレージ、オーディオなどのため。
  • 拡張プロセス — ほとんどの拡張は独自のレンダラークラスのプロセスを得る。

だから典型的なChromeセッションには1ブラウザ+1 GPU+10〜40レンダラー+少数のユーティリティプロセス。macOSでは、すべてがほぼ同一の名前の別行としてアクティビティモニタに現れます。

これが「MacでのChromeのタブ別通信量」が「Chromeの合計通信量」より難しい問いである理由。OSはPIDを見ます。あなたはタブを欲しい。

MacでのChromeのタブ別通信量はプロセスにどうマップするか

Chromeはサイト分離モデルを使います。同じサイト(同じeTLD+1、例: *.youtube.com)からの2タブはしばしばプロセスを共有。異なるサイトからのタブは異なるプロセスを得る。クロスサイトiframeも独自のプロセスを起動できます。

実用的含意:

  • youtube.comの5タブは1〜2レンダラーに座るかもしれません。
  • youtube.comgithub.comtwitter.comnews.ycombinator.comnytimes.comにまたがる5タブは5つの異なるレンダラーになります。
  • タブ内の広告iframeは独自のプロセスを持ちうる。そのiframeからの通信量は、ユーザ可視タブが「所有」しないように見えるプロセスに帰属。

ツール1: Chromeタスクマネージャ(Mac上のShift-Esc: メニューにあります)

Chromeには組み込みタスクマネージャがあります。macOSでは既定でShift-Escにバインドされていません——Chromeメニューバーでウィンドウ → タスクマネージャを開く。(またはChromeバージョン次第で表示 → 開発者 → タスクマネージャを使う。)

タスクマネージャはChromeプロセスごとに1行を表示します:

  • タスク名(しばしばタブタイトルまたは拡張名)
  • メモリフットプリント
  • CPU
  • ネットワーク(現在のレート)——可視でなければ列ヘッダを右クリックして「ネットワーク」を有効化。

これが「MacでのChromeのタブ別通信量」のネイティブに最も近いもの。ネットワークでソートすれば、現在最もデータを転送しているタブが見えます。

限界:

  • ライブレートを表示し、累積使用量ではない。タブが1時間前に200MBバースト読み込みしたなら、タスクマネージャはそれを表示しません——今流れているものだけ。
  • タブにまたがって共有されるサイトはタブごとではなく1度表示。
  • クロスサイトiframeは謎めいた名前で独自のタスクとしてリスト。

限界があってもタスクマネージャは正しい出発点。

ツール2: ヘルパーを折りたたむアプリ別モニター

Chromeタスクマネージャはこの瞬間のタブを表示します。縦断的ビュー——Chromeが過去1時間、1日、1週間で何をしたか——も欲しい、絵を散らかす40行のGoogle Chrome Helper (Renderer)なしで。

ovaはメニューバーに座り、約1Hzでアプリ別レートをサンプリングし、すべてのChromeヘルパーPIDを単一の「Google Chrome」行の下に折りたたみます。「今日どれだけ使ったか」に必要な合算レート、最近のタイムライン、合計が見えます。

2ツールは互いを補完します:

  • Chromeタスクマネージャ: どのタブが重いか。
  • 折りたたみメニューバーモニター: Chromeが合計でどれだけ使い、いつスパイクが起き、日々と比べてどう。
ヘルパープロセスの折りたたみ
ovaはすべての「Google Chrome Helper」PIDを親の下にロールするので、40の別個のヘルパー行ではなく「Chrome 12 MB/s」と読めます。

タブリークを見つける5分のワークフロー

Chromeが重く感じるとき、これがループ:

  1. メニューバーでovaを開く。 現在のChromeレートを記録。0〜50KB/sならリークなし——他を探しに。
  2. 能動的に閲覧していないのにChromeが1MB/sを超えて持続するなら、Chromeのタスクマネージャを開く。
  3. ネットワーク降順でソート。 トップ行が犯人。しばしば誤って一時停止された動画タブ、長いポーリングwebsocket、または暴走拡張。
  4. タスク名を記録。 拡張なら、必要か決める。タブなら、閉じるかしていることを一時停止。
  5. その後30秒ovaを観察。 Chromeのレートは下がるはず。下がらないなら、リークは別の場所。

ワークフローを覚えれば60秒の診断。

メニューバーに静かなChromeモニターを追加

ovaはヘルパーが結合された単一のChrome行とスクラブ可能なタイムラインを表示——ローカル、署名済み、約3MB。

macOS用ダウンロード

一般的なChrome通信量の意外

人々を油断させること:

YouTubeの事前読み込み

YouTubeは観察中に常に次の数秒の動画を事前読み込み。一時停止されたタブもping し続けます。バックグラウンドの自動再生(タブを切り替えるとき)もしばしば読み込み続ける。複数のYouTubeタブがあるなら、一時停止されたものでも通信量を食らえる。

サービスワーカー

モダンウェブアプリはタブがフォーカスされていないときもバックグラウンドで動くサービスワーカーをインストール。Gmail、Twitter、Slackウェブ、Notionすべてがこれをします。定期的に更新を取得。タブを閉じれば通常止まる。時にワーカーはブラウザ再起動まで残る。

長いポーリング接続

一部のウェブアプリは貧しい人のwebsocketとしてHTTP接続を開いたままにします。トラフィックは小さく見えるが一定。多くのタブにわたって積み重なる。

拡張

悪い拡張は永遠に1秒ごとにAPIをポーリングしうる。拡張を一度に1つずつ無効化しモニターを観察——うるさいものが自分を明かします。

同期

Chrome Syncはブックマーク、履歴、パスワード、開いたタブをGoogleアカウントにアップロード。通常小さい。大きなブックマークインポート後は測定可能になりうる。

データを読む: 通常のChromeレートとは?

いくつかのベースライン:

  • アイドル、5〜10タブ: 合算5〜30KB/s。
  • 動画なしの能動的閲覧: ページ読み込み中スパイク、間アイドル。
  • 1080p再生する1つのYouTubeタブ: 持続600KB/s〜1.5MB/s。
  • 2つのYouTubeタブ: おおむね倍。
  • フォルダのGoogle Drive同期: アップリンクを飽和できる。
  • 悪いポーリングのウェブアプリ: アイドルでも持続50〜200KB/s。

ovaのChrome行が何もしていないときに約100KB/sを超えて座っているなら、何か間違っています。タスクマネージャを開いて見つけましょう。

サイト分離とクロスサイトiframe

通信量を追跡するときの皺: 「いる」タブはバイトを動かすものではないかも。広告iframe、埋め込みYouTubeプレーヤー、Disqusコメントウィジェット——それぞれサイト分離下で独自のプロセスでありうる。

Chromeのタスクマネージャでは、それらはSubframe: https://example-cdn.comのような名前で表示されます。時に親タブより消費するサブフレームが見えます。それが発火しているトラッキングピクセルや分析SDKで、広告ブロッカーを検討するヒントです。

機能を無効化せずChromeの通信量を節約

針を動かすChrome設定をいくつか:

1. メモリセーバー(以前のタブ廃棄)

設定 → パフォーマンス → メモリセーバー。非アクティブなタブを廃棄。クリックして戻るとタブが再読み込み——通信量を使う——が、引き換えにバックグラウンドでタブはゼロ使用。ほとんどのワークロードでネット勝利。

2. ページの事前読み込み: オフ

設定 → パフォーマンス → ページの事前読み込み → 事前読み込みなし。既定でChromeは訪問すると予測するページを事前読み込み。オフにすると投機的ダウンロードを止めます。

3. ハードウェアアクセラレーション

直接通信量に影響しないが、動画再生中のCPUを減らし、ネットワークスタックがより働かなくて済むようにする。

4. サードパーティクッキーをブロック

設定 → プライバシーとセキュリティ → サードパーティクッキー → ブロック。一部のトラッカートラフィックを減らす。一部のサイトが壊れる——サイトごとに確認。

5. uBlock Originまたは同様

本物の広告/トラッカーブロッカーは、典型的な閲覧で単一最大の通信量節約。4MBで読み込まれたページが800KBに落ちる。使ったことがなければモニターでの効果は劇的。

アクティビティモニタがChromeタスクマネージャと一致しないとき

これをよく見ます:

  • アクティビティモニタがGoogle Chrome Helper (Renderer)を合計受信50MBで表示。
  • Chromeタスクマネージャが同じレンダラーを今「0 KB/s」で表示。

両方正しい。アクティビティモニタはプロセス起動以来の累積。タスクマネージャは現在のレート。タブ別累積を得るには、PIDをタイトルに一貫してマップしながら時間とともに集約するツールが必要——古いものが閉じると新しいタブにChromeがプロセスを再利用するため難しい。

実用的妥協: Chrome合計の累積にova、タブ別ライブレートにタスクマネージャを使い、正確なタブ別累積はChromeで本当に測定が難しいと受け入れる。

まとめ

ユーザーが見たいMacでのChromeタブ別通信量は2つの問いに分かれます: 今何が重いか(Chromeのタスクマネージャを使う)、Chromeが過去1時間で何を使ったか(ヘルパー折りたたみ付きアプリ別モニターを使う)。OSはプロセス別、Chromeはタスク別を与え、組み合わせが必要なものを教えてくれます。

ovaを開き、隣にChromeのタスクマネージャを開き、閲覧しながら両方を5分観察しましょう。コストになっていると気づかなかったタブまたは拡張を少なくとも1つ発見するでしょう——ほとんどの人がそうします。