puppeteer 是目前最稳妥的 html 渲染评测方案，原生支持 setviewport 和 emulatenetworkconditions，能真实触发浏览器渲染逻辑；viewport 设置需配合 waitfornavigation 或元素等待确保生效，emulatenetworkconditions 仅限速请求不模拟 dns/tls，批量测试须为每个用例新建 page 并显式 close 避免内存泄漏。
如何用 Puppeteer 模拟不同网络与屏幕条件做 HTML 渲染评测
直接结论：Puppeteer 是目前最稳妥的方案，它原生支持 setViewport 和 emulateNetworkConditions，能真实触发浏览器渲染逻辑，比纯 CSS 媒体查询检测或服务端渲染模拟更可靠。
viewport 设置不生效？检查是否遗漏了 waitForNavigation
常见错误是调用 setViewport 后立即截图或取 DOM，但页面可能还在加载中，导致视口未真正应用。特别是 SPA 或带动态布局脚本的页面，setViewport 只改了浏览器窗口尺寸，不强制重排或重绘。
- 必须在
setViewport后等待导航完成或关键元素出现，例如：await page.waitForSelector('body')或await page.waitForNavigation({ waitUntil: 'networkidle0' }) - 如果页面用
window.innerWidth判断响应式逻辑，需确认 JS 执行时机——有些框架（如 Vue 3 的 SSR）会在 hydration 后才读取 viewport，此时需加await page.evaluate(() => new Promise(r => setTimeout(r, 100)))微延时 - 注意：移动端 UA 不影响 viewport 行为，但某些站点会根据 UA 加载不同资源，建议配合
setUserAgent一起设置
emulateNetworkConditions 为什么测不出首屏白屏？
这个 API 只限速/丢包/延迟网络请求，不模拟 DNS 查询、TCP 握手、TLS 协商等底层耗时，也不影响本地 HTML 解析和样式计算。所以即使设成 Slow 3G，若 HTML 文件本身小且内联关键 CSS，首屏仍可能瞬间渲染——这不是 bug，是设计如此。
- 真实瓶颈常在 JS 执行或字体加载，需额外注入监控：比如用
page.metrics()获取FirstMeaningfulPaint，或监听PerformanceObserver捕获largest-contentful-paint - 若要模拟 DNS/TLS 延迟，得用系统级工具（如
tc+iptables），Puppeteer 无权限干预 - 注意
offline模式下，Service Worker 缓存行为可能掩盖问题，建议启动时加--disable-background-networking参数禁用后台预加载
批量评测时，如何避免 Chrome 实例内存泄漏？
每个 page 实例不关闭会导致内存持续增长，尤其测试几十个组合（如 3 屏幕 × 4 网络条件 × 5 URL）时，很容易 OOM。
- 必须显式调用
await page.close()，不能只靠browser.close()—— 后者不保证所有 page 已释放 - 不要复用
page做多组测试：同一 page 切换 viewport/network 后，部分渲染状态（如 GPU texture、字体缓存）不会重置，导致结果偏差 - 推荐模式：每个测试用例新建
page→ 设置条件 → 执行 → 截图/采集指标 →close()→ 再循环；若性能敏感，可用browser.createIncognitoBrowserContext()隔离 cookie/cache，但 context 也要手动 close
真正难的是跨设备字体渲染差异和 subpixel antialiasing，这些连 Puppeteer 也模拟不了——得靠真机集群或云测平台。自动化能抓的，只是可编程的部分。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
