lightpanda-io/browser 37,936★:把渲染引擎整个扔掉的浏览器——933 个页面爬完峰值 123 MB,Chrome 做同一件事要 2 GB

今天 GitHub 趋势页上,lightpanda-io/browser 当日新增 559 星;按 GitHub API 在 10 月 30 日 21:00 CST 的取数,仓库是 37,936★、1,849 个 fork、98 条未关 issue,主语言 Zig,许可 AGPL-3.0,2023 年 2 月 7 日建仓。三天前它刚发布 1.0.2,是 1.0.0(10 月 2 日)之后的第二个补丁版。

这东西值得写,不是因为它星多,而是因为它做的选择很少见:它把浏览器里最贵的那部分——渲染管线——直接删了,只留下脚本真正用得到的东西。做完之后,爬 933 个页面峰值内存 123 MB,而 Chrome 在同一份测试里要 2.0 GB;单页自动化重复 100 次,它 21.2 MB,Chrome 402.1 MB。

代价也写得很直白,而且正好落在很多人会踩的地方:它没有像素。Page.captureScreenshot 返回的是一张占位图,不是页面。

一句话定位:不画页面的浏览器

• 不是 Chromium 分支,也不是 WebKit 补丁。项目文档第一句就把话说死了:一台用 Zig 从头写的新浏览器,不用 Blink,也不用 WebKit。
• 删掉的是 style → layout → paint → composite 这条管线,保留网络层(libcurl)、HTML 解析(html5ever)、JavaScript 引擎(V8,和 Chrome 同一个)、DOM 与 Web API(用 Zig 实现)。页面在内存里是一棵树,永远不会变成像素。
• 省下来的内存主要来自这里。Chrome 即使跑在无头模式下,仍然要算图形输出、维护合成器与图层;Lightpanda 连图层这个概念都没有。
• 它把代价写在架构文档里:元素尺寸是「从 CSS 和 HTML 属性得出的近似值」,元素位置是「按 DOM 深度和兄弟顺序模拟的」,不是真实布局。这句话决定了它的适用边界,后面会单独展开。

这个取舍解释了一件事:为什么它的 benchmark 差距是数量级的,而不是百分之几十。删掉一整条管线,和省一点解析器开销,不是同一个量级的事情。

为什么是现在:熬了三年半,三周里发了三个版本

• 2023 年 2 月建仓,2026 年 10 月 2 日才发 1.0.0。三年半才敢挂 1.0,对一个声称「能跑现代网页」的引擎来说,这个节奏是诚实的——Web 平台太大,补齐要时间。
• 1.0.0 补的是「能当正式驱动用」的东西:经典 HTTP WebDriver 补全(会话、导航、前进后退、元素、点击、输入、Cookie、视口),CORS 从实验开关变成默认强制执行。
• 1.0.1(10 月 15 日)补的是表单与输入:回车隐式提交、change 事件时机、Ctrl+A 全选、contenteditable 判定、以及 BiDi / testdriver / press 共用一套按键表。
• 1.0.2(10 月 23 日)补的是 Web Crypto 与布局细节:Ed25519、X25519、ECDSA、RSA-PSS、AES-KW;元素宽度开始按父级解析(block、inline、float、百分比、min/max-width、基础 flex),getBoundingClientRect 改成相对视口。这些是在往真实布局靠,但离「能截图」还很远。
• 包体积掉了一半以上:下载页上 1.0.0 的 Linux x86_64 二进制是 179.5 MB,1.0.2 是同名文件 72.9 MB,deb 包 18.8 MB。官方发布说明没专门解释这件事,但对一台要横向扩几十个进程的机器来说,部署体积本身就是成本。

如果你只看一个信号:1.0 之后三周连发三个版本,1.0.2 的发布说明有四十多条行为变更与 API 补齐。这项目的开发强度是真的。

三张官方成绩单,和它们各自的边界

三组数字都来自官方 benchmark 仓库和文档,测试机是 AWS m5.xlarge 全新 Ubuntu,Chrome 143.0.7499.169,内存用 smem 的 PSS 口径(共享页不重复计),每 100 毫秒采样一次取峰值。这是厂商自己跑的测试,读的时候要按「自报成绩」算,不是第三方复测。

