Browserless レビュー：Chrome を必要な分だけ配分できるサービス

Browserless は、ヘッドレス Chrome をサービスとして自前運用できる形にまとめたものです。Docker コンテナは常駐し、HTTP または WebSocket 経由で処理を受け付け、各呼び出し元に埋め込まれるのではなく、共有の受付上限を適用します。ここで行った REST テストでは、サービスはアイドル時に Chrome プロセスを 0 のまま維持し、リクエスト処理中だけ Chrome プロセスを生成し、その後は再び 0 に戻りました。共有されているのは事前起動済みブラウザの実体ではなく、サービスの処理能力とキュー制御です。

v2.55.0 を、起動を段階分解した検証、3 つの設定での受付制御、既知の正解データに対する出力一致、30 セッションの連続耐久試験、そしてタイムアウト境界という形で、制御されたローカル fixture に対して実行しました。得られた有益な挙動は「速度向上」よりも「運用面」で、受付上限はクライアントが見えるレスポンスと一致し、問題になりやすい部分の多くはデプロイの仕方に起因するものでした。

最も重要だったのは遅延の数値ではありません。Browserless は Chrome の起動を速くするのではなく、Chrome の入口に入場制限をかけます。中に入れるセッション数を固定し、その後ろに待ち行列を置き、それでもあふれた分には HTTP 429 を返します。環境変数を 2 つ変えるだけで、この上限は 4 から 8、さらに 10 へ動きました。そして、コンテナ自身のカウント結果は、毎回クライアント側のステータスコードと一致していました。

Browserless は実際には何なのか

ここで多くの人がカテゴリを取り違えます。Browserless は、import して呼び出すライブラリではありません。ghcr.io/browserless/chromium という Docker イメージを、長寿命のサービスとして起動して使います。ブラウザ作業を仲介し、2 つの経路で外部に公開します。1 つは REST エンドポイント（/content、/scrape、/screenshot、/pdf、加えて /function と /unblock）、もう 1 つは Puppeteer や Playwright が connect() できる CDP/WebSocket の面です。

今回は REST 面をテストしました。WebSocket の経路も実在しており広く使われていますが、今回は計測していません。

検証対象は v2.55.0 で、確認日は 2026 年 7 月 27 日です。

スター数は変動します。あくまでその時点の値として見てください。

ライセンスの境界: SSPL-1.0 か商用ライセンス

このリポジトリでは Browserless が SSPL-1.0 または Browserless の商用ライセンス で提供されています。進む前に、必ず現行の リポジトリ LICENSE と Browserless の 公式オープンソース導入ガイド を確認してください。この記事では、商用製品、クローズドソースアプリ、CI システム、ホスト型サービス、社内展開について法的判断は行っていません。そのため、そうしたケースを特定のライセンスに割り当てていません。ソフトウェアライセンスの判断は、法務担当か、その責任者に任せてください。

Browserless はホスト型プランも販売しています。価格や利用単位の定義は変わりやすく、この self-hosted テストには含めていません。古い表を調達判断の証拠として扱うのではなく、必ず公式サイトで確認してください。

セッションモデルの内部動作

計測した REST 経路は、リクエストごとのブラウザ処理のように振る舞いましたが、この harness は Browserless の内部まで深く追っていないため、毎回新しいブラウザプロセスなのか、それともどこかでコンテキストを再利用しているのかは切り分けられていません。ただし、ひとつ明確に言えることはあります。アイドル時の Chrome プロセス数は 0、アクティブなリクエスト中は chrome 系プロセスが 11、順次実行後は再び 0 でした。この構成で、事前ウォーム済みブラウザプールの痕跡は見当たりませんでした。

長寿命の Node サービスは、処理できるブラウザジョブ数に上限を設け、さらに別の上限分をキューに入れ、それ以上は拒否します。以下で測ったアーキテクチャ上の契約は、この受付モデルとして理解してください。"pool" という言葉からプロセス再利用やコンテキスト再利用を推測してはいけません。このタイミング用 harness では証明できないからです。

受付制御のつまみは 2 つです。

• CONCURRENT — 同時に実行するセッション数
• QUEUED — スロット待ちできる追加リクエスト数

コンテナの /config エンドポイントは、デフォルトとして CONCURRENT=10、QUEUED=10、TIMEOUT=30000 を返しました。CONCURRENT + QUEUED を超えるものは即座に拒否されます。

