如何使用HTML5中UserTimingAPI为业务关键路径添加自定义性能打点-H5教程-PHP中文网

html5 user timing api 通过 performance.mark() 和 performance.measure() 在用户可感知业务节点（如 'product-page-start'）埋点，以语义化命名、关联测量、主动拉取或 performanceobserver 上报，实现轻量标准的性能监控。

如何使用html5中usertimingapi为业务关键路径添加自定义性能打点

使用 HTML5 的 User Timing API 为业务关键路径添加自定义性能打点，核心是用 performance.mark() 和 performance.measure() 在关键节点手动埋点，再通过 performance.getEntriesByType('measure') 或 PerformanceObserver 收集数据。它不依赖第三方 SDK，轻量、标准、可与浏览器 DevTools 和 RUM 系统无缝对接。

明确关键路径节点，合理命名 mark

业务关键路径不是代码执行路径，而是用户可感知的业务阶段，例如“商品页开始加载”“购物车提交按钮点击”“支付成功弹窗显示”。每个节点应使用语义化、唯一、小写短横线分隔的字符串命名：

performance.mark('product-page-start');
performance.mark('cart-submit-click');
performance.mark('payment-success-shown');

避免使用动态值（如 ID、时间戳）作为 mark 名，否则无法聚合分析；也不要用过于宽泛的名称（如 'start'），易与其他脚本冲突。

用 measure 关联两个 mark，计算业务耗时

当需要度量某段业务流程耗时（如“从点击下单到支付成功展示”），在起点和终点分别 mark 后，调用 performance.measure() 创建可统计的 measure 条目：

anything-to-html

将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。

下载

performance.mark('order-submit-click');
// ... 用户跳转、接口请求、渲染等逻辑
performance.mark('payment-confirmed');
performance.measure('time-to-payment-confirm', 'order-submit-click', 'payment-confirmed');

measure 名称建议采用 动词-名词-修饰 结构（如 time-to-payment-confirm），便于后续按前缀过滤或排序。注意：起始 mark 必须在 measure 调用前已存在，否则 measure 创建失败（静默忽略）。

主动上报或监听 measure 数据

默认情况下，mark/measure 数据仅保留在内存中，需主动采集并发送至监控服务：

主动拉取：在关键流程结束或页面卸载前（如 beforeunload），调用 performance.getEntriesByType('measure') 过滤出业务相关 measure，序列化后通过 sendBeacon 上报：
const measures = performance.getEntriesByType('measure').filter(m => m.name.startsWith('time-to-'));
navigator.sendBeacon('/log/perf', JSON.stringify(measures));
被动监听：使用 PerformanceObserver 实时捕获新创建的 measure（推荐用于 SPA 页面级监控）：
new PerformanceObserver((list) => { list.getEntries().forEach(entry => { if (entry.entryType === 'measure' && entry.name.includes('time-to-')) sendToMonitor(entry); }); }).observe({entryTypes: ['measure']});

与真实用户体验对齐，注意时机和上下文

User Timing 打点本身几乎无性能开销，但埋点位置决定数据价值：

mark 应尽量靠近用户行为触发点（如 click 事件回调开头），而非异步回调深处，否则会漏计交互延迟；
涉及服务端响应的环节（如下单接口返回），应在收到响应后立即 mark，而非发起请求时——前者反映真实用户等待时长；
在 SSR + hydration 场景中，服务端无法调用 User Timing，所有 mark 必须在客户端执行；若需对比首屏时间，可结合 navigationStart 或 first-contentful-paint 等导航/绘制指标交叉分析。