HTML前端性能测试关键在测什么、在哪测、如何排除干扰；浏览器原生API可覆盖80%诊断需求，如performance.getEntriesByType()获取真实加载链路，requestIdleCallback()检测主线程阻塞，requestAnimationFrame()分析帧率分布，强制重排测试需结合上下文，performance.mark()应使用带业务语义的统一命名。
HTML前端性能测试不是“跑个工具出个数字”就完事，关键在测什么、在哪测、怎么排除干扰。浏览器原生API就能覆盖80%日常诊断需求，不需要装一堆插件或压测平台。
用 performance.getEntriesByType() 看真实加载链路
这个 API 返回的是浏览器实际记录的资源加载、导航、paint 等事件，比 Network 面板更底层、更稳定。它不依赖 DevTools 是否打开，适合嵌入脚本做自动化采集。
-
performance.getEntriesByType('navigation')查首屏关键时间：重点关注domContentLoadedEventEnd和loadEventEnd，差值大说明 JS 执行阻塞严重 -
performance.getEntriesByType('resource')按initiatorType过滤，比如只看script或img，能快速定位慢资源是哪类文件拖垮了页面 - 注意：Chrome 中
performance.memory已被废弃，Firefox 不支持；别在生产环境依赖它判断内存泄漏
用 requestIdleCallback() 测主线程是否被长期霸占
很多卡顿不是因为 CPU 满载，而是 JS 任务没让出控制权。这个 API 的延迟值（callback 触发前等待的时间）就是最直接的证据。
- 执行
requestIdleCallback(() => console.log('idle'))后，如果延迟持续 >30ms，说明主线程有长任务（比如未拆分的 render loop 或同步 DOM 批量操作） - 滚动中立即执行该代码，若延迟突增至 >100ms，基本可断定存在 scroll handler 里做了重排（
offsetHeight、getComputedStyle）等高成本操作 - 不要用
setTimeout+performance.now()替代——它测的是事件循环延迟，不是空闲窗口，两者语义不同
用 requestAnimationFrame() 实时抓帧率，但别只看平均值
FPS 是渲染管线健康度的体温计，但平均 60fps 掩盖不了偶发的 5fps 卡顿。必须观察分布和抖动。
立即学习“前端免费学习笔记（深入）”；
- 运行标准采样脚本后，重点看连续低于 45fps 的帧数占比；若 >15%，用户已能感知卡顿
- 触发一次表单提交或弹窗后，立刻观察 FPS 是否掉到 20 以下并持续 >200ms——这是 layout thrashing 的典型信号
- 移动端 Safari 对
requestAnimationFrame调度更保守，同一段代码在 iOS 上帧率可能比 Chrome 低 10–15%，这不是 bug，是策略差异
强制重排（reflow）测试要带上下文，不能孤立执行
单纯读取 offsetHeight 并计时，结果毫无意义。重排代价取决于当前 DOM 状态和样式复杂度。
- 测试前先触发一次完整重绘：比如修改一个影响 layout 的 class，再等
requestAnimationFrame回调执行 - 然后批量读取多个布局属性（
offsetTop、offsetLeft、getBoundingClientRect()），观察耗时是否随元素深度/样式层数线性增长 - 在
will-change: transform生效的容器内执行同样操作，耗时应明显下降；否则说明 GPU 加速未真正启用
真正在意性能的人，不会等上线后才测。把 performance.mark() 埋点写进关键交互路径里，比任何事后分析都可靠——但前提是 mark 名字得统一、可检索，别用 'load-start' 这种模糊命名，换成 'cart-open-init' 这类带业务语义的标识。