認証は必須です。Browserless v2 では 常にトークンが必要 で、TOKEN を設定しないと起動時にランダムなトークンを生成して stdout に表示します。REST 呼び出しにはすべて ?token= を付けます。

監視用には /pressure（実行中、待機中、CPU、メモリ、最近拒否された件数）、/sessions、/config が用意されています。/metrics の JSON 出力もありますが、METRICS_JSON_PATH の設定が必要で、今回は使っていません。また、このイメージは PID 1 として dumb-init を使っています。これは、コンテナ化された Chrome に長年つきまとってきた zombie プロセス問題への、ドキュメント上の答えです。

セットアップの現実: コマンド 1 行、でも 1 行では書かれない 4 つのこと

誰もが引用するインストール例は、実際にはたしかに docker run 1 行です。ただし、その周辺で考えるべきことがあります。

イメージサイズは 4.34 GB です。 起動遅延よりも、こちらの数字を基準に考えるべきです。manifest には linux/arm64 と linux/amd64 の両方が含まれており、私の arm64 ホストでは Docker がネイティブの arm64 版を取得しました。（コンテナ内の Chrome の user-agent はそれでも X11; Linux x86_64 と表示されますが、これは Linux 上での Chrome の見た目上の UA であって、エミュレーションではありません。uname -m は aarch64 を返します。これを理由にバグ報告する人がいます。）

計測では毎回 --shm-size=2g を使いました。 この harness は Docker のデフォルト /dev/shm での対照実験を含んでいないため、2 GiB が普遍的に必須だとも、失敗点を定量化したとも言えません。ブラウザの数とワークロードに合わせてサイズを決めてください。

トークンは形式上のものではなく、デプロイ上の要件です。 これがなければ、ポート 3000 に到達できる誰でも、あなたのネットワーク上のブラウザを自由に使えてしまいます。

コンテナのネットワーク設定はあなたの責任です。 私の fixture はホスト上で動かしていたため、コンテナからは host.docker.internal でアクセスしました（colima では --add-host host.docker.internal:host-gateway でマップされます）。計測を信じる前に、まず raw の curl でコンテナから fixture に到達できることを確認しました。

環境は、macOS 26.5.2 arm64 上の colima 0.10.3（6 CPU / 11.6 GiB）と Docker 29.2.1 です。harness は Python 3 の標準ライブラリのみで書きました。PNG と PDF については、デコーダの妥当性、寸法、ページ数、完全性、見た目の忠実さではなく、ファイルシグネチャを確認しました。

最小構成の起動例は、固定したイメージ、明示的なトークン、そして今回使った共有メモリ割り当てを用います。

docker run --rm -p 3000:3000 --shm-size=2g \
  -e TOKEN=replace-with-a-secret \
  ghcr.io/browserless/chromium:v2.55.0

/pressure?token=... が返るようになったら、ターゲット URL を JSON ボディに入れた認証済みの POST /content?token=... で REST 経路を試せます。本番利用では、429 に対してジッター付きの上限付きリトライも必要です。即時リトライは、同じ満杯のキューにもう一度突っ込むだけだからです。

起動コストを分解する

新規の docker run 起動を 3 回行った結果、中央値と最小–最大は次のとおりでした。

真ん中の行は読みすぎに注意が必要です。ブラウザ起動だけを切り出して測ったものではなく、Browserless が in-process ライブラリより Chrome を速く立ち上げることを示すものでもありません。 これは、コンテナへの HTTP 往復に加え、ブラウザ作業、ナビゲーション、レスポンス転送を含んだ値です。最初の呼び出しと後続呼び出しの約 0.17 秒差には、ファイルシステム、OS、Chrome、Node、コンテナのキャッシュ効果が含まれている可能性があります。アイドル時の Chrome プロセスは 0 で、この呼び出しについて CDP トレースやプロセス時系列も採っていないため、この差をブラウザ再利用や起動コストの「償却」に帰することはできません。

また、これは macOS 上の colima VM の数字です。ベアメタルの Linux では異なります。0.78 秒を、まるでそのまま他環境でも通用する値のように SRE に伝えてはいけません。

実践: 両側から上限を探る

CONCURRENT + QUEUED → 429 という契約は、どこでも繰り返し語られますが、実際に示されることはあまりありません。

