JavaScript监控长任务渲染耗时需用PerformanceObserver监听paint事件获取真实绘制时间，配合performance.now()在任务切分点打点测JS执行与DOM更新耗时，并用requestAnimationFrame检测丢帧，辅以Long Tasks API定位50ms+阻塞源。
在 JavaScript 中监控长任务拆分后每一帧的渲染耗时，核心是结合 PerformanceObserver 监听 layout-shift 和 paint，并用 requestIdleCallback 或 setTimeout(..., 0) 切分任务，再通过 performance.now() 手动打点测量关键阶段耗时。单纯依赖 FPS 或 requestAnimationFrame 回调无法准确反映“渲染耗时”，因为 rAF 触发时机在帧开始（通常 16ms 内），不等于浏览器实际完成样式计算、布局、绘制、合成的时间。
用 PerformanceObserver 捕获真实渲染事件
Chrome 92+ 支持监听 largest-contentful-paint、first-contentful-paint、layout-shift，但最直接的是 paint 类型，它会在浏览器完成绘制（包括主线程绘制和部分合成）后触发：
- 启用
PerformanceObserver监听paint，可捕获first-paint和first-contentful-paint等时间戳 - 配合
performance.getEntriesByType('paint')可回溯已发生的绘制事件 - 注意：paint 条目只记录绘制完成时间，不包含布局或样式计算耗时；如需更细粒度，需手动埋点
在任务切分点插入 performance.now() 打点
对长任务做微任务/宏任务拆分时，在关键节点（如每处理 1000 条数据、每次 DOM 批量更新前后）调用 performance.now() 记录时间戳：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 例如：在
setTimeout(() => { /* 处理一批 */ }, 0)的开头和结尾打点，差值即为该批次 JS 执行耗时 - 在
document.createElement批量插入前、el.append(...)后立即打点，可估算 DOM 更新引发的同步布局/重绘开销 - 避免在循环内高频打点（影响性能），按逻辑块聚合（如“渲染第 N 页列表”）
结合 requestAnimationFrame 验证帧是否丢弃
requestAnimationFrame 的回调执行时间可间接反映帧健康度：
立即学习“Java免费学习笔记（深入）”；
- 在每次任务切分后注册 rAF，回调中对比
performance.now()与上一帧时间差 - 若间隔 > 16.7ms（60fps），说明该帧可能被阻塞或丢帧；连续多次超时，表明任务切分粒度仍过大
- 示例：
const start = performance.now(); requestAnimationFrame(() => console.log('帧耗时:', performance.now() - start));
使用 Long Tasks API 定位阻塞源头
启用 PerformanceObserver 监听 longtask 类型，可捕获持续 ≥ 50ms 的主线程任务：
- 每个 longtask 条目含
startTime、duration、attribution（调用栈信息，需开启entryTypes: ['longtask']） - 结合你的任务切分逻辑，检查未被拆分的残留长任务（如遗漏的循环、未 defer 的初始化）
- 注意：该 API 在 Safari 中支持有限，建议降级为手动打点 + 时间阈值告警
