要約— Electronには確かなメモリコストがあります。ただし、録画や書き出しの性能を大きく損なうとは限りません。
M4 Mac miniで、ネイティブのScreenCaptureKitレコーダーと、同じレコーダーをElectronから動かした場合を比較したところ、4K動画の出力はそれぞれ57.70 fpsと57.53 fpsでした。4K編集用シェーダーのP95フレーム時間は、Metalを直接使う場合が1.62 ms、ElectronのWebGLからMetalへ変換する経路が1.90 msでした。条件を揃えた1080p H.264の書き出し速度は、ネイティブのVideoToolbox経由が実時間の7.54倍、ElectronのWebCodecs経由が7.46倍でした。
差がゼロだったわけではありません。ただし、その差は従来語られてきた場所には現れませんでした。
Electronの明確な弱点はメモリです。Chromiumレンダラーを加える前の段階で、ネイティブ録画ホストは45 MB、署名済みのElectron/Nodeホストは94 MBでした。このテストで製品版Tight Studioは約744〜749 MBに落ち着きました。これは率直に示すべきトレードオフです。ただし、映像フレームがウェブページを経由することや、書き出しがソフトウェアエンコードになることを示す証拠ではありません。
Tight StudioはElectronで開発しているため、私たちはこの問いの当事者です。だからこそ条件を揃え、再現できるベンチマークにしました。この記事では、Electronに有利な結果だけでなく、不利な結果も掲載しています。
「ネイティブ対Electron」だけでは比較の粒度が粗すぎる
デスクトップアプリは、単一の実行エンジンではありません。
ElectronはChromiumレンダラー、Node.jsのメインプロセス、マルチプロセスのアプリケーションシェルを提供し、ネイティブモジュールにも対応しています。Electronの公式ドキュメントにも、プラットフォームAPIや性能が重要な処理にネイティブコードを利用できることが明記されています。
つまり、Electronの画面収録アプリには、少なくとも大きく異なる2つの設計があります：
- JavaScriptとブラウザのレイヤーで、フレームの取り込み、合成、コピー、エンコードまで行う設計。
- 製品のUIとオーケストレーションにはElectronを使用し、ScreenCaptureKit、AVFoundation、Metal、VideoToolbox、または他のネイティブメディアエンジンがホットパスを担当します。
どちらもElectron製ですが、性能を左右するアーキテクチャは同じではありません。
Electronは高負荷なデスクトップアプリでも活用されている
この構成は珍しいものではありません。現在配布されているCodexとClaudeのmacOS版もElectronを採用しています。この記事の検証環境では、Codex 26.825.41651のElectronAsarIntegrityがapp.asarパッケージに設定されていました。一方、Claude 1.26832.0には次の2つが含まれていました：Electron Framework.frameworkとapp.asar。
Electronの公式ドキュメントでも、Visual Studio Code、Figma、Docker Desktop、Loom、Canva、Notion、1Password、Slack、Discord、Signalが、このフレームワークで開発された製品として紹介されています。用途は、コードの編集・デバッグ、共同でのグラフィック制作、コンテナ管理、画面収録、認証情報の管理、メッセージング、音声・動画、AIワークフローまで多岐にわたります。
この一覧は性能ベンチマークではなく、すべてのElectronアプリが効率的だと証明するものでもありません。ここからわかるのは、デスクトップアプリの外側にElectronを採用しても、負荷の高い処理まですべてElectron側で担う必要はないという設計上のポイントです。専門的な処理は、ネイティブモジュール、GPUプロセス、ローカルサービス、リモートシステムに任せられます。
特別なツールがなくても、macOSアプリのバンドル構成を確認できます。Finderで「パッケージの内容を表示」を選択し、次の項目を確認します：Contents/Info.plist、Contents/Resources/app.asar、およびContents/Frameworks/。
Tight Studioは2番目のモデルを使用しています。macOSでは、画面フレームはScreenCaptureKitを使用するSwiftモジュールによってキャプチャされ、AVAssetWriterで書き込まれます。録画はDOM、React、またはChromiumのキャンバスを経由しません。編集や書き出しの際には、GPU合成とハードウェアコーデックのAPIが重い作業を行い、JavaScriptがパイプラインを調整します。
Appleは、ScreenCaptureKitを映像フレームと音声を取り込むための高性能APIと説明しています。Electronからの呼び出しが制限されるわけではありません。ネイティブモジュールから同じフレームワークを呼び出し、同じCMSampleBufferオブジェクトを受け取り、同じシステムエンコーダへ渡せます。
ベンチマークの内容
完成済みの2製品をそのまま比べる方法は避けました。一方が字幕、カーソルの動き、カメラの切り抜き、5つのオーバーレイを描画し、もう一方が元の録画を再多重化するだけなら、速度差からSwiftとElectronの違いを判断することはほぼできません。
そこで、処理内容を揃えて比較しました：
- テスト環境：Apple M4 Mac mini、10コアCPU、10コアGPU、16GBメモリ、macOS 26.5.2。
- 記録中：同じ製品版ネイティブキャプチャエンジンを、Swift CLIから直接起動した場合と、署名済みのTight Studio Electron/Node実行ファイルから起動した場合で比較しました。どちらも、同じアニメーションを表示する3840×2160の画面を60 fpsの目標で録画しています。
- 編集：3840×2160で、同じプロシージャル背景、角丸カード、グリッド、影、アニメーションするカーソルのシェーダーを描画しました。ネイティブはMetal、ElectronはANGLEのMetalレンダラーを介したWebGL 2を使用しています。非表示のキャンバスによって処理が省略されないよう、各フレームに同期ポイントを設けました。
- 書き出し：1920×1080、30 fps、H.264、目標12 Mbpsで300フレームを書き出しました。ネイティブはMetalとVideoToolbox、ElectronはWebGLと、ハードウェアアクセラレーションを要求したWebCodecsを使用しています。
- 実行：各経路を3回ずつ実行し、表には中央値を示しています。
バッテリーに関する結果は含めていません。今回はMac miniを使用しており、信頼できるバッテリー評価には、条件を揃えた長時間のMacBookテストが必要です。
結果
| フェーズ | 直接ネイティブ | Electron/ハイブリッド | Electronとの差 |
|---|---|---|---|
| 4K録画出力レート | 57.70 fps | 57.53 fps | -0.29% |
| 録画ホストのCPU使用率 | 7.06% | 6.98% | -0.09ポイント |
| os-serviceのCPUを記録 | 31.34% | 32.76% | +1.42ポイント |
| 録画ホストのピークメモリ | 45.36 MB | 94.39 MB | +49.03 MB |
| 4K編集シェーダースループット | 684.23 fps | 593.77 fps | -13.22% |
| 4K編集シェーダーp95フレーム時間 | 1.62ミリ秒 | 1.90ミリ秒 | +0.28ミリ秒 |
| 1080pの書き出しスループット | 226.10 fps | 223.78 fps | -1.02% |
| 1080pの書き出し速度 | 実時間の7.54倍 | 実時間の7.46倍 | -1.02% |
これは1台のマシンで行った短時間の比較テストです。各アーキテクチャで実現できる性能の一例を示すものであり、すべてのElectronアプリが同じ効率になることを保証するものではありません。
録画：Electronが映像フレームに触れる必要はない
録画結果はほぼ同点です。重要な部分では両方の方法が同じだからです。
ScreenCaptureKitがフレームを生成します。AVAssetWriterとシステムのコーデックスタックがそれらをエンコードします。Electron側は、ネイティブレコーダーに開始、停止、一時停止、再開を指示します。IPCチャネルを介して4Kピクセルバッファを受信したり、JavaScriptでそれらをエンコードしたりすることはありません。
3回の中央値は、ネイティブが57.70 fps、Electronホストが57.53 fpsで、差は0.29%でした。録画ホストのCPU使用率はネイティブが7.06%、Electronが6.98%。macOSのキャプチャサービスは、それぞれ平均31.34%と32.76%でした。
重要なのはフレームレートの結果です。CPU使用率がわずかに逆転したのは通常の実行ごとのばらつきであり、ElectronがScreenCaptureKitを高速化する証拠ではありません。
テスト条件について、明記すべき注意点があります。macOSの画面収録権限は、署名されたアプリケーションのIDに付与されます。開発用のElectronバイナリには権限がなかったため、Electron側の録画テストでは、署名済みのTight Studio実行ファイルをElectronのNode互換モードで動かしました。これによりネイティブブリッジは分離できますが、Chromiumレンダラーは含まれません。そこで、94 MBのホストを完全なElectronアプリとして扱うのではなく、製品版シェルのメモリを別途測定しました。
編集：変換レイヤーを介してもMetalはMetal
JavaScriptからAppleのMetal APIを直接呼び出すことはできません。この事実を拡大解釈し、ElectronではMetalベースのGPUレンダリングを使えないと語られることがあります。
macOSでは、ANGLEがOpenGL ES向けのMetalバックエンドを提供しており、ChromiumはWebGLの内部でこれを利用できます。今回のElectronベンチマークで確認されたレンダラーはANGLE Metal Renderer: Apple M4。
Metalを直接使うネイティブ実装の方が高速でした。中央値では、ネイティブが毎秒684フレーム、Electronが毎秒594フレームを描画し、スループットには13%の差がありました。P95のフレーム時間は1.62 msから1.90 msへ増加しました。
これは測定可能なオーバーヘッドです。ただし、60 fpsで使える16.67 msのフレーム時間に対して、増加は0.28 msでした。
実際の編集ソフトは、もちろん1つのシェーダーだけを動かすわけではありません。動画のデコード、テクスチャのアップロードや読み込み、テキスト描画、アニメーション状態の計算、入力への応答も行います。実装が不適切なら、コピー、メモリ確保、同期IPC、Reactの処理で残りのフレーム予算を使い切る可能性があります。ただし、ブラウザのコンポジターが必ずソフトウェアレンダラーになるわけではなく、MacでWebGLを使っていることはGPUを迂回している証拠にもなりません。
WebGLやWebGPUだけでは足りない場合も、ElectronからネイティブのMetalモジュールを利用できます。サブシステムごとに適切な実装経路を選べます。
書き出し：ハードウェアエンコーダは、起動元のUIを区別しない
VideoToolboxは、Appleのハードウェアエンコーダとデコーダを利用するための低レベルインターフェースです。ChromiumにはmacOS向けのVideoToolboxエンコーダバックエンドがあり、WebCodecsではアプリからハードウェアアクセラレーションを優先するよう指定できます。
ネイティブ側では、VideoToolboxがハードウェアエンコードの使用を確認できました。Electron側はWebCodecsからハードウェア使用を要求しています。WebCodecsは実際に選ばれたエンコーダ名を公開しないため、Electron側についてAPIレベルの確証はありません。ただし、性能と出力はハードウェア経路と整合しています。300フレームのエンコード時間の中央値は、ネイティブが1.327秒、Electronが1.341秒で、出力サイズの差は1%未満でした。
実時間に対して7.54倍と7.46倍の速度で、差は1%です。
もちろん、すべてのElectron製書き出し機能が高速という意味ではありません。次のような実装では遅くなります：
- 毎フレーム、GPUからピクセルを読み戻す
- JavaScriptやIPC経由でフルフレームをコピーする
- ソフトウェアでエンコードする
- デコード、描画、音声、エンコードの各段階を不要に直列化する
- ストリーミングせず、出力全体をメモリに保持する
- UIスレッドをレンダリング処理に使う
これらはパイプラインの設計判断であり、Electronに強制される要件ではありません。
実際のTight Studioでの書き出し
マイクロベンチマークは、どこでオーバーヘッドが生じるかを示します。製品全体のテストは、完成したパイプラインが実用的かを示します。
既存の5クリップ書き出し回帰テストも、Tight Studioで3回実行しました。112秒のタイムラインを1440×1080で処理し、クリップごとのデコード、GPU描画、音声、エンコード、連結、マルチプレックスまでを含めています。所要時間は81.54秒、80.94秒、81.28秒で、中央値は81.28秒でした。これは実時間の1.38倍の速度です。
生成ファイルは112.36秒、約30 fpsで、H.264映像とAAC音声を含みます。このテスト素材だけで普遍的な書き出し速度を示すことはできません。元の素材やエフェクトによって結果は変わります。それでも、再現可能なリポジトリテストにおいて、Electron製品が一連の処理を通して再生時間より速く書き出せることは確認できます。
Electronが明確に不利な点：メモリ
Electronはマルチプロセスのブラウザランタイムを内包するため、その分のメモリが必要です。
ネイティブ録画ホストのRSSピークは45 MB、署名済みのElectron/Nodeホストは94 MBでした。最小構成のElectron編集プロセスツリーは約360 MB、書き出し時は約394 MBです。新しいプロファイルで起動した製品版Tight Studioは、このテスト時の状態で約744〜749 MBに落ち着きました。
最後の数値はElectron固有の決まりでも、ネイティブアプリとの比較結果でもありません。最小構成のテスト用シェルを、実製品の性能を装う材料にしてはいけないという注意点です。
余裕のないマシンでは、メモリ使用量も重要です。メモリ不足は負荷やスワップを増やし、間接的に消費電力へ影響します。ただし、割り当て済みRAMは、録画時のCPU使用率、コマ落ち、GPUのフレーム時間、エンコーダのスループットとは別の指標です。1つの数値でほかのすべてを代用すると、誤った技術的結論につながります。
現実的な目標は「Chromiumのメモリ使用量をゼロにする」ことではありません。ブラウザランタイムを生のフレームが通るホットパスから外し、メディアオブジェクトを速やかに閉じ、バッファに上限を設け、出力をストリーミングし、待機中の処理をむやみに動かさないことです。
画面収録アプリを正しく評価するには
各サブシステムの実際の処理を確認してください：
- 画面の取り込みには、どのAPIを使っているか？
- フレームはどこで合成されるか？
- GPUバックエンドはハードウェアアクセラレーションされているか？
- どのエンコーダ実装が選ばれるか？
- フルフレームのコピーは何回発生するか？
- ピクセルデータはIPCやJavaScriptの境界を越えるか？
- 対象解像度で60 fpsを維持できるか？
- 出力1秒あたりの書き出し時間はどれくらいか？
- 同じ処理条件で、CPU、メモリ、コマ落ち、消費電力、温度はどう変わるか？
「ネイティブ」と「Electron」は実装方式を示す情報ですが、それだけでは有効なベンチマーク結果になりません。
結論
完全なネイティブアプリは、シェルのオーバーヘッドを最小限に抑え、プラットフォームAPIへ最も直接アクセスできます。同じ機能を持ち、同程度に最適化されたパイプラインを2チームが構築したなら、特にメモリ使用量やGPUを細部まで制御する点では、ネイティブ側に優位性が残ります。
Electronアプリでも、DOMノードやJavaScriptのループだけでメディアエンジンを作る必要はありません。ScreenCaptureKitで取り込み、MetalベースのGPU APIで合成し、ハードウェアのメディアエンジンでエンコードできます。性能が重要な処理は、ネイティブモジュールやワーカーへ移せます。
測定の結果、録画フレームレートの差は0.29%、合成4Kシェーダーのスループット差は13%、条件を揃えた書き出しの差は1%でした。一方、メモリ使用量には大きな差がありました。これが、トレードオフの実像です。
フレームワークが初期条件を決め、パイプライン設計が性能を決めます。
出典と再現方法
- Apple：ScreenCaptureKit
- Apple：VideoToolbox
- Electron：ネイティブコードとElectron
- Electron：プロセスモデル
- Electron：採用理由と実際のアプリ例
- ANGLE：Metalバックエンドサポート
- Chromium：macOS VideoToolboxエンコーダ
- W3C：WebCodecsのハードウェアアクセラレーション
ベンチマーク用コード、実行結果の生データ、権限に関する注意点、解釈上の制約は、単独で公開できる形に整備中です。クローンして独立実行できるようになり次第、ここにリポジトリへのリンクを追加します。ほかのAppleシリコン搭載Macや、条件を揃えたMacBookの消費電力テストも有用ですが、上記の結論には含めていません。