说实话，一提起“Playwright性能优化”，很多人第一反应是“这框架已经够快了，还要优化什么”。但真正用Playwright跑过几条完整业务流程的人，都体验过那种糟心：脚本单独跑明明6秒就跑完，塞进CI并行执行后却动不动15秒起步；本地十几分钟搞定的一套回归测试，放在高峰期要跑半小时。这些问题背后往往不是Playwright本身慢，而是使用姿势有问题。
我前前后后接手过好几个自动化测试项目，从几十条脚本的小型冒烟测试，到几千条用例的大型产品回归，Playwright的性能瓶颈和优化空间基本都摸过一遍。这篇文章就把我沉淀下来的经验做个系统性梳理——从等待策略、定位器选型、网络请求处理、上下文复用，到并行执行与报告裁剪，每一块都有具体的代码示例、参数解释，还有我踩过的坑。
如果你是刚把Playwright跑通的小白，这篇能帮你从一开始就避开低效写法；如果你是有维护经验的人，也能从“问题排查实录”里找到一些验证手段和调优思路。
1. 整体设计思路：性能优化不是堆技巧，而是算总账
1.1 先搞清楚“性能账本”从哪来
做优化之前，我习惯先画一张时间开销分布图。Playwright跑一条用例的时间，通常由这几部分构成：浏览器启动、页面加载与资源请求、等待策略耗时、定位器解析、用户动作执行、结果断言与截图。其中等待策略和资源请求这两项往往占掉70%以上的耗时，也是最容易优化的部分。这不是拍脑袋，我经常用performance.timing和Playwright自带的Trace Viewer给脚本计算关键耗时占比，发现真实瓶颈永远是那几个固定环节。
我把这类分析叫作“先量化再优化”。比如一条用例总计8秒，其中固定等待用了3秒，图片字体资源加载用了2.5秒，那你在定位器写法上抠破头皮都没有意义——第一刀应该砍向固定等待和网络资源。如果你跳过了量化的步骤，任由直觉去优化，大概率会把时间浪费在收益很低的地方。
1.2 优化目标永远是“稳定且快”，不是“数字跑得快”
做性能优化有一个很常见的误区：只看单条脚本的执行时间，把时间压下去就觉得万事大吉。但实际在测试框架里，“快”必须建立在“稳定”之上。随便举一个例子：为了减少等待，你把waitForLoadState('networkidle')去掉，脚本确实快了1秒，但后续点击按钮找不到元素，于是又临时加了几个waitForTimeout，一来一回不仅总耗时没降，脚本还变成了定时炸弹，隔三差五随机失败。
所以我做优化的第一原则是：几乎不对关键操作使用固定延时，全部换成状态等待或者Playwright内置的自动等待。这句话听起来简单，但真正做到位要考虑很多细节，后面我会展开讲。第二原则是：每个改动都至少在连续三到五轮CI上稳定跑过，再做下一个优化项。
1.3 别忽略“隐性乘法”：所有优化最终都要应对并行
单看一条用例的时间，“省100毫秒”感知不强。但同样的优化放到10条并行、50条并行里，时间收益是乘法级别的。这也是为什么我在设计优化方案时，总会额外问一句：这条优化在并发场景下还成立吗？比如上下文复用能减少多少浏览器启动开销？资源拦截在并行时是不是能缓解带宽瓶颈？这些思路决定了优化策略是“局部调优”还是“全局增效”。
2. 等待与定位器：最常被滥用也最值得深挖的两块硬骨头
2.1 等待策略选型：状态等待优先于固定延时
我在评审项目脚本时，最先扫的就是waitForTimeout出现的次数。老实说，每次看到脚本里有大量固定延时，我就知道这个脚本后续维护成本低不了。固定延时的最大问题是它完全不感知页面真实状态——网络慢时你等的时间不够，网络快时你又白等。Machine式的思考方式是：等待某个元素可见、等待某个请求完成、等待某个文本出现，这些才是页面真正愿意告诉你的状态信号。
Playwright对等待的内置支持其实非常完善，很多时候你根本不需要主动编写等待代码。比如click()、fill()、press()这些动作本身带有Actionability检查——元素必须先可见、稳定而且可接收操作，Playwright才执行下一步。所以新手最容易犯的错是“不信任框架”自己补了几秒等待，结果反而拖慢脚本并增加不确定性。
只有需要等某个异步副作用完成但后续又没有明确动作元素时，我才会显式使用等待API。比如表单提交后出现一个“保存成功”的提示，我会用await expect(page.getByText('保存成功')).toBeVisible()而不是await page.waitForTimeout(2000)，因为expect自带重试机制，等提示出现就立刻继续，提示不出现时也能捕获真实异常。
2.2 定位器：别在性能上反复摩擦DOM
定位器看似和性能无关，但选错定位器会让每次交互都付出不必要的解析成本。我遵循的优先级是：getByRole、getByLabel、getByText、getByTestId这类语义定位器 > 稳定的CSS选择器 > 极简的XPath。语义定位器不仅可读性好，而且Playwright对它们做了引擎级优化，解析成本低于你手动拼接的复杂选择器。
很多人写定位器喜欢把一层层的层级全部写出来，比如#app > div.container > div.row:nth-child(3) > button.submit。这种写法一旦DOM结构有一丁点调整就会挂掉，而且每次解析都要全路径匹配一轮。我一般只写能定位到目标的最短可靠路径，比如.submit-btn，或者干脆用page.getByRole('button', { name: '提交' })。这里有个重要的经验：定位器“短”不等于“脆”，很多从业者有过一个认知误区，觉得用各种索引和位置关系能把选择器做得更精准可靠。实际上位置关系恰恰是最易碎的选择，你真正需要的是稳定属性 + 语义角色。
如果项目里有条件，我会在每个高频交互元素上统一加>
