ベンチマーク: Playwright vs agent-browser

TL;DR

同じマシン・同じサイトで実測した結果、Playwright と agent-browser の実力は大きく変わらない。事前に期待していた「agent-browser は Playwright より 100 倍軽い・速い」は 実測では成立しない ことがわかった。

シナリオ	agent-browser	Playwright	差
単発（open + shot + close）	1.21 s	1.23 s	ほぼ同等
5 連続 shot を 1 フローで	1.86 s	1.30 s	Playwright 1.41x 速い
daemon 常駐中の 2 回目以降の shot	0.17 s	常駐不可	agent-browser の独壇場
メモリ（idle + 1 page）	290 MB	286 MB	ほぼ同等
プロセス数	5 (daemon + 4 chrome)	4 (node + 3 chrome)	ほぼ同等

理由はシンプルで、下回りのブラウザは両者とも同じ chrome-headless-shell を使っているから。マイクロベンチで見える差は IPC オーバーヘッドと Node.js ランタイム起動時間だけで、実用上は誤差レベル。

agent-browser の本当の強みは「速い/軽い」ではなく、daemon 常駐 + CLI インタフェース + LLM フレンドリーな要素参照 の 3 点にある。詳細は使い分けガイドを参照。

計測環境

項目	値
マシン	MacBook, Apple Silicon (arm64)
OS	macOS Darwin 25.2.0
agent-browser	0.25.3 + PR #1189 のローカルビルド
Playwright	1.59.1
共通ブラウザ	`chrome-headless-shell` 147.0.7727.56（agent-browser）/ 147.0.7727.15（Playwright）
対象 URL	`https://example.com`
計測ツール	hyperfine

すべて同一マシン、連続して計測。背景の Chrome プロセスは pkill + socket 削除で毎回クリーンアップ。

シナリオ 1: Cold start（単発 E2E キャプチャ）

想定ユースケース: dev-workflow /issue-test の Method 1 相当。1 枚スクリーンショットを取るだけのワンショット処理。

コマンド

bash

# agent-browser
agent-browser --session bench open https://example.com \
  && agent-browser --session bench screenshot out.png \
  && agent-browser --session bench close

# Playwright
npx playwright screenshot https://example.com out.png

結果（hyperfine, 3 runs）

Command	Mean [s]	Min [s]	Max [s]	Relative
`agent-browser (cold)`	1.207 ± 0.156	1.100	1.387	1.00
`playwright CLI (cold)`	1.229 ± 0.178	1.116	1.434	1.02 ± 0.20

結論: ほぼ同等。agent-browser がわずかに速いが誤差範囲。両者とも同じ chrome-headless-shell を起動しているので、この 1.2 秒のほぼ全部が Chrome 起動時間。

シナリオ 2: Warm start（daemon 常駐でのキャプチャ）

想定ユースケース: 長時間動作する AI エージェントが、同じセッションで何枚も screenshot を取るケース。

コマンド

bash

# agent-browser (daemon 起動済み、ブラウザオープン済み)
agent-browser --session warm screenshot out.png

# Playwright は同じ事ができない
# → 毎回 Node.js + Chromium を起動し直す必要がある

結果（hyperfine, 10 runs）

Command	Mean [ms]	Min [ms]	Max [ms]
`agent-browser (warm)`	178.5 ± 6.4	172.0	192.4
`playwright (equivalent)`	N/A	—	—

結論: agent-browser の独壇場。daemon が常駐しているので、Chrome の起動コスト（~1 秒）が帳消しになる。178 ms は Playwright の cold start（1229 ms）の 約 1/7。

この差が実際に効くのは、連続的に別々の screenshot コマンドを呼び出すワークフロー（AI エージェントが対話的にブラウザを操作する場合）。1 枚だけなら cold start 同士の比較になるので差は出ない。

シナリオ 3: 1 フロー内で 5 連続 screenshot

想定ユースケース: dev-workflow /issue-test の Method 2 相当。1 回の test 実行で、初期表示→ボタンクリック→モーダル表示→フォーム入力→確認→完了の 5 枚を撮る。

