加监控需在最开头用performanceobserver监听paint和navigation事件，并用sendbeacon发送数据，控制脚本≤1.5kb、避免dom操作与同步xhr，低端设备可降级采集。
加监控本身会带来开销，但合理使用 PerformanceObserver 和 sendBeacon 几乎不拖慢首屏——关键在初始化时机和采集粒度。
为什么有些 HTML 监控会让页面变慢
常见错误是把监控逻辑塞进 DOMContentLoaded 或等 JS 加载完才启动，这时首屏关键指标（如 first-contentful-paint）已经错过；更糟的是用 setInterval 轮询 performance.getEntriesByType('navigation')，或在主线程频繁调用 performance.memory（部分浏览器该 API 会强制 GC）。
- 所有监听必须在
最开头执行，比如直接写<script>new PerformanceObserver(...).observe(...)</script> - 避免监听
longtask以外的非 paint/navigation 类型，resource或mark过多会显著增加内存分配压力 - iOS Safari 不支持
performance.measure()在某些上下文中触发，用Date.now()打点更稳妥
PerformanceObserver 必须监听的两类事件
只关注真实用户感知的“内容可见”和“导航完成”，其他都是干扰项。Lighthouse 和 CrUX 数据都基于这两类原始事件聚合而来。
-
paint：用于捕获first-paint和first-contentful-paint，必须在内注册，否则大概率漏掉 -
navigation：提供domContentLoadedEventEnd、loadEventEnd、nextHopProtocol等字段，可判断是否卡在 TLS 握手（对比connectEnd - secureConnectionStart）
如何避免监控数据污染性能指标
监控脚本自身就是资源，它会参与加载、解析、执行全流程。若放在 底部或用 async 加载，可能延迟 FCP；若内联但体积过大，又会拖长 HTML 解析时间。
- 监控代码控制在 1.5KB 以内，建议用 IIFE 包裹并移除 source map
- 不要在 observer 回调里做 DOM 操作或发同步 XHR；一律用
sendBeacon发送，确保卸载前送达 - 对低端设备（如 Android Go 或 iPhone 6s），可按
navigator.hardwareConcurrency 条件降级：只报 <code>FCP和TTFB，跳过longtask统计
真正难的不是加监控，而是让监控不成为性能瓶颈——它得比你监控的对象更轻、更早、更克制。很多团队上线后发现 FCP 变差了 80ms，最后定位到是监控脚本里一个没删的 console.log 触发了 DevTools 的序列化开销。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