準備はこうです。fixture の route 側で 5 秒スリープさせ、各リクエストが既知の時間だけ 1 セッションを占有するようにします。そこへ CONCURRENT + QUEUED + 4 件を同時送信し、何が返るかを見ると同時に、別スレッドで /pressure をポーリングしてコンテナ自身の内部カウントも読み取ります。

ここから分かったことは 3 つです。

上限は毎回ぴったり CONCURRENT + QUEUED でした。成功したレスポンス数は 4、8、10 で、それぞれの設定値の合計に一致しています。拒否数は、3 回ともはみ出した 4 件でした。

上限は動きます。イメージに焼き付けられた固定値ではなく、設定した値そのものです。環境変数を変えるだけで 4 → 8 → 10 と動くことが、この機能を単なる雑学ではなく実用にしている点です。

そして、2 つのシグナルは独立しています。クライアントのステータスコードは実際の HTTP レスポンスから、/pressure は別スレッドでポーリングしたコンテナ内部のカウントから得ました。3 回の短い実行では両者は一致しました。これは /pressure が本番で使える候補シグナルであることを示しますが、完全な autoscaling 契約ではありません。ポーリング頻度、リセットの意味、複数レプリカの集約、長時間の混在負荷での挙動は、まだ検証が必要です。

成功/失敗の件数だけでは見えないニュアンスがあります。キューに入ったリクエストは失敗するのではなく、待つのです。しかも、かなり待つことがあります。 (2, 2) で 5 秒の処理を行ったとき、成功レスポンスは 5.7 秒から 11.0 秒の間に届き、中央値は 8.3 秒でした。したがって end-to-end の遅延は、おおむね 2 セッション分に達します。harness は受付時刻と実行開始時刻を別々には記録していないため、その遅延すべてをキュー待ちに帰属させることはできません。

実際のジョブではどう見えるか

たとえば、毎晩 4,000 件の商品ページを PDF にし、1 ページあたり約 5 秒かかるとします。CONCURRENT=5, QUEUED=5 に設定すると、スループット上限は 5 秒で 5 ページ、つまり 1 秒あたり 1 ページです。パイプをちょうど満杯に保てれば、処理には約 67 分かかります。これはベンチマークではなく、測定結果に基づく算数ですが、デプロイ前にあなたがやるべき算数です。

実行中と待機中の枠がすべて埋まった後に届いたリクエストは、即座に 429 になりえます。同時送信したからといって、どの順番のリクエストが負けるかは保証されません。ジョブランナーはこのレスポンスを backpressure として扱い、ジッター付きの上限付きリトライを行うべきです。さもないと、上位のジョブ管理が進み続ける一方でページが失われる危険があります。これは、この harness で実証した故障シナリオではなく、運用上のリスクです。

実践: エンドポイントが実際に見ているもの

レンダリングの忠実さを正直にテストするため、fixture ページは、実ブラウザでなければ見えないようにマーカーテキストを隠しています。表示される文字列 Runtime Injected Marker 88 は、ロード時に JavaScript の断片から組み立てられるため、サーバーが送るどのバイト列にも、そのまま連続したリテラルとしては存在しません。このページを静的に fetch すると 702 バイトが返りますが、マーカーは含まれていません。

/content が 811 バイトで挿入済みマーカーを返したということは、HTML が返る前に本物の Chromium がページをレンダリングしたということです。/scrape は、JavaScript 実行後にしか存在しない node から値を抜き出しました。どちらも クライアント側の自動化コードなし、つまり認証済みの POST 1 回で動きました。

それが本質的な売りです。同じテストの中で、静的 crawler はこの種のコンテンツを完全に取り逃し、in-process の browser library（chromedp、rod、Selenium）は明示的な待機処理を書いて初めて拾えました。Browserless は curl のようなリクエストでそれを拾います。自動化コードの代わりに、デプロイの重さを払っているわけです。

ただし、この主張にも限界があります。証拠は私の fixture のコンテンツ種別に関するものであって、現代 Web 全体の調査ではありません。また、/unblock（検出回避用エンドポイント）は意図的に触れていません。したがって、ここでの結果を anti-bot 対応の能力証明として読んではいけません。/function、/download、/performance も未検証です。

実践: 短期の残留物チェック

コンテナ化 Chrome には「死体を残す」評判があるため、CONCURRENT=3 で 30 セッションを順次実行し、コンテナ内のプロセス数を数えました。

