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

MacでSlackの通信量が多い理由(と確認方法)

SlackはmacOSで最もネットワークを使うアプリの一つです。その理由と、自分のマシンでの実態を可視化する方法を解説します。

  • App-specific
  • macOS
  • Bandwidth
  • Productivity

メニューバーを一目見ると、入力さえしていないのにSlackが2MB/s引いています。アクティビティモニタは異なる合計の4つの「Slack Helper」エントリを表示し、どれもネットワークモニターで見るものに合計しません。Slackの通信量がしている仕事に対して不釣り合いに感じる理由を考えたことがあるなら、答えはそのアーキテクチャにあります——Electron、websocket、ヘルパープロセス、人々が気づくより重い既定のA/Vスタック。

これはSlackの叩き記事ではない。Slackは本当に有用で、ネットワークの使い方はほぼ理にかなっています。ただ、macOSではプロセス別の数字が混乱しうるし、知る価値のあるいくつかの設定があります。

なぜSlackの通信量が高いか(アーキテクチャ的回答)

MacのSlackはElectronアプリ。つまり内部にChromiumを同梱し、Chromeのように仕事を複数のプロセスに分割:

  • Slack — メインプロセス、UI、調整。
  • Slack Helper — ユーティリティレンダラーとバックグラウンド作業。
  • Slack Helper (GPU) — 合成のためのGPUプロセス。
  • Slack Helper (Renderer) — UI用の1つ以上のレンダラープロセス。
  • Slack Helper (Plugin) — プラグインホスト(現バージョンでまれ)。

各ヘルパーは独自のPIDを持ちます。各々が独自のネットワークソケットを持ちうる。「MacでSlackがどれだけ通信量を使っているか」を尋ねるとき、親とすべてのヘルパーにわたって合計するか——またはそれらを折りたたむツールを使う必要があります。

ヘルパープロセスの折りたたみ
ovaはすべてのSlack Helper PIDを単一の「Slack」行にロールします。7つの部分的な数字ではなく実合計が見えます。

回線上に実際何があるか

トラフィックのカテゴリを、どれだけ貢献するかおおむね順に:

1. websocket

SlackはSlackのサーバへ持続的なwebsocketを開いておきます。これがプレゼンス更新、新メッセージ、入力中インジケータ、リアクション、ファイルアップロード通知、チャンネル状態変更、pingを運ぶ。アイドル時、websocketは小さい——数KB/s——ですが、UIで「即座」と感じるべき各イベントがこの接続経由の1つ以上のフレームです。

多くの忙しいチャンネルがあるなら、websocket単独で営業時間中に50〜150KB/sに座りえます。

2. HTTP取得

UI読み込み、アバター画像、チャンネル履歴、検索結果、リンクプレビュー、絵文字。これらは短いバースト——今日初めてチャンネルを開くと数MB取得、2回目はキャッシュに当たる。

3. ファイル転送

30MB画像をチャンネルにドラッグするとアップリンクにきれいなスパイクが見えます。Slackがファイルストレージにアップロードし、それからwebsocketに pingしてチャンネルにファイルを伝える。あなたのクライアントは、他人が共有するファイルのプレビューをダウンロード。多くのデザインファイルを共有するチームはプレビューだけで1日数百MBを動かしうる。

4. オーディオとビデオ通話

これが大きいもの。Slackハドル(音声のみ)は方向ごとに数百Kbps。ビデオハドルは数Mbps。ビデオ上の画面共有は5+ Mbpsを押せる。デコードしている参加者のビデオ数で乗算。

5. バックグラウンド更新と分析

Slack自動更新がバックグラウンドで動き、定期的に新バージョンを引きます。加えてテレメトリ——機能使用、クラッシュレポート——は1日KB単位、ほぼ無視できる。

典型的な1日からの実数

約25チャンネル、日中3〜4がアクティブ、合計45分の2ハドルでSlackを動かす単一Macからの数字:

  • アイドル(アプリ開いている、相互作用なし): 定常で5〜30KB/s。多くの忙しいチャンネルがあると高い。
  • 忙しいチャンネルへの入力: プレゼンスと既読受信が流れる中で短いスパイク50〜100KB/s。
  • 冷たいチャンネルを開く: 履歴の深さとアバター数次第で1〜5MB。
  • 45分のハドル(1:1、ビデオオン): 合計約600〜900MB。
  • ハドルなし、中程度の活動の典型的な業務日: 100〜300MB。
  • 2回のビデオハドルのある日: 簡単に1〜2GB。

これらは目安。チームの絵文字習慣はあなたが思うより重要。

Macで実際に見る方法

3つのオプション、有用性の順:

アクティビティモニタ

アクティビティモニタ → ネットワークタブを開く。「送信したバイト」または「受信したバイト」でソート。親とヘルパーが別行として、プロセス起動以来の累積合計付きで見えます。健全性チェックには有用、「Slackは今何をしているか」にはより少なく有用。

nettop

ターミナルで:

nettop -P -m route

ライブ更新のプロセス別ビュー。同じ問題——Slackとそのヘルパーが別行として現れる。

ヘルパー折りたたみ付きメニューバーモニター

