你的 headless Chrome 每開一個 tab 吃掉 300 MB RAM。十幾個同時跑,OOM killer 就來敲門了。

這件事荒謬的地方在於:你根本不需要一個「瀏覽器」。你需要的是 DOM 樹、JavaScript 引擎、還有網路請求能力。螢幕渲染、GPU 合成、真皮座椅級的 Web API——這些東西在 headless 模式下全是死重。

Lightpanda 就是把這個死重砍乾淨的產物。GitHub 上 26,000 顆星,用 Zig 從零寫的 headless browser,記憶體是 Chrome 的十六分之一,速度快九倍。

它不是「更輕的 Chrome」。它是一台只剩引擎和輪子的車。


為什麼不「改良」headless Chrome 就好

想像你要搬家。你需要一台貨車。但你手上只有一台全配的賓士 S-Class——真皮座椅、Burmester 音響、12 吋螢幕儀表板,全都佔空間。你當然可以把後座拆了硬塞箱子進去,但不管怎麼拆,底盤設計就不是給載貨用的。

headless Chrome 就是那台拆了座椅的 S-Class。

它的架構天生就是多進程的:每個 tab 一個獨立 process,有自己的記憶體空間。它跑完整的渲染管線——layout、paint、composite——即使沒有螢幕在看。它載入幾千個 Web API,大部分在 headless 場景裡根本沒人呼叫。

Lightpanda 的做法不是改良,是重寫。三個關鍵決策讓它輕了一個數量級:

砍掉整條渲染管線。 沒有 layout,沒有 paint,沒有 composite。DOM 樹建完就能查詢,中間省掉的計算量是最大的一塊。

單進程架構。 Chrome 每個 tab 都是獨立 process,光 process 間通訊的開銷就不少。Lightpanda 把所有東西塞進一個 process,記憶體碎片化的問題直接消失。

V8 Snapshot。 把 JavaScript 引擎的初始化狀態序列化成一個快照檔,啟動時直接載入。結果就是「瞬間啟動」——不用每次都重新 bootstrap 一整個 V8 runtime。


那個語言選擇本身就是設計哲學

Lightpanda 用 Zig 寫。不是 Rust,不是 C++,是 Zig。

為什麼?因為它的核心元件來自三種不同語言:V8 是 C++,html5ever 是 Rust,Libcurl 是 C。要把這三個東西無縫黏在一起,需要一個對 C ABI 原生相容的語言。Zig 剛好就是。

最後編譯出來的是一個單一 binary。部署的時候丟一個檔案上去就好。不用裝 runtime,不用管 dependency,不用 Docker——雖然它也有 Docker image 啦。

1
2
3
# macOS (Apple Silicon)
curl -L -o lightpanda https://github.com/lightpanda-io/browser/releases/download/nightly/lightpanda-aarch64-macos
chmod a+x ./lightpanda

就這樣。一個 curl 加一個 chmod,你就有一台 headless browser 了。


跟你現有的程式碼幾乎無縫

最實用的一點:Lightpanda 實作了 Chrome DevTools Protocol(CDP)。白話講就是——你現有的 Puppeteer 程式碼,只要改一行就能用。

puppeteer.launch() 換成 puppeteer.connect(),指向 Lightpanda 的 WebSocket 端點:

1
2
3
4
5
const browser = await puppeteer.connect({
browserWSEndpoint: "ws://127.0.0.1:9222",
});
const page = await (await browser.createBrowserContext()).newPage();
await page.goto('https://example.com', { waitUntil: "networkidle0" });

其他程式碼不用動。page.evaluate、page.click、page.waitForSelector——該有的 CDP 操作都支援。

它甚至在原始碼裡已經有 src/mcp/ 模組了,代表 Model Context Protocol 整合正在進行中。對 Claude Code 生態來說,這意味著 AI agent 未來可以透過標準化協定直接控制一台超輕量的瀏覽器。


什麼時候不該用

該講的講清楚:Lightpanda 不是萬能的。

沒辦法截圖。 渲染管線整條砍掉了,沒有像素就沒有截圖。需要做視覺回歸測試的,還是得用 Chrome。

Playwright 相容性不穩。 Playwright 會根據瀏覽器回報的能力來選擇執行路徑,Lightpanda 每次新增 API 支援反而可能打破原本能跑的腳本。目前 Puppeteer 是最穩的選擇。

CORS 還沒做完。 跨域請求處理仍在開發中。如果你的爬蟲場景大量依賴 CORS,目前會踩坑。

遙測預設開著。 記得加 LIGHTPANDA_DISABLE_TELEMETRY=true

還有一個要注意:授權是 AGPL-3.0,不是 MIT。如果你打算把它包進商業產品的後端,得確認合規性。


六個值得用的場景

AI Agent 批量操作網頁。 同時跑幾十個 agent 控制瀏覽器填表、擷取資料。headless Chrome 跑三四個就卡死,Lightpanda 用同樣的記憶體可以跑幾十個。

SPA 網站爬蟲。 React、Vue、Angular 寫的頁面,cURL 抓到的是空殼。需要 JavaScript 渲染才能拿到內容,但你不需要為此付出完整瀏覽器的代價。

CI/CD 測試加速。 把 headless Chrome 換成 Lightpanda 當測試後端。瞬間啟動加上低記憶體消耗,特別適合資源有限的 CI runner。

LLM 訓練資料採集。 大量抓網頁餵模型的場景。基礎設施成本直接砍到十六分之一。

SEO 預渲染。 幫 SPA 網站產生靜態 HTML。搜尋引擎抓得到、用戶體驗也不變。

競品監控。 同一台機器可以同時盯更多網站的動態內容,因為每個 instance 只吃幾十 MB。


兩條線

回頭看,headless browser 領域一直有兩條平行的需求線在跑。

第一條是「完整的瀏覽器、只是沒螢幕」——headless Chrome 走的路。什麼都能做,代價是什麼資源都要。

第二條是「只要 DOM + JS + 網路,其他都是多餘」——Lightpanda 走的路。能做的事少一半,但資源消耗降了一個數量級。

大部分人一直在第一條線上最佳化:用 pool 管理、限制 tab 數量、加記憶體。但真正的槓桿在第二條線——問題不是「怎麼讓 Chrome 吃少一點」,而是「你到底需不需要一個 Chrome」。

原文來源:Lightpanda GitHub