Playwright 与 Puppeteer 对比：基准测试、浏览器支持与选型

选择 Playwright 还是 Puppeteer，真正值得回答的问题是：哪个工具能让你的浏览器自动化工作更容易开发和维护。浏览器覆盖范围、编程语言、测试架构、状态隔离、现有代码，以及对 Chrome DevTools Protocol（CDP）的依赖，往往比几毫秒的速度差异更重要。

下文的基准测试记录涵盖五类受控工作负载。不同任务中的领先框架并不相同，差距也从几乎可以忽略到具有实际意义不等，因此无法得出一个普遍适用的性能冠军。下文列出完整测试方法、数值和适用边界，方便你判断这些任务是否接近自己的业务。

先看选型结论

对于需要跨浏览器自动化、多语言支持或集成端到端测试的新项目，Playwright 通常更适合作为起点。对于范围明确的 JavaScript 自动化、Chrome/CDP 工作，或者已经稳定运行的 Puppeteer 系统，Puppeteer 仍然合理，而且可能更简单。这是基于需求的工程建议，并不意味着某个框架在所有任务中都更快。

• 需要 Chromium、Firefox、WebKit，或使用 Python、Java、.NET，以及希望采用完整 E2E 测试体系时，优先考虑 Playwright。
• 以 JavaScript 为主、聚焦 Chrome/CDP、任务范围有限，或者已有 Puppeteer 代码时，优先评估继续使用 Puppeteer。
• 如果延迟或并发直接影响运营成本，就用自己的实际工作负载测试。

能力对比依据 2026 年 9 月 13 日查阅的 Playwright 语言文档、Playwright 浏览器文档和 Puppeteer 支持浏览器文档。

Playwright 与 Puppeteer 速览

这些工作负载测量的是自动化生命周期的不同部分，不应合并成一个总分。等待机制、隔离和代理配置的细节会在后面的专节展开。

2026 年的浏览器支持：不要再把 Puppeteer 当成 Chrome 专用工具

“Playwright 支持多浏览器，而 Puppeteer 只支持 Chrome”的旧说法已经不准确。Puppeteer 当前文档列出了 Chrome 和 Firefox。从 Puppeteer 23 开始，自动化 Chrome 默认使用 CDP，Firefox 默认使用 WebDriver BiDi；Chrome 也可以通过 BiDi 自动化。详见 Puppeteer 协议与跨浏览器 FAQ。

Playwright 的统一引擎覆盖范围仍然更广，包括 Chromium、Firefox 和 WebKit。今天更准确的区别是：前者覆盖更多浏览器引擎，后者是以 Chrome/CDP 为重要方向、同时支持 Firefox 的 JavaScript 库。需要第三种引擎时，WebKit 很有价值，但 Playwright 使用的经补丁修改的 WebKit 构建并不是品牌浏览器 Safari。Playwright 浏览器指南明确说明了这一点。

基准测试如何进行

测试来源与限制

下面的数值来自为本文提供的源稿 Puppeteer vs Playwright.docx 中记录的测试。本次发布没有重新运行这些测试，也不把它们描述为新完成的独立测量或厂商基准。原稿说明，数据来自一台机器上的一次正式测试会话；其中未提供测试日期、原始样本日志或可执行基准脚本，因此读者无法仅凭本文独立审计每一轮测试。

记录中的环境使用 Playwright 1.63.0 和 Puppeteer 25.10.0，在同一台机器上以无头模式运行，共用一个 Chromium 可执行文件和本地测试页面。解释结果时应保留这个范围：这些数值只描述该记录环境，不能代表所有版本或部署方式。

基准测试环境

记录中的测试把两套框架统一配置为 Playwright 安装的 Chromium 153.0.8010.12，以减少浏览器构建差异。这有助于比较该组任务，但不等于分别采用两套框架的默认浏览器组合。特别是，当前 Puppeteer 支持版本表为 Puppeteer 25.10.0 列出的对应版本是 Chrome for Testing 152.0.7977.75。因此，不应把实验中共用的 Chromium 说成 Puppeteer 默认支持的版本组合。