ovaはまさにこのパターンを中心に作られています。すべてのヘルパーにわたる合算レート付きの単一「Slack」行、最近の活動のスパークライン、スパイクが起きたときが見られるスクラブ可能なタイムライン。「Slack」をクリックすると、欲しければヘルパー別詳細にドリルダウンできます。

Slackが実際何を使うかを確認

ovaはSlack Helper PIDを親アプリの下に折りたたみ、ライブ+過去のアプリ別通信量を表示。ローカル、署名済み、約3MB。

macOS用ダウンロード

Slack通信量を減らす——実際に重要な設定

ほとんどの「Slackで通信量を節約」アドバイスはリサイクルされ間違っています。実際に動くもの:

1. 絵文字をアニメーション: オフ

Slack → 環境設定 → アニメーションと画像プレビュー → スクロール時に絵文字をアニメーション。オフ。通信量(アニメーションGIFは大きい)とCPU両方を減らす。

2. メディアをインライン表示: 必要に応じて

同じ環境設定パネル。「画像とファイルを表示」を手動に設定すると、クリックして展開——共有された各画像の自動ダウンロードを避けます。トレードオフはわずかにリッチでないUI。通信量制約付き接続には簡単な勝利。

3. 音声とビデオの既定

ハドル中、できること:

  • ビデオをオフ——そのセグメントのアップロードを約80%下げる。
  • 他参加者のビデオを隠す(ギャラリー → スピーカービュー)——デコード負荷を減らす。
  • Slackが公開しているならビデオ品質を下げる。

ホットスポット上の長いミーティングには、ビデオオフが正しい既定。

4. 必要ないとき Slackを終了

明白に聞こえる。Slackは最小化時にwebsocketを閉じるのに苦労する——ウィンドウを閉じてもmacOSではアプリは終了しません。Cmd-Qが終了。従量制接続でリアルタイムメッセージングが必要ないなら、終了しましょう。

5. 自動起動するワークスペースを制限

各ワークスペースは大体1セットのヘルパーと1つのwebsocketを動かします。3ワークスペースは3つすべてを意味する。能動的に使わないワークスペースを削除すると通信量シェアを取り除きます。

ツール間で数字が一致しない理由

頻繁な混乱: アクティビティモニタはSlackが今日240MB使ったと言い、メニューバーモニターは380MB、nettopがさらに別の数字を表示。理由:

  • 異なる測定窓。 アクティビティモニタはプロセス起動以来をカウント。メニューバーモニターは今日、今週、またはローリングをカウントするかも。
  • ヘルパー含有。 あるツールの親プロセス行がヘルパーを除外するなら、それらを折りたたむツールより少なく見えます。
  • サンプリング vs 合計カウンタ。 nettopはポーリング、アクティビティモニタはカーネルカウンタを読む、良いモニターも同じ。同じスコープで同じ窓にわたって測定すれば、数字は密に一致するはず。

修正は1つのツールを選び比較に一貫して使うこと。ovaのアプリ別行は1つの数字——すべてのSlackヘルパーにわたって合算、選んだ窓にわたって——で、リンゴ対リンゴの比較を簡単に。

ホットスポットや上限付き接続でのSlack

電話にテザリングするか、データ上限のある場所から働くなら、Slackは速く積み重なる。実用ルール:

  1. セルラーでビデオハドルなし。 音声のみハドルは耐えられる。ビデオはダメ。
  2. メディアの自動ダウンロード: オフ。 流し読みするチャンネルで誰かが200MBデザインファイルを共有することから救う。
  3. 古いチャンネルを開かない。 冷たい開きは履歴を取得する。スクロールが必要ないなら、しないこと。
  4. 集中セッション間にSlackを終了。 「プレゼンス」のために動かしたままではなく、メールやDMに依存し、ブロックの開始と終わりにSlackをチェック。
  5. ウェブクライアントを短く使う。 ブラウザ版、単一タブで、Electronアプリより軽くなりうる——ヘルパー少ない、自動更新バックグラウンド作業なし。

Slackを代替と比較

通信量的に、おおまかな順:

  • iMessage / Mail — プッシュベース、ほぼゼロアイドル。
  • Telegram、WhatsApp — 小さなアイドルフットプリント、控えめなメッセージトラフィック。
  • Discord — Electron、Slackと似たアーキテクチャ、似たアイドルプロファイル。
  • Microsoft Teams — アイドルでSlackより重い、通話で同等。
  • Slack — アイドルで中〜重い、通話で重い。
  • Zoom — アイドルで軽い、通話で重い(他所のメモ参照)。

これは切り替え推奨ではない——Slackの通信量プロファイルはすることに対して妥当。ただ、「ネットワーク」を責めていて実は1日4GBのメッセージングクライアントなら、それは知る価値がある。

まとめ

MacでのSlack通信量は、永続的なwebsocket、複数のヘルパープロセス、インラインメディアとビデオ通話を含む機能セットを持つElectronアプリだから高い。見るもののほとんどは正常。一部は構成可能。すべては、モニターが1つの「Slack」行の下にヘルパーを折りたたむときに推論しやすい。

ovaを1日動かし、Slackの合計への貢献を観察し、コストが得られる価値と一致するか決めましょう。ほとんどの人にSlackは価値あり。従量制接続の人には、いくつかの設定調整が多くを節約します。