Playwright端到端测试性能低下（CPU占用过高）排查求助

一、排查测试耗时久、CPU占用过高的原因 #

• 启用全量性能追踪：将Playwright配置中的trace: 'on-first-retry'改为trace: 'on'，测试完成后打开生成的HTML报告，重点查看网络请求时序、页面渲染阶段的CPU占用、WebGL资源加载/编译耗时，定位3D地图相关资源的瓶颈点。
• 统一浏览器启动参数：桌面Chrome默认启用GPU加速且无后台节流，Playwright启动的Chromium需补充参数强化性能：

  launchOptions: {
    args: [
      '--use-gl=desktop',
      '--enable-webgl',
      '--ignore-gpu-blocklist',
      '--disable-background-timer-throttling', // 禁止后台定时器节流
      '--disable-renderer-backgrounding', // 禁止渲染进程后台化
      '--disable-dev-shm-usage' // 避免共享内存不足导致的性能下降
    ],
  }
  

• 优化页面等待逻辑：page.goto(url)默认等待load事件（所有资源加载完成），而桌面Chrome的“加载完成”可能仅指DOM就绪。可改为：

  await page.goto(url, { waitUntil: 'domcontentloaded' });
  await expect(page.getByTestId('tableToggleStack')).toBeVisible();
  

  对比耗时变化，判断是否是3D资源的加载/渲染拖慢了测试。
• 移除冗余认证步骤：配置中已通过storageState注入认证状态，测试代码中手动添加cookies属于重复操作，直接删除该段代码，减少资源消耗。
• 区分资源占用主体：测试时打开系统任务管理器，观察是Playwright的浏览器进程还是本地Docker服务CPU占用过高。若为Docker服务，检查容器的资源限制（如是否给足CPU、内存）。

二、解决并行测试性能更差的问题 #

• 合理设置worker数量：根据本地CPU核心数手动指定，比如4核CPU设workers: 2，避免进程过多抢占资源。
• 调整并行策略：fullyParallel: true会让所有测试（包括setup项目）同时启动，改为：

  fullyParallel: false,
  projects: [
    { name: 'setup_auth', testMatch: /auth\.setup\.ts/, fullyParallel: false },
    { name: 'setup_project', testMatch: /project\.setup\.ts/, fullyParallel: false, dependencies: ['setup_auth'] },
    // 测试项目可开启并行
    { name: 'chromium', fullyParallel: true, dependencies: ['setup_project'] }
  ]
  

  保证setup流程串行执行，避免资源冲突。
• 复用浏览器上下文：在setup项目中创建上下文并传递给测试，减少重复启动浏览器的开销：

  // setup_project.ts
  test('setup project', async ({ browser }) => {
    const context = await browser.newContext({ storageState: 'frontendTests/.auth/user.json' });
    await context.storageState({ path: 'frontendTests/.auth/project-ready.json' });
    await context.close();
  });
  

  然后在测试项目中复用该状态：

  {
    name: 'chromium',
    use: {
      ...devices['Desktop Chrome'],
      storageState: 'frontendTests/.auth/project-ready.json',
      // ...其他配置
    },
    dependencies: ['setup_project'],
  }
  

• 强化服务端资源：若本地Docker服务是瓶颈，启动容器时增加资源分配，例如：

  docker run --cpus=4 --memory=8g ...
  

三、Chromium与Firefox的速度差异是否正常 #

这种差异是正常的，核心原因包括：

• WebGL渲染优化差异：Chromium的Blink引擎在3D场景的纹理加载、Shader编译、GPU调度上的优化比Firefox的Gecko引擎更成熟，复杂3D地图场景下性能差距会被放大。
• 自动化接口效率：Playwright对Chromium的底层支持更深度，进程间通信开销更低；Firefox依赖Marionette接口，在资源加载钩子、进程调度上的额外开销更大。
• 沙箱机制差异：两者的沙箱实现逻辑不同，Chromium的沙箱对渲染进程的资源限制更灵活，Firefox的安全检查在部分场景下会增加CPU消耗。

如果纯静态页面的测试速度差异不大，说明当前的性能差距主要由3D地图的渲染引擎差异导致。

内容的提问来源于stack exchange，提问作者pcace