测试目标是通过 localhost 提供的确定性页面。外部网络波动和真实网站的响应行为大多被排除，所以这些数据不代表实际互联网网站的访问表现。

测试方法

根据测试记录，每套框架、每类工作负载先执行 5 次预热，再执行 30 次正式测量；成对运行时交替安排框架顺序。在适用情况下，两边保持相同的浏览器状态、页面加载条件、视口、截图设置与任务边界。

B01 并非只测进程启动，还包括启动浏览器、创建隔离上下文、创建页面、配置视口，以及等待测试页面就绪。B03 在两套框架中执行等价的 page.evaluate() DOM 操作，不比较不同定位器或填表方法的语义。B05 同时运行 4 个隔离浏览器上下文任务，并计入上下文销毁时间。只有了解这些边界，数值才有明确含义。

指标含义

中位数用来表示典型的一次运行。p95 按最近秩法计算，至少 95% 的记录样本不超过该值。由于每组只有 30 次正式测量，这里的 p95 更适合描述样本尾部表现，不应视为生产环境延迟的可靠估计。测试记录未报告显著性检验、跨任务总体平均值或总分。

基准测试结果

以下数值均以毫秒为单位，保留记录精度，不对小数进行额外舍入。

冷浏览器会话启动

在这项任务中，Playwright 中位数为 268.377 ms，Puppeteer 为 471.152 ms，前者约低 43%。两者 p95 分别为 279.088 ms 和 487.727 ms，方向一致。

在记录的机器和共用 Chromium 环境下，这个差异很明显。不过，计时包含上下文、页面、视口和本地测试页面准备，因此它反映的是完整会话启动时间，并非单纯的进程启动测量。

热态页面导航

浏览器已经启动后，Puppeteer 的中位数更低，为 19.241 ms；Playwright 为 22.779 ms。Puppeteer 的 p95 为 21.618 ms，Playwright 为 24.612 ms。

中位数只相差 3.538 ms。这说明 Puppeteer 在该受控导航任务中略有优势，但单凭它不足以成为重构自动化系统的理由。

DOM 交互

对于等价的页内 DOM 操作，Puppeteer 记录的中位数为 0.392 ms，p95 为 0.556 ms；Playwright 分别为 0.524 ms 和 0.816 ms。

两者中位数的绝对差仅为 0.132 ms。如果只用百分比描述，很容易夸大业务意义。对大多数实际应用而言，这个差距可以忽略。该测试也特意排除了定位器易用性和自动等待机制的比较。

截图性能

Playwright 的截图中位数为 17.652 ms，p95 为 19.890 ms；Puppeteer 分别为 20.653 ms 和 25.169 ms。中位数相差 3.001 ms，说明在固定视口、PNG 格式和相同测试页面状态下，Playwright 有适度优势。

四上下文并行任务

在这项具体任务中，Puppeteer 优势较明显：中位数为 340.274 ms，p95 为 369.083 ms；Playwright 分别为 407.748 ms 和 454.438 ms。中位数相差 67.474 ms。

该结果描述的是采用同一种生命周期与销毁方案的 4 个并发隔离任务。任务数量、页面内容、浏览器引擎、机器资源或会话复用策略变化后，结论都可能改变。

为什么不同工作负载会出现不同结果

观察到的总耗时由多种因素共同决定，包括框架行为、浏览器生命周期和构建、运行环境、API 语义、并发设计、网络条件及目标应用。冷会话更强调进程和状态初始化；热态导航排除了大部分启动工作；DOM 微基准偏重短协议往返；并行上下文则会增加调度和资源回收压力。

