HTML监控不破坏性能分析，但错误实现会导致结果失真；关键在脚本加载时机（需内联于<head>首行）、事件监听类型（仅'paint'和'navigation'）、数据过滤（去重、弃用干扰项）、上报方式（sendBeacon）及避免DOM操作与console.log。
HTML监控本身不会破坏性能分析，但错误的实现方式会让性能分析结果失真甚至完全失效。 关键不在“加不加监控”，而在于监控脚本何时启动、监听什么事件、采集哪些数据、如何上报。
PerformanceObserver 必须在 <head> 最开头注册
如果把 PerformanceObserver 初始化逻辑放在 DOMContentLoaded 之后、或用 async 脚本加载，首屏关键时间点（如 first-contentful-paint、domInteractive）早已触发并错过。浏览器不会补发历史条目。
- 正确做法：内联一段 ≤1.5KB 的脚本，放在
<head>第一行，立即注册监听'paint'和'navigation'两类事件 - 错误典型：
setInterval(() => performance.getEntriesByType('navigation'), 100)—— 主线程轮询不仅漏数据，还强制触发垃圾回收（尤其在低端 Android） - iOS Safari 对
performance.measure()支持不稳定，打点建议统一用Date.now()
只上报 entryType === 'navigation' 和 'paint' 的条目
全量上报 performance.getEntries() 会混入大量干扰项：第三方字体加载、mark 打点、resource 条目（尤其 SPA 中频繁的路由资源请求），导致内存暴涨、上报体积激增、后端解析压力翻倍。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 必须过滤：只保留
entryType === 'navigation'（一次页面加载生命周期）和entryType === 'paint'（first-paint/first-contentful-paint） - SPA 场景需去重：检查
entry.initiatorType === 'navigation'，排除由fetch或XMLHttpRequest触发的伪 navigation 条目 - 废弃字段要兼容：
loadEventEnd在部分 Chromium 新版本中可能为0，应改用domContentLoadedEventEnd+loadEventStart推算
用 sendBeacon() 上报，禁用同步 XHR 和 DOM 操作
监控脚本自身就是资源，任何阻塞行为都会拖慢 HTML 解析流程。常见误操作包括：在监听回调里执行 document.querySelector、调用 console.log（DevTools 开启时序列化开销极大）、用 XMLHttpRequest 同步发送数据。
立即学习“前端免费学习笔记（深入）”；
- 上报必须用
navigator.sendBeacon()：异步、不阻塞卸载、保证送达 - 禁止在
observe回调中访问 DOM 或触发重排：所有数据应在entry到达时直接提取并缓存 - 避免
performance.memory：该 API 在部分浏览器中会强制 GC，显著拉高主线程耗时 - 低端设备可降级：检测
navigator.hardwareConcurrency < 2时，跳过longtask监听，只保 paint + navigation
最容易被忽略的是监控脚本自身的加载时机和体积控制——它不是“附加功能”，而是首屏性能链路上的第一环。一个没删的 console.log、一段晚注册 200ms 的 PerformanceObserver，就足以让 FCP 统计偏差 80ms 以上，且你根本不会在 Lighthouse 报告里看到这个原因。
