做UI自动化的同学大概都有这种体验功能逻辑不复杂case也不多但一跑就是二十分钟起步。打开报告一看单条case没几个断言耗时却全花在页面加载、固定等待、重复登录、资源下载这些“看不见的角落”里。Playwright本身已经是同类工具里比较快的那一档但快不快是相对的真正拖垮测试时间的往往是我们的用法不对比如盲目用sleep、全程开着trace、每个用例都重新登录一遍、一个case里串行了十几个页面操作还不开并发。这篇内容我整理了10个在真实项目中验证过、能明显缩短Playwright测试时间的技巧。每条都会讲清楚原理、给到可直接复制的代码再补上我踩过的坑。适合已经把Playwright跑起来、但觉得回归时间越来越难接受的团队也适合准备搭新框架、想从第一天就把性能底座打好的同学。放心没有什么玄学调优全是能落地的东西。1. 先搞清楚Playwright 慢在哪聊优化之前得先给Playwright“验个伤”。我见过不少团队一上来就开--workers16结果机器直接卡死case互相抢资源跑完比单线程还慢。所以先花30秒弄明白时间都去哪了再动手改远比盲目套技巧有效。1.1 慢的根源往往不在 Playwright 本身Playwright的底层通信走的CDP协议每个操作都经过浏览器响应这层开销是固定的。真正能优化的通常是几类问题等待策略太差代码里大量time.sleep(3)、waitForTimeout(5000)不管页面是否就绪硬等。浏览器上下文重复创建每条case都从零启动context再从零加载登录页、走登录流程一次三五秒十次就是半分钟。页面“减重”不够被测应用往往带了一堆统计脚本、广告SDK、字体文件、埋点请求这些和断言无关却全被当成了页面加载的一部分。串行执行默认单worker跑完全部case明明机器有16个核只用了1个。录制和追踪默认全开trace、截图、视频在本地调试时有价值在CI里就是纯开销。判断依据很简单跑一次完整回归打开trace的Timeline看每个operation的耗时再用page.on(request)打印所有请求看看有多少请求和业务逻辑无关。做完这两个动作优化方向基本就清晰了。1.2 性能优化的三条主线不管是什么类型的项目Playwright优化本质上就三件事减少工作量不加载的资源不加载不走的流程不走不做的事不做。减少等待等真正的条件不硬等时间。增加并行度让CPU、内存、带宽都动起来。下面10个技巧就是这三条主线在具体场景里的展开。我会按“启动与上下文 → 等待策略 → 网络资源 → 并发分发 → 录制开销”的顺序来写每条都能独立使用但合在一起效果最好。2. 减少启动与上下文开销省下第一个大头Playwright的性能优化我最先动的永远是“上下文创建”和“登录流程”。很多项目里这两块能吃掉整体时间的30%以上。2.1 技巧1重用一个 BrowserContext别每次新开browser.new_context()本身不贵但每次新context都意味着一个全新的、没有任何cookie和localStorage的浏览器环境。如果case需要登录态那你等于每次都从零开始走一遍登录。这在测试场景里往往是纯浪费。正确做法是把相同登录态、相同配置的case放进同一个context里。以Pythonpytest为例import pytest from playwright.sync_api import sync_playwright pytest.fixture(scopesession) def browser(): with sync_playwright() as p: browser p.chromium.launch(headlessTrue) yield browser browser.close() pytest.fixture(scopesession) def context(browser): # 所有case共用一个contextcookie、localStorage都在 ctx browser.new_context(viewport{width: 1920, height: 1080}) yield ctx ctx.close()单个case用context.new_page()去拿页面而不是每个case都重新创建context。这样登录只做一次页面状态可以共享。注意共享context有个天然代价case之间隔离性会变差。如果你有case会清cookie或者改登录态那就不适合全局共享这时候用技巧2更稳。2.2 技巧2用 storageState 跳过登录而不是每次走 UI比起共享context我更推荐的做法是用storageState。核心思路是把登录成功后的cookie和localStorage保存成一个json文件后续所有context直接加载这个状态秒开。先跑一次登录并保存状态from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch() context browser.new_context() page context.new_page() page.goto(https://your-app.com/login) page.get_by_label(用户名).fill(test_user) page.get_by_label(密码).fill(test_pass) page.get_by_role(button, name登录).click() page.wait_for_url(**/dashboard) # 保存整个上下文的存储状态 context.storage_state(pathstate.json) browser.close()之后每条case都这样创建contextcontext browser.new_context(storage_statestate.json)这里有几个注意点storage_state保存的是cookie、localStorage、indexedDB里的内容不是用户密码。所以即使文件泄露也不等于账号泄露前提是服务端做过基本安全处理。如果被测系统有token过期机制要定期重新生成state.json我习惯在CI里用专门的setup job生成再传给执行job。对多套用户角色比如管理员、普通用户、只读用户分别保存admin_state.json、user_state.json根据case需要加载。个人实测一个原本要3秒完成的登录流程用storageState之后直接变成0秒。一个200条case的回归套件光登录就能省10分钟以上。3. 把等待策略收紧消灭隐含的等待等待是UI自动化里最大的时间黑洞。Playwright的自动等待机制已经很聪明了但很多从Selenium转过来的人还保留着“sleep一下再说”的肌肉记忆这习惯必须戒掉。3.1 技巧3按需设置 waitUntil别总用 loadpage.goto()默认会等load事件也就是页面里所有资源——包括图片、广告、统计脚本——全部加载完才算数。但很多时候我们的断言根本不依赖这些东西。你完全可以告诉Playwright“我只关心DOM结构不关心外部资源”# 只等HTML解析完成不等图片和广告 page.goto(https://your-app.com/list, wait_untildomcontentloaded) # 更激进只要导航确认就往下走 page.goto(https://your-app.com/list, wait_untilcommit)对于列表页、详情页这类页面从load降级到domcontentloaded通常能省0.5到2秒。不过要小心如果页面的核心内容是通过异步请求渲染的光等domcontentloaded不行你得配合断言等待见技巧4。我的习惯是首屏内容用domcontentloaded断言等待不要用load更不要用commitcommit只代表导航被提交DOM都未必渲染好。3.2 技巧4让 Playwright 自动等待删掉所有 sleep这是我想强调最多的一条。Playwright的定位器、断言、点击操作都内置了自动等待点击前会等元素可操作断言会等条件成立默认超时30秒。这套机制已经帮你把“等待”这件事做完了你再额外加sleep反而会拉长测试时间。反面教材# 错误 page.goto(https://your-app.com/login) page.wait_for_timeout(3000) # 固定等3秒 page.fill(#username, test_user)正确写法# 正确直接让Playwright等“用户名输入框可操作” page.goto(https://your-app.com/login) page.get_by_label(用户名).fill(test_user)如果某个异步操作需要等结果用断言等条件from playwright.sync_api import expect page.get_by_role(button, name提交).click() # 等结果出现最多10秒出现即返回 expect(page.get_by_text(操作成功)).to_be_visible(timeout10000)这样做的好处是“条件满足就立刻往下走”页面1秒就绪就1秒通过页面5秒就绪就5秒通过而不是不管快慢都硬等3秒。把代码里所有wait_for_timeout和sleep清理一遍是性价比极高的一步。3.3 技巧5精准调控超时时间别让失败拖到30秒Playwright的默认超时是30秒这是兜底值不是目标值。如果一个断言在10秒内没满足基本就是bug了没必要让它硬抗满30秒才报错。全局调低超时能让失败快速暴露也变相压缩了异常case的拖尾时间。在配置文件里设置# pytest playwright-pytest def pytest_configure(config): config.option.timeout 15000 # 每个操作15秒超时如果用的是Playwright Test Runner直接在配置里写// playwright.config.js module.exports { timeout: 15000, use: { actionTimeout: 10000, navigationTimeout: 15000, }, };actionTimeout控制单个动作点击、填表的超时navigationTimeout控制导航超时二者分开调往往比一刀切更精准。某些确实慢的接口比如报表导出再单独用locator的.click(timeout20000)做局部放宽避免为了少数慢case拖垮整体。4. 网络层做减法把页面“减重”UI自动化跑的是真实浏览器页面加载多少资源测试就得等多少资源。但很多资源对测试结果毫无意义。这部分的优化空间经常被人忽略。4.1 技巧6拦截并干掉无用的第三方请求常见的无用请求统计脚本、广告SDK、埋点上报、字体文件、社交媒体组件、在线客服脚本。这些请求不仅拖慢页面加载还可能在CI环境里因为网络不通而导致各种奇怪的超时。统一拦截BLOCKED_DOMAINS [ google-analytics.com, googletagmanager.com, doubleclick.net, facebook.net, hotjar.com, sentry.io, ] def block_unwanted(route): url route.request.url if any(domain in url for domain in BLOCKED_DOMAINS): route.abort() else: route.continue_() page.route(**/*, block_unwanted)在启动context后、导航前统一调用一次即可。我做过一个测试一个重营销页面的加载时间从6.8秒降到2.1秒全靠拦掉了将近40个第三方请求。还有一类更极端的操作直接拒绝图片、字体、媒体资源只保留文档和接口def block_heavy_resources(route): req route.request if req.resource_type in [image, font, media]: route.abort() else: route.continue_()注意如果页面里的某些元素是因为背景图加载完才出现那屏蔽图片可能导致元素状态判断异常。建议先跑一轮看哪些资源真的会影响断言再决定屏蔽清单。4.2 技巧7用 route.fulfill 给接口打桩告别等待真实接口在测试“前端交互逻辑”时你其实不关心后端返回的真实数据是什么只需要一个稳定的、快速返回的mock数据。用route.fulfill可以直接拦截请求并立刻返回预设内容比让测试去等真实接口可能很慢甚至不稳定要快得多也稳定得多。def mock_orders(route): if api/orders in route.request.url: route.fulfill( status200, content_typeapplication/json, body{code: 0, data: [{id: 1, status: paid}]}, ) else: route.continue_() page.route(**/api/orders, mock_orders)这里有个经验只mock测试用例真正依赖的接口不要一股脑全mock。否则本来该暴露出来的后端问题会被mock掩盖测了个寂寞。我通常的划分是——用例验证前端逻辑时mock慢接口涉及端到端链路完整性的case保留真实接口。5. 并发与分发用空间换时间单case优化做到位之后下一步就是横向扩展。Playwright设计上天生适合并行利用好了十几分钟的回归能压缩到两分钟。5.1 技巧8用 pytest-xdist 并行跑起来Python生态用pytest跑Playwright的话并行方案最常用的是pytest-xdist。安装依赖pip install pytest-xdist运行# -n auto根据CPU核数自动决定worker数量 pytest tests/ -n auto # 也可以手动指定 pytest tests/ -n 4有几个细节需要处理好如果每条case都用pagefixture并行时多个worker会各自管理自己的浏览器实例。要确保机器内存够一个Chromium实例大概占200-500MB内存同时跑8个worker需要预留4GB左右。case之间不能有共享文件写冲突。比如多个case同时往一个日志文件里写就会互相污染。如果有pytest.fixture(scopesession)的context注意-n模式下session级fixture会在每个worker里各执行一次不是全局共享。另一个值得提的是--dist loadscope参数。它让同一个测试类或同一个模块的case尽量分到同一个worker里执行。如果你的case依赖某个模块级别的共享资源这个参数能避免不同模块互相干扰。5.2 技巧9CI 上按浏览器分片sharding在本地跑pytest-xdist已经够用。到了CI里如果矩阵配置得当可以把整个测试集切分到多个并行机器上这才是终极提速手段。Playwright Test Runner原生支持分片# 第1台机器跑前1/4 npx playwright test --shard1/4 # 第2台机器跑第2个1/4 npx playwright test --shard2/4配合GitHub Actions的矩阵策略strategy: matrix: shard: [1, 2, 3, 4] steps: - run: npx playwright test --shard${{ matrix.shard }}/4如果是pytest-xdist虽然内置分片支持弱一些但可以用--collect-only配合awk把用例列表切分或者直接用pytest --dist loadgroup加pytest.mark.group手动分组。分片时要注意每台机器都要有完整的浏览器依赖Playwright的install --with-deps以及各自的state.json等测试数据。分片粒度建议按业务模块切而不是按字母硬切不然稳定性数据不在一个维度上不好分析。6. 收尾阶段别让“记录”拖慢整体很多人把trace、视频、截图称为“Playwright的隐形杀手”。这些功能确实好用调试效率神器但在回归环境里全部默认开启CPU和磁盘都受不了。6.1 技巧10按需开 trace / video默认关掉Trace记录每一次操作、网络请求、快照和控制台日志对定位问题极其有用但它的文件体积大写入也消耗时间。视频录制更夸张每条case动辄几十MB。正确姿势是“只在失败时记录平时关闭”// playwright.config.js module.exports { use: { trace: retain-on-failure, video: retain-on-failure, screenshot: only-on-failure, }, };在本地调试时用命令行临时开启npx playwright test --trace on如果调试已经稳定的case再关掉恢复速度。pytest-playwright的用法类似在命令行指定pytest --tracingretain-on-failure pytest --videoretain-on-failure提醒一下retain-on-failure模式下会先正常跑case失败时才会保存trace。但录制器本身还是在背后一直采集数据的只是最终没落盘。如果连采集开销都想省测试环境可以用--tracingoff。我的做法是本地调试开着CI里只保留失败trace稳定后把retain-on-failure改成off等发现问题再临时打开。6.2 补充技巧禁用动画与资源加载压掉最后一点空闲很多前端框架Ant Design、Element、Bootstrap都有过渡动画。动画本身耗时不多但在自动等待模式下动画期间元素可能被判定为“不稳定”或“不可见”Playwright会多等一小段时间。用一段样式注入把所有动画和过渡直接关掉既提速又减少flakypage.add_style_tag(content *, *::before, *::after { transition: none !important; animation: none !important; caret-color: transparent !important; } )把这个操作放在context创建后立即执行所有页面都会自动套用。实测中表格递增行、弹窗淡入淡出这些场景的稳定性提升很明显。另外如果页面有轮询接口比如每3秒刷新一次订单状态测试过程中这种轮询会让“等结果”的判定出现竞态。可以用page.route把轮询接口的响应拉到很长或者配合mock固定返回避免时间在轮询上打转。7. 常见问题与排查实录这条不算是第11个技巧但都是我在实际项目里踩过、也帮人排查过的典型问题值得单独记一笔。7.1 问题1加了并行还是慢甚至更慢症状-n auto跑起来整体时间反而比串行还长。原因基本都是机器资源不足。8核CPU、8GB内存的机器开8个worker每个worker一个Chromium一跑起来内存就满了系统开始疯狂swap浏览器之间互相抢CPU结果每个case都变慢。排查办法跑之前用free -h看内存nproc看核数。经验值一个worker至少占用1个CPU核心和500MB空闲内存。宁可用-n 4跑得稳也别-n auto一把梭把机器打爆。另一个容易踩的点是启动命令带了--headed有头模式。在CI里千万别开有头模式一个headed的Chromium窗口本身没问题但并行时多个窗口争抢X server资源慢得离谱。7.2 问题2等待元素一直超时不是Timeout太小是定位器本身太弱症状把超时从10秒调成30秒case还是失败时间全耗在等。原因往往不是元素出现慢而是定位器选择器写得太弱。常见的是page.locator(div.container div.row div:nth-child(2) button)这种容易选到多个元素的XPath或者依赖text但页面上有多个相同文本。排查办法打开--debug模式看locator实际命中了几个元素。更规范的写法是用get_by_role、get_by_label、get_by_test_id这些选择器更贴近用户视角命中唯一性也更高。# 弱 page.click(div.form-btns button) # 强 page.get_by_role(button, name提交, exactTrue).click()7.3 问题3页面懒加载滚动才出数据怎么等都白等症状断言列表有N行数据但页面只渲染了首屏Playwright等很久也不出现在视觉区超时报错。原因是被测页面用了无限滚动或“滚动加载更多”模式可视区外的内容根本没渲染。排查思路分两类如果你要测懒加载本身那必须用locator.scroll_into_view_if_needed()或mouse.wheel滚动到目标元素附近再触发加载、做断言如果你只是测试列表页的筛选功能没必要等全部懒加载内容渲染完建议改断言方式只断言前几条结果是否符合预期别等“全部数据”这个永远等不完的条件。7.4 调优后的效果参考我自己维护过一套电商后台的Playwright回归大概220条case优化前后对比优化项优化前优化后登录方式每条case UI登录storageState复用等待策略多处sleep(2-3秒)全部改为自动等待页面加载默认loaddomcontentloaded 断言等待第三方资源全部加载拦截统计/广告/字体执行方式单worker串行4 worker并行trace/video全部开启仅失败保留总耗时从46分钟降到8分钟左右。整个优化花了一个下午没有改任何业务断言逻辑纯粹是“少做无用功”。我个人在实际操作中的体会是Playwright的性能优化不是一条条技巧单独生效而是一个组合拳先把等待策略和登录流程改掉就能看到肉眼可见的提速再把网络拦截和并行加上去体感就是“测试从晚上跑变成了随时跑”。如果你的回归还长时间在10分钟以上建议按这个顺序逐条排查每一条的收益都能量化也方便日后跟团队展示投入产出。