HTML中如何使用performance.mark标记性能节点-html教程-PHP中文网

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

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

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() 是标准性能基线。两者根本不在一个层级上。

html-deploy

使用 htmlcode.fun 将 HTML 内容或文件部署到网页，适用于用户要求“部署到网页”“托管此 HTML”“生成此前端...的实时链接”等场景。

下载

关键差异：

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，整套监控就变成盲区。