HTML中如何用performance.mark标记性能节点

根本原因是标记未真正注册成功；需满足名称合法、调用已执行且未被clearMarks清除，常见问题包括构建工具误删、变量拼接命名、异步时序错乱及IE11兼容性限制。

performance.mark() 为什么打完点却 getEntriesByName 拿不到？

根本原因不是 API 失效，而是标记没真正“注册成功”。performance.mark() 调用后，标记只有在满足三个条件时才会出现在 performance.getEntriesByName() 结果里：名称是合法字符串、调用已执行（非被压缩移除）、且未被 performance.clearMarks() 清掉。

常见失效场景：

• 构建工具（如 Terser）把 performance.mark('xxx') 当作无副作用语句删了——加 void 0 兜底：performance.mark('xxx'); void 0;
• 用变量拼接名：performance.mark(prefix + '-start')，压缩后可能变成 performance.mark('a' + '-start')，导致名称不一致
• 异步逻辑中先读再打：setTimeout(() => { performance.mark('a'); }, 0); console.log(performance.getEntriesByName('a')); —— 极大概率返回空数组
• IE11 虽支持 mark()，但不支持 clearMarks()，若你手动清理失败，旧标记会残留干扰新数据

如何安全配对 performance.mark 和 performance.measure？

performance.measure() 不是自动计算工具，它只做一件事：查两个已存在的 mark 名，取它们的 startTime 相减，生成一条 PerformanceMeasure 条目。任一 mark 缺失，measure 就静默失败，不报错也不留记录。

确保配对可靠的实操要点：

立即学习“前端免费学习笔记（深入）”；

• 必须显式检查起点是否存在：if (performance.getEntriesByName('api-start').length) { performance.mark('api-end'); performance.measure('api-latency', 'api-start', 'api-end'); }
• 名称严格区分大小写和空格：'Api-Start' 和 'api-start' 是两个不同标记，measure() 不会模糊匹配
• 避免重复名覆盖：多次 performance.mark('load') 只保留最后一次，建议加唯一后缀，如 `load-${Date.now()}` 或 `load-${Math.random().toString(36).substr(2, 6)}`
• 别用 performance.timing 里的字段（如 navigationStart）直接传给 measure() —— 它只认字符串名，不接受数值时间戳

为什么不能只用 console.time 替代 performance.mark？

console.time() 是调试辅助，performance.mark() 是标准性能基线。两者根本不在一个层级上。

关键差异：

• console.time('x') 的计时上下文不稳定：Promise 链中断、跨 iframe、React 异步更新后都可能丢失或错位
• DevTools Timeline、Lighthouse、RUM SDK 等工具原生识别 performance.getEntriesByType('mark')，但完全忽略 console.time 记录
• performance.mark() 的时间戳统一基于 navigationStart，能和 FP、FCP、DOMContentLoad 等原生指标对齐分析；console.time 是相对当前 JS 执行时刻的任意偏移
• console.time 数据无法结构化导出，也不能通过 PerformanceObserver 自动捕获上报

上报 measure 数据时最容易漏掉的三件事

很多团队实现了打点和 measure，但监控后台收不到数据，问题往往卡在上报环节。

必须确认以下三点都到位：

• PerformanceObserver 必须显式配置 { entryTypes: ['measure'] } —— 缺少这个选项，回调永远不会触发，这是最常被跳过的配置
• 上报不能依赖 window.onunload：页面快速跳转或崩溃时，日志直接丢失；应在 measure 创建后立刻提取并用 navigator.sendBeacon() 发送
• 高频打点必须节流：滚动、输入等场景下 measure 可能一秒几十条，直接发请求会阻塞主线程甚至被浏览器限流；应聚合为批次（如 500ms 内最多发一次），或使用 requestIdleCallback 异步发送

真正难的不是打点动作本身，而是让每个 mark 都对应可复现的用户行为切片，并确保从打点、测量到上报整条链路没有时序断点或命名歧义。一旦某个环节用了变量拼接名、或忘了清旧标记、或 observer 没配 entryTypes，整套监控就变成盲区。