因此，相对差异和绝对差异应一起看。如果绝对差不到一毫秒，20–25% 的差距可能无关紧要；而反复发生的冷启动或高频任务中，60–100 ms 的差距可能更值得优化。这两个范围用于说明如何解读结果，并不是新增测试数据。微基准可以帮助定位问题，却不等于生产环境排名。

浏览器与语言支持

应按必须覆盖的引擎选型，而不是比较谁的功能列表更长。只运行 Chrome 的服务可能很少受益于 WebKit；明确需要第三种引擎的产品团队，则有充分理由考虑 Playwright。其浏览器文档还解释了为什么不能把品牌浏览器与配套引擎构建的行为视为完全相同。

Playwright 官方支持 JavaScript/TypeScript、Python、Java 和 .NET。当自动化必须接入现有非 JavaScript 技术栈时，这可能是直接决定选型的因素。官方语言指南也区分了不同语言的测试生态集成：Playwright Test 是 Node.js 的测试运行器，不能理解成每种语言都使用这一套运行器。

Puppeteer 的官方定位是以 Node.js 为中心的 JavaScript 库。社区移植项目不应被表述为官方 Python、Java 或 .NET 绑定。对于 JavaScript 团队，这个范围可能完全够用，也能让选择更简单。参见 Puppeteer 简介。

自动等待与定位器模型

Playwright 把可操作性检查放在交互流程的核心位置。根据动作类型，它会在执行前检查可见性、稳定性、能否接收事件及是否启用等条件，帮助减少测试中重复的同步等待代码。不同动作执行的检查并不完全相同，应以 Playwright 自动等待表为准。

Puppeteer 同样提供具有自动等待和操作前检查能力的定位器。对于相关交互，它会检查可见性、启用状态及元素边界框是否稳定。因此，“Puppeteer 没有自动等待”是不准确的说法。更值得比较的是在实际页面上的行为、错误诊断和与外围测试体系的配合。详见 Puppeteer 页面交互文档。

这项 DOM 微基准无法决定这种体验孰优孰劣，因为两边都使用了 page.evaluate()。选型时应另行验证应用真正需要的操作及页面状态。

浏览器上下文与并行执行

两套框架都能创建隔离的浏览器上下文。Playwright 将上下文隔离直接纳入测试模型，Puppeteer 则在库层面提供上下文创建能力。对应说明见 Playwright 隔离文档和 Puppeteer Browser.createBrowserContext。

记录中的四上下文测试更有利于 Puppeteer，但这并不否定 Playwright 在测试隔离方面的开发体验。运行性能和工程易用性回答的是两个问题：前者衡量指定任务的完成时间，后者影响团队能否稳妥地构建和维护测试套件。生产设计中应明确上下文数量、浏览器复用、销毁、重试和资源上限。

用于网页采集时怎么选

对于以 Node.js 为主、优先使用 Chrome、已有 CDP 相关代码且流程范围明确的采集服务，Puppeteer 很合适。如果多个浏览器引擎、非 JavaScript 语言或更广泛的测试需求影响团队如何维护服务，Playwright 会更有吸引力。

无论选择哪个框架，都不能保证生产吞吐量。真实采集任务可能主要受目标响应时间、网络延迟、代理质量、速率限制、会话策略及反自动化行为影响。本地测试页面排除了其中很多变量，因此不能直接把记录中的耗时套用到真实网站。应在获授权的目标上，使用实际部署、会话策略和允许的请求速率进行评估。

代理支持

代理能力并非 Playwright 独有。它的网络文档支持在整个浏览器或单个上下文中配置 HTTP(S) 与 SOCKSv5 代理。文档中的用户名和密码选项针对 HTTP(S) 代理，不能仅凭配置形式就推断所有代理认证方式都可用。

Puppeteer 当前的 BrowserContextOptions列出了 proxyServer 和 proxyBypassList，并指向 Page.authenticate() 处理用户名和密码。部署时仍应验证具体浏览器、代理协议及认证组合。