一、爬取:933 个链接,两种并发模型

抓的是自家演示站 demo-browser.lightpanda.io/amiibo/,从首页顺着链接走完 933 个 URL,客户端都用 Go 的 chromedp,保证是同一套驱动代码。

• 25 并发这一档是两个引擎都在最佳区间的位置:4.81 秒对 46.70 秒,123 MB 对 2.0 GB,大约 9.7 倍速度和 16 倍内存。官方口径的「9 倍快、16 倍省」就是从这行来的。
• 两种引擎的扩展方式不一样,这点比数字重要。Chrome 是「一个浏览器开多个标签」,共享渲染进程和 V8 堆;Lightpanda 不支持一个进程开多个标签,官方只能起多个进程,每个进程一个端口。所以这张表严格说是「标签数 vs 进程数」的比较。
• Chrome 在 5 个标签之后就持平了(45.66 秒 → 46.70 秒),因为标签在抢同一批资源;Lightpanda 到 25 个进程还在变快,100 个进程才因为调度和内存开始回落(5.23 秒、410 MB)。
• 一个反面信号:100 个进程只比 25 个进程慢一点点,却多花 287 MB 内存。真要压满机器,25 到 50 之间是更划算的档位。

二、单页自动化:这才是大部分人真实的用法

爬取测的是「抓和走链接」,这组测的是「加载页面、等两个 XHR 回来、把数据读出来」,重复 100 次,本地服务器供页以排除网络抖动。

• 16 毫秒对 185 毫秒,单次差 11 倍多;100 次下来是 1.7 秒对 18.6 秒。
• CPU 那一列比内存更值得看:4.6% 对 158.6%,意味着同样一台机器上,Lightpanda 几乎不占算力,你可以把它和别的服务塞在一起跑;Chrome 是大核吃满,一跑起来整机都在抖。这一条对 1 GB、2 GB 的小机器是决定性的——本站另一篇1.6 GiB 服务器实测清单里算过,无头 Chrome 那点余量根本塞不进去。
• 口径提醒:这组是本地供页,真实网络下两者的差距会被网络延时摊薄。16 ms 的意义是「解析加执行很快」,不是「抓一个站只要 16 ms」。

三、Agent:能干活,但排名第一的不是引擎

这组是最容易被误读的一组。官方用自家 lightpanda agent(不走 MCP、不走 CDP,模型和引擎在同一进程里)跑 AssistantBench 33 题验证集和 GAIA Level 1 53 题验证集,模型 Claude Sonnet 4.6,单题超时 1,800 秒。

• 成绩:AssistantBench 严格准确率 69.7%,GAIA Level 1 83.0%,两边零超时;按 token 折算的单题成本分别是 1.94 美元和 0.34 美元。
• 换工具面之后,分数掉下来:同样的模型走 MCP,Lightpanda MCP 是 66.7% / 86.8%;把 Lightpanda 当引擎塞进 agent-browser 是 57.6% / 81.1%;agent-browser 配 Chromium 是 57.6% / 84.9%;browser-use 配 Chromium 是 39.4% / 47.2%。
• 官方自己的解读值得抄下来:AssistantBench 上 agent-browser 配 Chrome 和配 Lightpanda 都是 57.6%,一分不差,说明那 9 个百分点的差距来自自家 MCP 的工具设计,不来自引擎;GAIA 上换引擎掉 3.8 个百分点,掉在「需要渲染才能看见的内容」上。
• 所以这张表证明的是:工具面比引擎更能决定 agent 成绩;以及无渲染的代价在特定页面上是量得出来的——GAIA 那 3.8 个点就是门票钱。

怎么用起来:四条路,从一行命令到录制回放

一、一次性抓取,不写代码

1
2
3
4
5
6
7

curl -fsSL https://pkg.lightpanda.io/install.sh | bash
export PATH="$HOME/.local/bin:$PATH"

lightpanda fetch --obey-robots --dump markdown \
  --strip-mode clutter --wait-until networkidle \
  --dump-max-bytes 60000 \
  https://example.com/article