コマンド

bash

# agent-browser
agent-browser --session s open URL
for i in 1..5; agent-browser --session s screenshot out-$i.png
agent-browser --session s close

# Playwright（1 つの Node.js プロセスで完結）
node -e "const {chromium}=require('playwright');(async()=>{
  const b=await chromium.launch();
  const p=await b.newPage();
  await p.goto(URL);
  for(let i=1;i<=5;i++) await p.screenshot({path:'out-'+i+'.png'});
  await b.close();
})()"

結果（hyperfine, 3 runs）

Command	Mean [s]	Min [s]	Max [s]	Relative
`playwright (5 shots)`	1.299 ± 0.040	1.253	1.328	1.00
`agent-browser (5 shots)`	1.863 ± 0.022	1.837	1.879	1.43x slower

結論: Playwright が 1.41 倍速い。理由は IPC オーバーヘッド:

Playwright: 1 つの Node.js プロセス内で page.screenshot() を呼ぶ → メモリ共有、オーバーヘッドほぼ 0
agent-browser: 毎コマンドが「CLI → Unix domain socket → daemon → CDP → Chrome → CDP → daemon → socket → CLI」を往復 → 1 shot につき ~170 ms の IPC 追加

5 shot では 170 ms × 5 = 850 ms が加算され、Playwright との差になる。

含意: 「シェルから逐次呼び出す」パターンは agent-browser には不利。E2E シナリオを 1 本のシェルスクリプトに書くより、1 本の Node.js / Python スクリプトに書いたほうが結局速い。

シナリオ 4: 並列 3 セッション × 5 shot

想定ユースケース: 複数の issue を並列テストする multi-agent ワークフロー。

コマンド

bash

(
  agent-browser --session p1 open URL
  for i in 1..5; agent-browser --session p1 screenshot p1-$i.png
  agent-browser --session p1 close
) &
(
  agent-browser --session p2 open URL
  for i in 1..5; agent-browser --session p2 screenshot p2-$i.png
  agent-browser --session p2 close
) &
(
  agent-browser --session p3 open URL
  for i in 1..5; agent-browser --session p3 screenshot p3-$i.png
  agent-browser --session p3 close
) &
wait

結果

Command	Wall time
agent-browser parallel × 3	1.86 s

結論: 並列 3 セッションでも、シリアルの 1 セッションと同じ 1.86 秒で完了。daemon が 3 セッションをさばいているので、実質的にスループットが 3 倍になっている。これは --session でセッション分離した agent-browser の強み。Playwright でも Promise.all で並列化すれば同等だが、複数プロセスではなく 1 プロセス内の非同期並列になるため、クラッシュ耐性がやや落ちる。

シナリオ 5: メモリ使用量

計測方法

open 後、1 ページ読み込み完了状態で ps -o rss を合計。

結果

Component	agent-browser	Playwright
CLI / runtime	10 MB (daemon)	~80 MB (node) ※計測外
chrome-headless-shell (browser)	89 MB	87 MB
chrome-headless-shell (gpu)	67 MB	72 MB
chrome-headless-shell (network)	46 MB	45 MB
chrome-headless-shell (renderer)	85 MB	88 MB
合計（browser only）	287 MB	292 MB
プロセス数	5 (daemon + 4 browser)	4 (browser) + 1 node

結論: ほぼ同等。両者とも同じ chrome-headless-shell を起動しているので当然。agent-browser の daemon は 10 MB と極小だが、Chrome プロセスが 280 MB 使うので全体で見ると差は小さい。

重要: 上流 README に書かれている「agent-browser 8 MB vs Playwright 143 MB」は、おそらく agent-browser daemon のみ vs Playwright + Chromium 全体 というフェアでない比較。同じブラウザを動かしているなら、メモリ使用量は本質的に Chromium で決まる。

使い分けガイド

agent-browser を選ぶべきケース