对于大量依赖代理的采集系统，更重要的往往是整体架构：代理池质量、轮换规则、认证、会话持久性、重试行为以及目标网站的限制。框架的配置接口只是其中一个组成部分。

用于端到端测试时怎么选

对于新建 Node.js E2E 测试套件，Playwright 通常更适合作为默认选项，因为 Playwright Test 将运行器、断言、隔离、并行执行，以及调试和报告工具组合在一起。多引擎支持也便于从一开始规划跨浏览器覆盖。Playwright 入门文档介绍了这一体化测试工具集。

Puppeteer 也能驱动端到端测试，并不是不能测试。团队可以把它与自己的运行器、断言库、报告和可观测性方案搭配使用。已有成熟技术栈时，这种灵活性很合理；从零开始时，则可能意味着更多基础设施需要组装和维护。决定是否迁移前，应先比较现有方案的真实维护成本。

Chrome DevTools 与底层自动化

Puppeteer 由 Chrome Browser Automation 团队维护，Chrome 默认使用 CDP。它的官方 FAQ也说明，在发展 WebDriver BiDi 的同时会继续支持 CDP。因此，对于 Chrome 特有自动化和已有 DevTools 相关代码，Puppeteer 是自然的候选方案。

Playwright 同样能够深入操作 Chromium。这里的优势在于项目定位和需求匹配，并不是说 Playwright 完全不具备相应能力。评估任何一方时，都要确认应用实际依赖的协议专有功能能够保留。

已有 Puppeteer 项目是否应该迁移

不应自动迁移。只有出现具体收益时才值得评估，例如必须支持 WebKit、自动化工作转交给 Python/Java/.NET 团队，或者自建 E2E 基础设施的维护成本已经高于采用 Playwright Test。这些变化可能足以抵消 API 改造和回归验证的成本。

如果当前系统运行正常，Chrome/CDP 仍是主要目标，测试运行器和可观测性也已解决，就有理由继续使用 Puppeteer。尤其当不同任务中的领先方向会变化时，一条基准测试标题更不足以支持迁移。决定重写前，先比较一个有代表性的流程，同时评估故障诊断和部署维护成本。

场景决策表

最终建议

对于没有特殊约束的新项目，Playwright 是合理的默认建议，因为它覆盖的浏览器、语言和测试场景更广。如果工作的核心是 JavaScript、Chrome/CDP、简单明确的任务，或者已积累了 Puppeteer 代码，Puppeteer 仍然是高效的选择。

测试结果说明，不能只凭一条性能标题选型：任务变化时，领先框架也会变化。选择能减少实际工程阻力的工具，并测量真正影响成本或可靠性的工作环节。

来源

基准数据与配图：提供的源稿 Puppeteer vs Playwright.docx。

以下第一方产品文档于 2026 年 9 月 13 日查阅。

• Browsers — Playwright 浏览器文档：支持引擎、浏览器构建差异，以及 WebKit 与品牌 Safari 的区别。
• Supported languages — Playwright 语言文档：官方语言与测试集成。
• Auto-waiting — Playwright 自动等待文档：不同动作的检查条件。
• Isolation — Playwright 隔离文档：浏览器上下文与测试隔离。
• Network — Playwright 网络文档：浏览器级与上下文级代理配置。
• Installation — Playwright 入门文档：Playwright Test 和一体化测试工具。
• Introduction — Puppeteer 简介：JavaScript 浏览器自动化库定位与入门入口。
• FAQ — Puppeteer 常见问题：维护团队、CDP、Firefox 和 WebDriver BiDi。
• Supported browsers — Puppeteer 浏览器文档：支持浏览器与版本配对。
• Page interactions — Puppeteer 页面交互文档：定位器行为与等待机制。
• Browser.createBrowserContext — Puppeteer 上下文 API：隔离上下文。
• BrowserContextOptions — Puppeteer 上下文选项：代理服务器、绕过列表与认证参考。