• --dump markdown 直接出 Markdown,是喂给模型最省 token 的形态;--strip-mode clutter 按阅读模式启发式只留正文,配合 --strip-mode shell 去导航与页脚。
• --wait-until networkidle 等网络静下来;动态页要更细的控制就用 --wait-selector 或 --wait-script,再不行用 --terminate-ms 设硬截止,防止死循环脚本把进程拖住。
• 多个 URL 必须加 --json,一个失败不会中断其他 URL,但进程最后会以退出码 1 结束;--fail-on-http-error 则让 4xx、5xx 直接变成退出码 22,方便挂进 CI 判错。

二、当成 Puppeteer / Playwright 的后端

1

lightpanda serve --host 127.0.0.1 --port 9222 --obey-robots

1
2
3
4
5

import puppeteer from 'puppeteer-core';
const browser = await puppeteer.connect({ browserWSEndpoint: 'ws://127.0.0.1:9222' });
const page = await browser.newPage();
await page.goto('https://example.com', { waitUntil: 'networkidle0' });
console.log(await page.evaluate(() => document.title));

• Playwright 用 chromium.connectOverCDP('ws://127.0.0.1:9222')(Python 是 p.chromium.connect_over_cdp(...)),之后 newContext()、newPage()、goto() 都照旧。
• 想走 W3C 标准而不是 CDP,加 --protocol webdriver;两个都要就写两次 --protocol。只给本机用时可以走 Unix socket(--unix-socket /run/user/1000/lightpanda.sock),比 TCP 更好管权限。
• 这一条的价值在于迁移成本:脚本基本不用改,只改连接地址。但标签模型变了——一个进程一个页面,原来在一个浏览器里开十个 tab 的代码要拆成十个进程,每个一条连接。

三、接进 AI 客户端

MCP 是最省事的一条。配置里必须写二进制的绝对路径,因为宿主程序不是从你的终端启动的,看不到你 export 的 PATH:

1
2
3
4
5
6
7
8

{
  "mcpServers": {
    "lightpanda": {
      "command": "/home/you/.local/bin/lightpanda",
      "args": ["mcp", "--obey-robots"]
    }
  }
}

• 暴露的工具是一套浏览器原语:goto、markdown、html、links、extract、findElement、interactiveElements、detectForms、click、fill、selectOption、press、waitForState、structuredData、getCookies。
• markdown 加内联 url 是最省往返的调法:一次请求同时完成导航和取正文。
• 要让几个 agent 同时用一个进程,用 HTTP 传输:lightpanda mcp --port 9223,客户端 POST 到 /mcp。每个连接自动分到一个独立浏览会话(自己的页面、Cookie、内存),靠 Mcp-Session-Id 头维持;相同的 id 则共享同一个会话,适合多个 agent 协作同一页。

四、agent 模式:用自然语言跑一遍,导出成不收 token 的脚本

1
2

lightpanda agent --task "去 quotes.toscrape.com 找到爱因斯坦的名言,告诉我它们归在哪些标签下"
lightpanda agent --no-llm        # 不接大模型,进 REPL 手动敲

• 它支持 Anthropic、OpenAI、Gemini、Vertex、Mistral、Hugging Face、Vercel AI Gateway、OpenRouter,以及任何 OpenAI 兼容端点(OPENAI_BASE_URL),本地模型走 Ollama 或 llama.cpp。
• 最有意思的设计是录制:/save 把这一趟操作导出成 PandaScript——一段原生 JavaScript,里面是 goto、click、fill 这类原语。之后 lightpanda run session.js 回放,确定性执行、不调用任何模型、不花 token。先用模型探路,再把它固化成生产脚本,这条路子比每次让模型重跑一遍便宜得多。

七个必须先知道的限制