長時間動作する AI エージェントがブラウザを操作する
- daemon 常駐で 2 回目以降の操作が圧倒的に速い（178 ms）
- AI エージェントが考えている間もブラウザ状態が維持される
shell スクリプトや CLI パイプラインからブラウザを操作したい
- Node.js を書かずに済む
- agent-browser click @e1 のような 1 行コマンドで操作可能
アクセシビリティツリーベースの要素参照（@e1, @e2）を使いたい
- LLM がスナップショットから直接参照 ID を読んで操作できる
- CSS セレクタよりも DOM 変更に強い
Node.js を入れたくない環境（CI、Docker、Lambda など）
- 単体 Rust バイナリで動作
複数セッションを完全に分離して並列実行したい
- --session でブラウザインスタンス単位で分離
- 1 セッションがクラッシュしても他に影響しない

Playwright を選ぶべきケース

既存の Node.js / TypeScript プロジェクトでテストを書く
- @playwright/test と統合されたテストランナーが使える
1 フロー内で多くのブラウザ操作を逐次実行する
- IPC オーバーヘッドがないので agent-browser より速い
成熟した API と豊富な機能を必要とする
- auto-waiting、trace viewer、codegen、video recording、network stub 等
複雑なインタラクション（ドラッグ、マルチタッチ、iframe 越しの操作）
- agent-browser は基本操作しかカバーしていない
既存の Playwright エコシステム（fixture、plugin）を活用したい

dev-workflow `/issue-test` での推奨

ケース	推奨	理由
静的ページのワンショット (Method 1)	どちらでも	性能差ほぼ無し
対話操作 E2E (Method 2)	Playwright	1 フロー内の連続操作は Playwright の方が速い
認証後の画面キャプチャ (Method 3)	agent-browser	`credentials set` でセッション再利用が楽
AI エージェントが試行錯誤しながら操作	agent-browser	daemon 常駐で warm start 178 ms が効く
CI で一発テスト（Node.js あり）	Playwright	既存エコシステム活用
CI で一発テスト（Node.js なし）	agent-browser	単体バイナリで完結

よくある誤解の訂正

❌ 「agent-browser は Playwright の 100 倍軽い」

実際: ブラウザ (chrome-headless-shell) は同じなので、メモリ使用量はほぼ同等（290 MB vs 286 MB）。

「100 倍」という数字は、agent-browser の CLI バイナリ（~7 MB）と Playwright の npm パッケージ（node_modules 含む ~710 MB）を比較した値。ただしどちらも実行時は同じ Chromium (~160 MB) をダウンロード・展開するので、ディスク使用量の実態は agent-browser 170 MB vs playwright 870 MB くらい。CLI 本体だけなら 100 倍差は正しいが、実行時メモリは同等。

❌ 「agent-browser は Playwright より速い」

実際: cold start はほぼ同等。1 フロー内の連続操作では Playwright の方が速い。

agent-browser が速いのは「daemon 常駐中の 2 回目以降の単発コマンド」という特定シナリオだけ。ワンショット E2E なら差はない。

✅ 「agent-browser は AI エージェントに適している」

これは正しい。理由:

daemon 常駐で warm start が高速 → AI が「考える」時間中も状態が維持される
CLI コマンドなので bash から直接呼べる → AI エージェントが Node.js スクリプトを書かなくて済む
アクセシビリティツリーベースの @eN 参照 → スナップショット出力から直接コピペで操作可能

✅ 「agent-browser は Node.js 非依存」

これは正しい。Rust 製単体バイナリなので、Node.js が入っていない環境でも動作する。ただし、npm install -g agent-browser 経由のインストールは Node.js 必要。Homebrew/Cargo 経由なら完全に非依存。

生データ

シナリオ 1: Cold start

Benchmark 1: agent-browser (cold)
  Time (mean ± σ):      1.207 s ±  0.156 s    [User: 0.008 s, System: 0.008 s]
  Range (min … max):    1.100 s …  1.387 s    3 runs

Benchmark 2: playwright CLI (cold)
  Time (mean ± σ):      1.229 s ±  0.178 s    [User: 0.496 s, System: 0.203 s]
  Range (min … max):    1.116 s …  1.434 s    3 runs

