Lightpandaは「速いChrome」ではない｜レンダリングを捨てた設計と、使えるケースの判断基準

Lightpandaは「速いChrome」ではない ── レンダリングを捨てた設計と、使えるケースの判断基準

「Chromeの最大11倍速い」「メモリ最大16分の1」。この数字だけを見ると、まるでChromeの高速版のように思えます。

しかし、それは根本的に誤った理解です。Lightpandaは「速いChrome」ではなく、「レンダリングを丸ごと捨てたブラウザ」です。この違いを正しく理解しないと、導入後に「思っていたのと違う」という事態になりかねません。

本記事では、Lightpandaが何を捨てて何を得たのか、そしてあなたのユースケースで実際に使えるのかを、技術的根拠に基づいて解説します。

Lightpandaは何がどう違うのか――スペックから読む設計思想

Lightpandaは、Zig言語でゼロから構築されたオープンソースのヘッドレスブラウザです。Chromiumのフォークでも、WebKitのパッチでもありません。AIエージェントと自動化のために、最初から設計された新しいブラウザエンジンです。

Lightpanda | The headless browserlogoIconDiscordGithubLogoSVGIconNoCloudIconSlowBrowserIconSharedStateIconLightpandaIconChromeIconLightpandaIconChromeIconScrapeIconBuildIconAutomateblueskyIconGithublogoIconLinkedinIconXIconDiscordIconGithub

lightpanda.io

主要なスペックを整理します。

Lightpanda公式は自身のブラウザを「curl with JS execution（JS実行ができるcurl）」と表現しています（公式Xアカウントでの発言）。この一言が、Lightpandaの本質を最も端的に示しています。

ポイントは、JavaScriptエンジンにV8を採用している点です。つまりJavaScriptの実行自体は可能です。「ヘッドレスだからJSが動かない」というわけではありません。

Puppeteer/Playwrightとの互換性もCDP経由で確保されており、既存のスクリプトからの移行はブラウザ接続先のエンドポイントを変更するだけ。コード変更は基本的に3行程度です。

「レンダリングを捨てた」とは何を意味するのか

ここがLightpandaを理解する上で最も重要なポイントです。

通常のブラウザ（Chromeを含む）は、ページを表示するために以下のレンダリングパイプラインを実行します。

1. HTML解析 → DOMツリー構築
2. CSS解析 → CSSOMツリー構築
3. レンダーツリー構築 → DOMとCSSOMを統合
4. レイアウト計算 → 各要素の位置・サイズを計算
5. ペイント → ピクセルに変換
6. コンポジット → GPU合成・画面描画

ヘッドレスChromeは「画面に映さない」だけで、ステップ3〜6のレンダリング処理を依然として内部で実行しています。CSSの計算やレイアウトの決定は行われるのです。

一方、Lightpandaはステップ1（HTML解析）とJavaScript実行だけに特化し、CSSのレイアウト計算（ステップ3〜6）を省略しています。CSS自体は読み込みますが、要素の位置やサイズを決めるレイアウト計算は行いません。

これが意味することを整理すると、こうなります。

Lightpandaにできること：

• HTMLの取得・解析
• JavaScript実行（V8）
• DOM操作
• XHR / Fetch APIによるAJAX通信
• Cookie・ヘッダー・プロキシ制御
• ネットワークインターセプション

Lightpandaにできないこと：

• スクリーンショット撮影
• PDF生成
• CSSのレンダリング結果の取得
• 視覚的なレイアウト情報の取得
• Canvas / WebRTCなどの高度なWeb API

つまり、Lightpandaは「目が見えないが、手足は動かせるブラウザ」です。ページの構造とデータにはアクセスできますが、「見た目」に関する一切の情報を持ちません。

なぜ11倍速いのか――削ったことによる速さの正体

「11倍速い」というベンチマーク結果の背景を、技術的に分解します。

レンダリングパイプラインの省略

前述のとおり、通常のブラウザはHTML解析後にCSS計算、レイアウト、ペイント、コンポジットと続きます。このレンダリング処理は、ページの複雑さに応じてCPU・メモリを大量に消費します。ヘッドレスChromeでも、内部的にはBlinkエンジンがこの処理を実行しています。

Lightpandaはこれを根本から不要にしました。CSSのレイアウト計算を行わないため、CSSOMツリーの構築、スタイルの継承計算、レイアウトツリーの構築といった処理がゼロです。

Zig言語による低レベル制御

Chromiumは主にC++で書かれていますが、歴史的に蓄積された膨大なコードベース（数千万行）を持っています。Lightpandaの開発チームは「Chromiumのコードベースはモジュール化されるように設計されていない」と述べており、レンダリングエンジンだけを切り離すことが極めて困難だったと説明しています。

Zigを選択したことで、メモリの明示的な管理と低レベル制御が可能になり、ヘッドレス用途に必要な最小限の機能だけを実装できました。

ベンチマーク結果の詳細

公式のベンチマークは、AWS EC2 m5.largeインスタンスでPuppeteerを使い、JavaScriptの実行を必要とする933ページのWebサイトを対象に実施されました。

