html模板是性能起点和放大器，必须在解析阶段埋点：用performance.mark标记关键区块起止，performance.measure计算解析耗时，统一以navigation条目为基准对齐数据，且须与服务端日志协同分析。
HTML 模板本身不参与运行时性能瓶颈，但它是所有前端性能指标的起点和放大器——performance.getEntriesByType('navigation') 中的 domInteractive、domContentLoadedEventEnd 等关键时间点，全部锚定在 HTML 解析流程中。组件监控若脱离模板加载阶段，等于在源头失焦。
为什么不能只监控 JS 组件的 mount 耗时
很多团队用 console.time 或框架生命周期钩子（如 React 的 useEffect）测组件渲染耗时，但这漏掉了最重的一段：HTML 解析 + 内联脚本执行 + 首屏 DOM 构建。比如一个 <my-header></my-header> 自定义元素，如果它的 connectedCallback 里调用了 document.querySelector，而此时 DOM 还没解析完，就会触发 parser-blocking 回退，实际延迟远超 JS 执行本身。
- 内联
<script></script>在中同步执行，会中断 HTML 解析流，domInteractive时间直接拉长 - 第三方 SDK 若未用
async defer加载，可能在开头就阻塞后续标签解析 - 服务端渲染（SSR）模板中混入大量
data-*属性或 JSON 字符串，会增大 HTML 体积，延长responseEnd到domInteractive的间隔
如何对 HTML 模板做轻量级组件级埋点
目标不是给每个 <div class="card"> 打点，而是标记模板中关键语义区块的解析完成时机。核心原则：不打断解析、不依赖 <code>document、早于 DOMContentLoaded。
- 在模板关键节点前插入
<script>performance.mark('header-start')</script>，节点后插入<script>performance.mark('header-end')</script> - 避免使用
document.currentScript—— 它在某些浏览器中不可靠，且会触发 parser reentrancy - 对自定义元素，应在
constructor中调用performance.mark，而非connectedCallback（后者可能被多次触发） - 用
performance.measure('header-parse', 'header-start', 'header-end')计算解析耗时，比 JS 执行耗时更反映真实瓶颈
组件监控数据怎么和 Performance API 对齐
常见错误是把组件上报时间和 performance.timing 混用。前者已废弃，后者无法反映现代多进程浏览器的真实行为。必须统一用 performance.getEntriesByType('navigation') 提供的字段做基准。
-
fetchStart是 DNS 查询起点，若组件首屏依赖异步资源，需对比其startTime是否晚于该值 -
responseEnd到domInteractive的差值，就是 HTML 解析 + 同步脚本执行总耗时，超过 200ms 就要检查模板中是否含document.write或未加defer的内联脚本 - 上报组件解析数据时，必须带上
entry.navigationType（如'navigate'或'reload'），否则无法区分冷启与缓存恢复场景 - 不要用
window.onload触发上报 —— 此时用户可能已滚动或跳转，应改用sendBeacon在beforeunload中发出performance.getEntriesByType('element')（需提前启用PerformanceObserver监听element类型）
最容易被忽略的是：HTML 模板监控不是“加个 script 标签就完事”。它必须和服务端日志对齐 —— 比如 Nginx 的 $request_time 和前端 responseEnd - fetchStart 差值超过 100ms，说明网络或服务端有异常；而这个差值本身，正是你所有组件解析耗时的天花板。
