应使用 performance.getEntriesByType('navigation')[0] 替代已弃用的 performance.timing，因其在 Safari 和 WebView 中稳定可用，可准确拆解首屏各阶段耗时。
别在预览页里依赖 performance.timing，它在 Safari 和多数 WebView 中根本拿不到有效值；直接用 performance.getEntriesByType('navigation')[0] 拆解首屏各阶段，才是稳定、可复现的方案。
为什么预览场景下 performance.timing 基本不可用
HTML 预览（比如 VS Code Live Server、CodePen、本地双击打开的 .html 文件）常运行在受限上下文或旧版 WebView 中。此时 performance.timing 的多数字段（如 domainLookupStart、connectStart）会返回 0 或 undefined，哪怕 DNS 和 TCP 真实发生了耗时——这不是网络快，是浏览器压根没填这些值。
常见错误现象：
-
performance.timing.navigationStart为0，导致所有差值计算得负数或NaN -
performance.timing.responseStart - performance.timing.requestStart恒为0，TTFB 完全失真 - 在 iOS QQ 浏览器预览页中，整个
timing对象字段全空
根本原因：W3C 已将 PerformanceTiming 标记为 deprecated，Safari 和大部分 WebView 实现从未完整支持 Level 1 规范。
立即学习“前端免费学习笔记（深入）”；
预览页中安全获取导航时序的三步 fallback
必须按顺序尝试以下方式，不能跳过：
- 首选：
performance.getEntriesByType('navigation')[0]—— 所有现代浏览器（Chrome 60+、Firefox 58+、Safari 15.4+）均支持，字段语义清晰、精度微秒级，且仅需一次调用 - 降级：
performance.navigationStart（注意不是timing.navigationStart）—— 这是规范定义的顶层属性，兼容性比timing好得多 - 兜底：
Date.now()—— 仅用于极端情况，比如页面刚加载 JS 就执行，连navigationStart都未就绪时
推荐写法：
const nav = performance.getEntriesByType('navigation')[0];
const navStart = nav ? nav.startTime : (performance.navigationStart || Date.now());注意：nav.startTime 等价于 navigationStart，但更语义化，也避免了 fallback 判断嵌套。
怎么从 navigation 条目拆出渲染关键阶段（预览页实测可用）
预览页中 HTML 通常无服务端逻辑，但 TTFB、DOM 解析、资源加载等阶段依然存在，只是数值偏小。重点看这几个差值（单位：毫秒，含小数）：
-
nav.responseStart - nav.requestStart：TTFB，本地预览应 100ms，检查是否被插件拦截或启用了慢速模拟 -
nav.domInteractive - nav.domLoading：HTML 解析耗时，含同步脚本执行；预览页中若 > 50ms，说明 inline 脚本过大或含阻塞解析操作 -
nav.domContentLoadedEventEnd - nav.responseEnd：DOM 构建 + 同步 JS 执行总耗时；超过 100ms 就该查<script>是否未加defer或async -
nav.loadEventEnd - nav.domContentLoadedEventEnd：异步资源拖尾时间；预览页中若明显高于其他阶段，说明图片、字体等未压缩或未设decoding="async"
特别注意：nav.type === 'back_forward' 在预览页中几乎不会出现，可忽略该分支；但若你手动刷新后立即读取，仍建议加判空防护：if (!nav) return;
预览页中容易被忽略的两个精度陷阱
一是 performance.now() 虽然高精度，但在预览页中若配合 setTimeout 或 Promise.then 打点，容易因任务队列延迟引入误差——建议对渲染逻辑用 requestIdleCallback 包裹后再测；二是 performance.getEntriesByType('resource') 返回的资源条目，只有已加载完成、未走强缓存、且响应头含 Timing-Allow-Origin: * 的跨域资源才带完整字段，本地 file:// 协议下多数资源会缺失 connectStart 等字段，此时只能依赖 duration 粗略判断。
