HTML5 User Timing API 通过 performance.mark() 和 performance.measure() 在用户可感知业务节点（如 'product-page-start'）埋点，以语义化命名、关联测量、主动拉取或 PerformanceObserver 上报，实现轻量标准的性能监控。
使用 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 条目：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 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等导航/绘制指标交叉分析。