その前に、検出器を較正しました。セッション実行中に /proc の列挙器は 11 個の chrome 系プロセス（browser、zygote、GPU、renderer、utility）を読み取りました。これが重要なのは、計測器が Chrome を見えていることを証明するからです。そうでなければ、実行後に 0 を返しても、それは「何もない」のではなく「見えていない」だけかもしれません。カウントできることを証明せずに「0 プロセス」と言う leak テストは無価値です。

30 セッション後は、Chrome プロセス 0、zombie 0 でした。残っていたのは dumb-init、node、Xvfb、start.sh、sh だけです。/sessions もアイドル時には 0 を示しました。

docker stats によるコンテナメモリ（単一プロセスの RSS ではなく、運用者が見る値）:

30 セッションを通した増加は約 9.5 MB で、サンプリングした曲線は 10 セッション後に横ばいでした。これは、この短い区間で単純な線形リークがあることとは整合しません。Node のウォームアップがもっともらしい説明ですが、このプロセス数とメモリ系列だけでは証明できません。

範囲の注意点として、30 セッションの順次試験は小さな soak にすぎず、耐久試験でも並列試験でもありません。issue tracker にある古くからの EventEmitter リスナー警告のような問題は、数時間・数千セッションで表面化する可能性がありますが、今回はそこまで回していません。ここで支持できる結論は、この時間枠・この v2.55.0 では Chrome プロセスや zombie の蓄積が観測されなかった、という点だけです。

タイムアウト境界

TIMEOUT は調整可能な項目として文書化されています。実際に発火するか確認したかったのです。

TIMEOUT=5000 の状態で、ページを 15 秒保持しようとしたセッションは、ぶら下がることなく 5.007 秒で HTTP 408 を返しました。この 1 回の観測で、設定境界付近での enforcement は確認できました。ただし、タイマー実装の中身までは分かりませんし、スロット解放を証明したわけでもありません。より強い検証としては、試行を繰り返し、/sessions と /pressure がアイドルに戻るのを観測し、その後のリクエストが解放されたスロットを取れることまで確認すべきです。

移行の落とし穴: PREBOOT は無効で、何も教えてくれない

今回測った中で、アップグレード前に一番渡してほしかった結果はこれです。

Browserless 2.0.0 では PREBOOT と KEEP_ALIVE が削除されました。changelog では、分かりにくく、効果が薄く、バグの原因になっていたため削除したとされています。それは妥当です。問題は、v1 の設定をそのまま v2 にコピーしてしまうことです。これは、実際にもっとも起こりがちなアップグレード方法です。

コンテナを -e PREBOOT=true 付きで起動し、デフォルトと比べました。

いずれのタイミングも、デフォルト側の min–max 範囲の中に収まっています。つまり、差ではなくノイズです。そして、何も事前ウォームされていません。PREBOOT=true のコンテナはアイドル時にブラウザを 1 つも抱えておらず、フラグなしと同じでした。さらに 2 つ、数値ではないシグナルがあります。

• /config に preboot キーが存在しない。あるのは concurrent、queued、timeout、token、maxCPU、maxMemory、retries などです。
• エラーもない。警告もない。コンテナログにも何も出ません。

したがって、v1 の PREBOOT 設定は、v2 の通常起動とログ確認の範囲では、静かな no-op です。/config にキーがなく、挙動も変わらないことが検出可能なシグナルです。Browserless は明示的な拒否や警告を出しません。移行確認では、起動が緑で通ったかどうかではなく、実際に適用された設定を確認する必要があります。

KEEP_ALIVE は逆のケースで、この 2 つを一緒に扱ってはいけません。 同じリリースで削除されましたが、こちらは静かではありません。コンテナをスポットで確認すると、stdout に Environment variable of "KEEP_ALIVE" is deprecated and ignored. と出ます。これは運用者向けの適切な警告です。KEEP_ALIVE は PREBOOT と同じ計測ハーネスにはかけていないので、ここでは計測ではなく確認結果として報告しています。ただ、方向性としては十分はっきりしています。静かな罠なのは PREBOOT だけです。Browserless は、単純に「v2 は v1 のフラグを無視する」と片付けるよりも、KEEP_ALIVE についてはずっと誠実です。

長所と短所

長所

