Slackは実質的にブラウザです
なぜSlackはこんなにメモリを使うのか、その答えはフレームワークにあります。SlackはElectronというフレームワークで開発されています。ElectronはGoogleのChromeブラウザのエンジン（Chromium）をアプリケーションとしてパッケージ化します。つまりSlackを開くと、チャットアプリを起動しているのではなく、1つのWebサービスを表示するために専用に設定されたWebブラウザを起動しているのです。
Chromiumだけで100〜200 MBのRAMが必要です。その上にSlack自体のコードが乗っかるため、何もしていない状態でもSlackのメモリ使用量はすでに相当な量になります。これが「Slack 重い」と感じる最初の原因です。
ワークスペースの数がslackメモリ使用量を押し上げます
ChromeがタブをそれぞれのプロセスとしてSlackは複数のワークスペースを別々のプロセスとして処理します。3つのワークスペースに接続している場合、8つ以上のプロセスが同時に実行されることがあります。これがSlack重い問題の大きな原因のひとつです。確認方法は次のとおりです：
- Windows：タスクマネージャーを開き「Slack」エントリを展開する
- macOS：アクティビティモニターで「Slack」を検索する
- Linux：ターミナルで
ps aux | grep -i slackを実行する
それぞれのプロセスが独自のメモリを消費します。すぐに合計は大きくなります。
見えないバックグラウンドプロセス
メッセージを読んだり送ったりしていないときでも、Slackは複数のプロセスを常時稼働させています：
- リアルタイム同期：参加しているすべてのチャンネルでメッセージをポーリング
- スペルチェッカー：バックグラウンドで常時動作するフルスペルチェックエンジン
- 自動更新：新バージョンをサイレントでチェック・ダウンロード
- クラッシュレポーター：診断データの収集と送信
これが、Slackのメモリ使用量が1日を通じて増え続ける理由です。朝の起動時400 MBだったものが、夕方には1.5 GBになっていることも珍しくありません。Slack重いデータの積み重ねが、こうしたバックグラウンド処理から生まれています。
なぜSlackはこの設計を採用し、変えないのか
Electronには実質的な利点があります。1つのコードベースでWindows、macOS、Linuxに対応できます。Slackほどの規模の企業では、1チームで3つのOSをカバーできることは大きな運営上のメリットです。
アプリをネイティブで書き直すには数年間の開発が必要で、ユーザーから見える新機能は何も増えません。このメモリコストは意図的なトレードオフであり、slackメモリ使用量の問題はアーキテクチャが変わらない限り解消されません。
できること
いくつかの回避策があります（使っていないワークスペースの切断、ハードウェアアクセラレーションの無効化など）。詳しくはSlackのメモリ使用量を減らす方法をご覧ください。
より根本的な解決策は、Electronを使わないクライアントへの切り替えです。msgaはネイティブのSlackクライアントで、すでに使用しているSlackサーバーに接続しますが、ブラウザエンジンを内蔵しない本物のデスクトップアプリとして動作します。アイドル時のRAM使用量は約60 MBです。