1. 没有像素。 Page.captureScreenshot 返回占位图;元素位置是按 DOM 深度和兄弟顺序模拟的,不是布局算出来的。视觉回归、像素级验收、拖拽、canvas 与 WebGL 类页面全部不适用。任何依赖「看一眼截图对不对」的流程,它都替代不了。
2. 一个进程一个页面,没有多标签。 官方 benchmark 自己写明这点,并用多进程多端口来扩。照搬「一个浏览器开 N 个 tab」的旧代码会直接失败。
3. 平台卡得比想象中紧。 x86_64 要 glibc 2.35+(Debian 12、Ubuntu 22.04/24.04),arm64 要 glibc 2.38+(Debian 13、Ubuntu 24.04);Alpine 这类 musl 系统会报 cannot execute: required file not found;没有 Windows 原生二进制(得走 WSL),Android / Termux 也不行。
4. 许可 AGPL-3.0。 自己内部用没问题;把它改一改嵌进对外提供的闭源服务里,要按 AGPL 处理源码义务。做商业产品的,这一条要在动手之前过一遍法务。
5. 遥测默认开着。 官方隐私说明写得很具体:发往 telemetry.lightpanda.io 的是「这次导航是否用了 TLS、上下文类型(页面 / iframe / 弹窗)、agent 模式下用的模型厂商与名称」,不含你访问的 URL 和页面内容。介意就设 LIGHTPANDA_DISABLE_TELEMETRY=true,这比事后解释便宜。
6. Web API 只覆盖一部分。 官方文档的原话是「实现的是无头自动化会用到的 API,不是整个 Web 平台」,并且每天发布 Web Platform Tests 通过率。冷门 API、复杂框架(尤其依赖完整布局或新提案的)会静默失效——JS 报错只是被记进日志,页面看起来照样加载完了。
7. robots.txt 默认不遵守,HTTP 错误默认不报错。 抓取礼貌要自己加 --obey-robots;goto 遇到 404 / 500 仍算导航成功,只把状态码放在返回里,超时也不抛错——脚本必须自己判 httpStatus,否则你会把错误页当正文存进库。

另外补一条容易被忽略的:1.0.0 起 CORS 默认强制执行,跨域 fetch / XHR 不通过就拦。以前靠 --experimental-features cors 打开的老脚本,现在是反过来的,跨域抓取失败要查这里(--disable-features cors 可关)。

和同类比:它抢的是谁的位置

• 它抢的不是 Playwright 的位置,是「Playwright 底下那台浏览器」的位置。上层客户端不变,换引擎。
• 它也抢不掉 curl。纯静态页、纯 API 抓取,curl 更快更省;Lightpanda 的价值在「页面必须跑 JS 才能出内容」这一档。
• 它比云浏览器服务多一个隐私优势:本地跑,URL 和内容不出你的机器;官方也把「不想让流量经过我们」列为选本地的第一理由。

我的判断

该上的三种人:

• 做数据采集、RAG 喂料、站点监控的,尤其是要跑在自己 1 GB、2 GB 小机器上的。单进程 27 MB 这个数字意味着你终于可以在小机器上开并发,而不是排队跑。
• 在 CI 里做功能性流程测试的(登录、下单、表单提交、断言 DOM 状态)。这类测试不要像素,只要行为和内容,正好落在它的强项上。
• 已经在用 Playwright 或 Puppeteer、想降本又不想重写脚本的。改一行连接地址就能试,试错成本几乎为零。

再等等的两种人:

• 流程里有任何一步依赖截图、视觉判断、鼠标坐标拖拽的。这不是配置问题,是它没有渲染引擎,等不来。
• 依赖冷门 Web API 或复杂前端框架的。先拿你最难的三个真实页面去跑,跑通了再谈迁移。

别碰的两种人:

• 需要「看起来像真人浏览器」的场景。它不渲染、不伪装,遇到按渲染结果或指纹判人的站点,行为和 Chrome 不一样是必然的。
• 要把浏览器内核嵌进闭源商业产品的团队。AGPL-3.0 是这里最硬的一道门,比性能重要。

一句话收口:Lightpanda 不是「更快的 Chrome」,它是「把浏览器里跟人有关的部分砍掉之后剩下的机器」。你要的东西如果本来就不需要给人看,它省钱省到离谱;你要的东西一旦需要人眼看,它一步都帮不上。

本文由拾光札记编辑部整理,勘误请联系我们