• 文書どおりに振る舞う受付制御があり、設定変更に合わせて動く。3 つの異なる上限で、クライアントのステータスコードとサーバー側カウントの両方で確認済み。
• /pressure が、実行中・待機中・拒否済みの数を 3 回の短い試験でクライアント可視の値と一致させた。autoscaling やアラート入力の候補として評価できる。
• クライアント側の自動化コードなしで本物の Chromium レンダリングが可能。認証済み POST 1 回で、静的 fetch では見えない JS 挿入 DOM を取得できた。
• 30 セッションの順次実行で Chrome プロセスの蓄積なし。終了後のプロセス数は Chrome 0、zombie 0。
• 1 回の TIMEOUT 試行で、5.000 秒の予算に対して 5.007 秒で 408 を返した。cleanup と slot 解放は別途確認していない。
• 認証はデフォルト有効。4 つの REST エンドポイントは、トークンなしではすべて 401 を返す。
• 使える状態になるまで docker run 1 回で約 0.78 秒、その後の最初のレンダリングは 0.32 秒。

短所

• 4.34 GB のイメージ。 これが正直なコストで、レジストリ、CI キャッシュ、コールドデプロイ時間に効いてきます。
• SSPL-1.0 か Browserless 商用ライセンス。 現行条件を、あなたのデプロイおよび配布モデルに照らして確認してください。
• v1 の PREBOOT は v2 で受け付けられるが、静かに無視される。エラーも警告も /config キーもない。
• 依存関係を追加するのではなく、サービスを運用することになる。つまり、コンテナ、トークン、ネットワーク経路、受付上限、アップグレード責任が必要です。
• キューに入ったリクエストは (2, 2) の試験で end-to-end 遅延をおよそ 2 セッション分まで押し上げた。個別のキュー待ち時間は計測していません。
• 測定した REST の時間には HTTP 往復が含まれ、ブラウザ起動コストの切り出しやブラウザ再利用の証明にはなっていません。

どんな人に向いていて、どんな人には向かないか

Browserless が価値を持つのは、複数の場所でブラウザが必要なとき です。複数アプリで共有するレンダリングサービス、各サービスに Chrome 依存を持たせる代わりに HTTP 経由でスクリーンショットや PDF を得たいチーム、測れる backpressure 付きの容量上限が本当に必要なジョブパイプライン。そういう形に合います。すでに Docker を運用していて誰かがデプロイを担当しているなら、運用面のストーリーは明快です。予測可能な受付、観測可能な backpressure、そして 30 セッションの順次確認で Chrome プロセスや zombie の蓄積は見られませんでした。

また、スタック内の各サービスがそれぞれ Chromium を個別に入れるしかない状況なら、それを 1 つのコンテナにまとめるのは、かなり筋の良い設計上のトレードオフです。

一方、1 本のスクリプトを書くだけなら、これはやりすぎです。3.4 GB 級を引っ張ってきてコンテナを立て、たった 1 つの Python ファイルがレンダリング済みページを取るためだけに運用するのは、規模の小さい仕事には大げさです。プロセス内の browser library なら、別サービスのデプロイなしで済みます。SSPL 条件が商用製品に合わず、解決できない場合もやめるべきです。さらに、欲しいのが「コールドコストなしで事前ウォームされた browser」であるなら、それも向いていません。v2 の PREBOOT はそれを実現してくれないからです。そして、真の問題が anti-bot 対応なら、それは今回意図的に試していない別エンドポイントの領域なので、保証はできません。

代替案と、Thunderbit が入る位置

比べるべきなのは Browserless と別のコンテナではありません。ブラウザがどこで動き、誰が生かし続ける責任を持つのか、です。

関連レビュー: Browsertrix Crawler review

関連レビュー: chromedp review

自分のプロセス内にブラウザが欲しく、待機処理を書くのが苦にならないなら、library の方が軽く、デプロイもありません。そのあたりは Playwright と Puppeteer の比較 や、より広い オープンソーススクレイピングプロジェクト総覧 で整理しています。

そもそもブラウザ運用自体をしたくないなら、私たちの Thunderbit も管理型の選択肢です。Browserless はレンダリング済み素材を返し、それをコード側で解釈します。一方 Thunderbit は、レンダリング基盤を提供側が持ったまま、Markdown や schema に合ったデータを返せます。この記事では Thunderbit の遅延、容量、障害時の挙動、抽出品質、コストはベンチマークしていないので、この表は性能比較ではなく、責任分界を示すものです。

同じテスト期間の関連読み物として、Crawl4AI review は自前運用する browser-backed Markdown パイプラインを扱っており、web scraping tools overview はカテゴリ全体を俯瞰しています。

Thunderbit で Web データ抽出を試す

