在Playwright/Puppeteer中检测FPS下降及环境模拟是否适用于性能测试？

一、FPS计数器作为性能预警的有效性 #

这种方式是有效的性能预警手段，但需结合场景合理使用：

• 核心优势：直接关联用户实际体验（掉帧、卡顿），能捕捉渲染线程的性能瓶颈，比单纯的静态跑分更贴近真实交互场景
• 局限性：
  • 仅能检测渲染层面的掉帧问题，无法覆盖JS主线程阻塞、网络请求缓慢等间接导致卡顿的根源，需配合Long Tasks、LCP等性能指标共同判断
  • 测试环境的性能波动会影响结果，必须保证测试环境的一致性

优化后的FPS计数器代码 #

你提供的代码存在判断条件写反的问题，同时需要将异常传递到测试框架中，以下是调整后的实现：

// Options
const decimalPlaces    = 2;
const updateEachSecond = 1;
const fpsThreshold = 60; // 设定预警阈值

// Cache values
const decimalPlacesRatio = Math.pow(10, decimalPlaces);
let timeMeasurements     = [];

// Final output
let fps = 0;

const tick = function() {
  timeMeasurements.push(performance.now());

  const msPassed = timeMeasurements[timeMeasurements.length - 1] - timeMeasurements[0];

  if (msPassed >= updateEachSecond * 1000) {
    fps = Math.round(timeMeasurements.length / msPassed * 1000 * decimalPlacesRatio) / decimalPlacesRatio;
    timeMeasurements = [];
    
    // FPS低于阈值时抛出错误，通知测试框架
    if (fps < fpsThreshold) {
      throw new Error(`FPS预警：当前${fps}fps，低于阈值${fpsThreshold}fps`);
    }
  }

  requestAnimationFrame(tick);
}

tick();

在测试框架中捕获异常 #

以Playwright为例，可通过监听页面错误实现测试失败触发：

await page.goto('目标页面URL');
// 注入FPS计数器代码
await page.addScriptTag({ content: fs.readFileSync('./fps-counter.js', 'utf8') });
// 监听页面错误，触发测试失败
page.on('pageerror', (error) => {
  if (error.message.includes('FPS预警')) {
    throw new Error(`性能测试不通过：${error.message}`);
  }
});
// 执行核心交互操作（如滚动、弹窗触发）
await page.mouse.wheel(0, 2000);

二、让测试环境贴近真实用户设备 #

Netlify/Vercel等构建环境的性能远强于5年前的安卓设备，直接测试无法模拟真实用户的卡顿场景，必须添加节流机制：

• CPU节流：模拟低端设备的计算能力，Playwright和Puppeteer均支持：

  // Playwright
  await page.context().throttle({ cpuSlowdownMultiplier: 4 }); // 4倍CPU减速，对应中低端移动设备
  
  // Puppeteer
  await page.emulateCPUThrottling(4);
  

• 网络节流：配合慢网络模拟（如3G），覆盖资源加载对渲染的影响：

  // Playwright
  await page.context().throttle({
    downloadThroughput: 750 * 1024, // 3G下载速度
    uploadThroughput: 250 * 1024,
    latency: 150 // 延迟150ms
  });
  

• 设备模拟：直接匹配目标设备的硬件参数，Playwright内置常见设备列表：

  const { chromium, devices } = require('playwright');
  const browser = await chromium.launch();
  const context = await browser.newContext({
    ...devices['Pixel 3'], // 模拟5年前的安卓设备
    cpuSlowdownMultiplier: 4
  });
  

• 内存限制：通过启动参数强制限制浏览器内存，模拟低端设备的资源瓶颈：

  const browser = await chromium.launch({
    args: ['--js-flags=--max-old-space-size=512'] // 限制内存为512MB
  });
  

三、总结 #

结合FPS计数器+环境节流的方案，能在部署前有效发现界面渲染卡顿问题，建议：

1. 将FPS测试整合到核心交互场景的E2E测试流程中
2. 不要单独依赖FPS指标，配合Long Tasks、LCP等形成完整的性能检测体系
3. 定期根据目标用户设备的性能数据调整节流参数，保证测试的准确性

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