HTML5 Performance API在CI中应只监控paint和navigation两类entryType，用内联IIFE脚本早注册、sendBeacon上报，并通过多点采样与浮动阈值判定性能退化。
在持续集成（CI）中接入 HTML5 Performance API，核心目标不是“采集全量数据”，而是稳定捕获关键首屏指标，并与历史基线比对，及时发现性能退化。它不替代后端 APM 或合成监控，但能填补真实用户侧首屏体验的空白。
只监控两类 entryType：paint 和 navigation
CI 环境通常使用无头浏览器（如 Puppeteer、Playwright）加载页面，这类环境支持完整的 Performance Timeline，但资源条目（resource）极易因缓存、预加载、Service Worker 干扰而失真。因此应严格限定监听类型：
-
paint：用于提取
first-paint（FP）和first-contentful-paint（FCP），这两个时间点在 CI 中可稳定复现，且直接反映视觉加载进度 -
navigation：用于获取
domContentLoadedEventEnd和loadEventEnd，它们反映 DOM 构建与资源加载完成节点，是判断 JS 执行阻塞的关键依据 - 禁用
resource、longtask等监听——CI 脚本本身轻量，无需诊断运行时卡顿；且 resource 条目数量随页面资源增长而激增，易导致内存溢出或上报超时
脚本必须内联注册，且早于任何 HTML 解析
CI 流程中若通过外部 script 标签或 async 加载监控逻辑，会错过 navigation 和 paint 的首次触发。正确做法是在 HTML 模板的 最顶部插入一段 ≤1.5KB 的 IIFE：
<script>
(function() {
if ('PerformanceObserver' in window) {
const obs = new PerformanceObserver((list) => {
list.getEntries().forEach(entry => {
if (entry.entryType === 'paint') {
// 上报 FP/FCP
} else if (entry.entryType === 'navigation' && entry.initiatorType === 'navigation') {
// 上报 domContentLoadedEventEnd / loadEventEnd
}
});
});
obs.observe({ entryTypes: ['paint', 'navigation'] });
}
})();
</script>
该脚本不依赖 DOM，不触发重排，且确保在 navigationStart 后立即生效。
立即学习“前端免费学习笔记（深入）”；
用 sendBeacon 上报，不依赖页面生命周期
CI 场景下页面常被快速销毁（如 Puppeteer.close()），传统 fetch 或 XMLHttpRequest 可能中断。必须使用 navigator.sendBeacon() 发送结构化日志：
- 上报内容至少包含：
url、fp、fcp、domContentLoadedEventEnd、loadEventEnd、timestamp（CI 构建 ID 或 commit hash） - 避免在回调中调用
document.querySelector或getBoundingClientRect——这些操作在无头环境中可能抛错，也会拖慢 CI 执行速度 - 禁用
console.log和performance.memory：前者在 DevTools 启用时引发序列化开销，后者在部分 Chromium 版本中强制 GC，显著抬高主线程耗时
回归判定逻辑要结合误差容忍与多点采样
单次 CI 测量存在波动（网络抖动、CPU 抢占、JS JIT 编译差异）。建议：
- 每轮 CI 对同一 URL 进行 3–5 次独立加载，取 FCP 的中位数作为本次结果
- 设定浮动阈值：例如 FCP 基线为 820ms，则允许 ±5%（±41ms）波动；超出即标记为“疑似退化”
- 连续两轮 CI 超出阈值，才触发失败并阻断合并（block PR），避免误报干扰开发节奏
- 将历史基线存为 JSON 文件随仓库提交，而非依赖远程服务——保证 CI 离线可运行、结果可复现