結論

Browserless を運用すべきか？ はい、複数の呼び出し元がブラウザ処理を必要とし、誰かがコンテナを運用でき、ライセンスレビューがデプロイモデルを承認するなら、使う価値があります。3 つの synthetic な受付試験では、受け入れ数は CONCURRENT + QUEUED と一致し、あふれた分には 429 が返り、/pressure はクライアントに見える数と一致しました。別の 30 セッション順次チェックでは、Chrome プロセスや zombie の蓄積はありませんでした。1 回のタイムアウト試験では、設定境界付近で 408 が返りました。これらは有用な上限付きの観測であって、普遍的な保証ではありません。

ただし、導入コストは正直に見積もる必要があります。これは 4.34 GB のイメージであり、あなたが運用するサービスであって、ただ追加する依存関係ではありません。このテストでは、in-process の browser library との速度比較は確立していません。得られるのは、ブラウザを 配給制にできる ことです。つまり、既知の上限と、測定できる backpressure です。30 セッションの順次確認では、Chrome プロセスや zombie の蓄積は見られませんでした。代償はデプロイの重さと、ちゃんと読むべきライセンスです。数ページを 1 本のスクリプトで処理したいだけなら、このトレードは見合いません。複数サービスが依存するレンダリング層を運用するなら、話は別です。ただし導入時には v1 の環境変数をよく確認してください。PREBOOT は、働いているように見えて、実際には何もしないからです。

Thunderbit で Web データ抽出を試す Get Started Free

FAQs

Browserless は headless Chrome を速くしますか？ このテストでは答えられません。HTTP エンドポイントが応答可能になったのは docker run から 0.78 秒後で、その後の最初の /content 呼び出しは 0.32 秒、同じコンテナ内の後続呼び出しは約 0.15 秒でした。これらは HTTP 往復、ブラウザ作業、ナビゲーション、レスポンス転送をまとめた値です。起動時間の切り出し、プロセス再利用のトレース、比較可能な in-process ベンチマークの公開はしていません。Browserless は共有サービス境界と受付制御のために使い、自分の遅延経路は自分でベンチマークしてください。

Browserless の concurrency 上限を超えるとどうなりますか？ 即座に HTTP 429 が返ります。上限はぴったり CONCURRENT + QUEUED で、(2,2) では 4 件成功・4 件拒否、(3,5) では 8 件成功・4 件拒否、(5,5) では 10 件成功・4 件拒否を確認しました。サーバーの /pressure は毎回、running、queued、recentlyRejected の一致した件数を返しました。なお、キューに入ったリクエストは失敗ではなく待ちます。(2,2) で 5 秒仕事なら、成功レスポンスは 5.7 秒〜11.0 秒でした。クライアントは 429 を backpressure として扱い、リトライとバックオフを入れるべきです。

Browserless v2 で PREBOOT はまだ使えますか？ 使えません。PREBOOT は 2.0.0 で削除され、v2 では -e PREBOOT=true を付けてもエラーも警告も出さず、何もせずに受け付けます。無効であることは 3 つの方法で確認しました。遅延はデフォルトと区別できず、アイドル時の PREBOOT=true コンテナは Chrome プロセス 0、/config にも preboot キーがありません。v1 設定を移行した場合、インスタンスは事前ウォームされません。同じリリースで削除された KEEP_ALIVE は、"deprecated and ignored" の警告を出します。したがって、静かな失敗は PREBOOT 固有です。

Browserless は商用利用無料ですか？ このリポジトリでは SSPL-1.0 か Browserless の商用ライセンスが提供されていますが、この記事では個別の商用・クローズドソースのケースをどちらかに割り当てていません。現行の LICENSE と 公式導入ガイド を確認し、そのうえでソフトウェアライセンスの責任者に、あなたのデプロイおよび配布モデルを評価してもらってください。

Browserless は zombie Chrome プロセスを残しますか？ 短時間の試験では蓄積は見られませんでした。30 セッションの順次実行後、コンテナには Chrome プロセス 0、zombie 0 で、残っていたのは dumb-init、node、Xvfb、start.sh、sh だけでした。検出器はセッション稼働中に chrome 系プロセス 11 を数えていたので、盲検ではありません。コンテナメモリは 294 MiB から 303 MiB まで増え、その後サンプル上は横ばいでした。これは数時間、並列、あるいは数千セッション規模の耐久結果ではありません。