Summary
  agent-browser (cold) ran
    1.02 ± 0.20 times faster than playwright CLI (cold)

シナリオ 2: Warm start

Benchmark 1: agent-browser warm (screenshot only)
  Time (mean ± σ):     178.5 ms ±   6.4 ms    [User: 2.7 ms, System: 2.2 ms]
  Range (min … max):   172.0 ms … 192.4 ms    10 runs

シナリオ 3: 5 連続 shot

Benchmark 1: agent-browser (5 shots)
  Time (mean ± σ):      1.863 s ±  0.022 s    [User: 0.022 s, System: 0.020 s]
  Range (min … max):    1.837 s …  1.879 s    3 runs

Benchmark 2: playwright (5 shots)
  Time (mean ± σ):      1.299 s ±  0.040 s    [User: 0.327 s, System: 0.112 s]
  Range (min … max):    1.253 s …  1.328 s    3 runs

Summary
  playwright (5 shots) ran
    1.43 ± 0.03 times faster than agent-browser (5 shots)

シナリオ 4: 並列 3 セッション

real    0m1.859s
user    0m0.010s
sys     0m0.014s

シナリオ 5: メモリ

=== agent-browser memory ===
  processes: 5
  total RSS: 290 MB

=== Playwright memory ===
  processes: 4
  total RSS: 286 MB

計測に使用したスクリプト

計測は scripts/benchmark.sh（Issue #9 で追加）で再現可能。

bash

bash scripts/benchmark.sh

ベンチマーク: Playwright vs agent-browser ​

TL;DR ​

計測環境 ​

シナリオ 1: Cold start（単発 E2E キャプチャ） ​

コマンド ​

結果（hyperfine, 3 runs） ​

シナリオ 2: Warm start（daemon 常駐でのキャプチャ） ​

コマンド ​

結果（hyperfine, 10 runs） ​

シナリオ 3: 1 フロー内で 5 連続 screenshot ​

コマンド ​

結果（hyperfine, 3 runs） ​

シナリオ 4: 並列 3 セッション × 5 shot ​

コマンド ​

結果 ​

シナリオ 5: メモリ使用量 ​

計測方法 ​

結果 ​

使い分けガイド ​

agent-browser を選ぶべきケース ​

Playwright を選ぶべきケース ​

dev-workflow /issue-test での推奨 ​

よくある誤解の訂正 ​

❌ 「agent-browser は Playwright の 100 倍軽い」 ​

❌ 「agent-browser は Playwright より速い」 ​

✅ 「agent-browser は AI エージェントに適している」 ​

✅ 「agent-browser は Node.js 非依存」 ​

生データ ​

シナリオ 1: Cold start ​

シナリオ 2: Warm start ​

シナリオ 3: 5 連続 shot ​

シナリオ 4: 並列 3 セッション ​

シナリオ 5: メモリ ​

計測に使用したスクリプト ​

ベンチマーク: Playwright vs agent-browser

TL;DR

計測環境

シナリオ 1: Cold start（単発 E2E キャプチャ）

コマンド

結果（hyperfine, 3 runs）

シナリオ 2: Warm start（daemon 常駐でのキャプチャ）

コマンド

結果（hyperfine, 10 runs）

シナリオ 3: 1 フロー内で 5 連続 screenshot

コマンド

結果（hyperfine, 3 runs）

シナリオ 4: 並列 3 セッション × 5 shot

コマンド

結果

シナリオ 5: メモリ使用量

計測方法

結果

使い分けガイド

agent-browser を選ぶべきケース

Playwright を選ぶべきケース

dev-workflow `/issue-test` での推奨

よくある誤解の訂正

❌ 「agent-browser は Playwright の 100 倍軽い」

❌ 「agent-browser は Playwright より速い」

✅ 「agent-browser は AI エージェントに適している」

✅ 「agent-browser は Node.js 非依存」

生データ

シナリオ 1: Cold start

シナリオ 2: Warm start

シナリオ 3: 5 連続 shot

シナリオ 4: 並列 3 セッション

シナリオ 5: メモリ

計測に使用したスクリプト