注目すべきは、Lightpandaが並列数を25まで増やしてもメモリ使用量が123MBに収まっている点です。Chromeは100並列タスクで4.2GBに達します。

この差は単なるチューニングではなく、アーキテクチャレベルの設計差から生まれています。

※ 上記はネットワーク越し933ページのベンチマーク結果。ローカルベンチマーク（ネットワーク遅延なし）では最大11倍速い・メモリ9分の1という結果も報告されています。

SPAサイトで機能するのか？

ここが実務で最も気になるポイントでしょう。結論から言うと、「部分的に動くが、完全な互換性は期待できない」です。

V8搭載 = JavaScriptは動く

LightpandaにはChromeと同じV8エンジンが搭載されています。つまり、JavaScriptの言語仕様レベルでは問題ありません。async/awaitもPromiseもES Modulesも動きます。

問題はWeb APIの対応範囲

SPAフレームワーク（React、Vue、Angular等）がブラウザで動くためには、JavaScript言語仕様だけでなく、ブラウザが提供するWeb APIが必要です。

例えば以下のようなAPIです。

• window.getComputedStyle() → CSSの計算結果を取得
• element.getBoundingClientRect() → 要素の位置・サイズを取得
• IntersectionObserver → 要素の可視性を監視
• ResizeObserver → 要素のサイズ変化を監視
• requestAnimationFrame → アニメーションフレーム制御

Lightpandaはレンダリングエンジンを持たないため、レイアウトや視覚に関するAPIは原理的に正確な値を返せません。DOM API、Fetch API、XHRは対応済みですが、Web APIは「数百ある」とLightpanda自身が認めており、対応は段階的に拡大中です。

現実的な動作パターン

動く可能性が高いケース：

• サーバーサイドレンダリング（SSR）されたReact/Nextサイトのデータ取得
• APIコールの結果をDOMに反映するシンプルなSPA
• フォーム入力やリンクのクリックといった基本的なインタラクション

動かない可能性が高いケース：

• CSS-in-JSに依存したスタイル計算
• IntersectionObserverを使った無限スクロール
• Canvas/WebGLを使ったグラフ描画
• 複雑なアニメーションやトランジション
• レイアウト情報に依存するUI制御

コミュニティの報告では、約5%のサイトでクラッシュまたは未対応APIによるエラーが発生しているとされています。逆に言えば、95%のサイトではある程度動作しているということです。

「Reactを使っているサイトならほとんど機能しないのでは？」という見方もありますが、これはやや悲観的すぎる評価です。正確には「Reactサイトでも、レイアウト情報に依存しない操作であれば動作する可能性がある。ただし、フルレンダリングを前提としたSPAの完全な再現は不可能」というのが実態です。

用途別の適性判断――フローチャートで「自分のケース」を確認する

Lightpandaの特性を踏まえた、用途別の適性判断です。

向いている用途

• 大規模Webスクレイピング: 数百〜数千ページを並列で高速に取得。メモリ効率が桁違い
• AIエージェントのWeb閲覧: LLMにページ内容を渡す前処理。テキストとDOM構造が取れれば十分
• API的なデータ取得: XHR/Fetchで取得されるJSONデータの収集
• リンク巡回・サイトマップ生成: ページ構造の解析
• CI/CDでのヘルスチェック: ステータスコードとDOM要素の存在確認

向いていない用途

• ビジュアルリグレッションテスト: スクリーンショットが撮れない
• PDF生成: レンダリングエンジンがない
• E2Eテストの完全代替: レイアウト依存のテストは不可
• 複雑なSPAの操作自動化: Web API対応が不完全

判断フローチャート

使うかどうか迷ったら、以下の順に確認してください。

1. スクリーンショットやPDF生成が必要か？ → Yes: Lightpandaは不可。Chrome/Playwrightを使う
2. ページのテキスト・データだけ取れればよいか？ → Yes: Lightpandaが最適
3. 対象サイトはSPAか？ → No: Lightpandaが最適 / Yes: 次へ
4. SPAでレイアウト依存の操作が必要か？ → Yes: Chrome推奨 / No: Lightpandaで試す価値あり
5. 大量ページを並列処理するか？ → Yes: Lightpandaのメモリ効率が大きなアドバンテージ

Lightpandaを選ぶ前に確認すること――Beta版として正しく使うために

Lightpandaは「速いChrome」ではありません。レンダリングパイプラインを丸ごと捨てることで、ヘッドレス用途に特化した全く別のブラウザです。

※ベンチマーク条件: AWS EC2 m5.large、Puppeteer使用、933ページ対象。ローカル環境では異なる結果になる場合があります。

AIエージェントが爆発的に増加し、Webからの情報取得がボトルネックになりつつある今、「レンダリングは本当に必要か？」という問いは極めて合理的です。

必要なのが「データ」であって「見た目」でないなら、Lightpandaは現時点で最も効率的な選択肢の一つです。ただし、Beta版であることを忘れないでください。本番導入前にはChromeへのフォールバックを必ず用意しておきましょう。