应优先使用 performance.getEntriesByType('navigation') 获取 PerformanceNavigationTiming 实例，因其语义清晰、精度高且主流浏览器均支持；若不支持，则按 performance.navigationStart、performance.timing.navigationStart、Date.now() 逐级降级；需注意 back_forward 类型下 responseStart 可能为 0，上报应使用 sendBeacon 并配置 Timing-Allow-Origin。
直接用 performance.timing 统计页面加载时间已不可靠——Safari、iOS QQ 浏览器及多数 WebView 中它常返回 0 或 undefined，Chrome 120+ 更已正式弃用。真正稳定的做法是优先使用 performance.getEntriesByType('navigation') 获取标准的 PerformanceNavigationTiming 实例，再结合降级逻辑与关键阶段拆解。
首选：用 navigation 类型获取完整导航时序
performance.getEntriesByType('navigation') 返回的是语义清晰、精度达微秒级的现代接口，所有主流浏览器（Chrome 60+、Firefox 59+、Safari 15.4+）均支持。调用后取第一个条目即可：
- 确保在
document.readyState === 'complete'后执行，或监听window.addEventListener('load', ...)，否则数组可能为空 -
nav.startTime等价于导航起点，比navigationStart更规范、更可靠 - 字段如
responseStart、domContentLoadedEventEnd、loadEventEnd全部可用，无需手动映射
关键阶段耗时计算示例
从 nav 对象中直接相减，就能得到用户感知最敏感的几个阶段：
-
TTFB（首字节时间）：
nav.responseStart - nav.requestStart，超过 800ms 需排查后端或 CDN -
DOM 解析耗时：
nav.domContentLoadedEventEnd - nav.responseEnd，反映 HTML 解析 + 同步脚本执行时间 -
资源拖尾时间：
nav.loadEventEnd - nav.domContentLoadedEventEnd，高值说明图片、字体、异步脚本加载慢 -
HTML 解析阶段：
nav.domInteractive - nav.domLoading，异常高可能因 HTML 过大或含阻塞脚本
注意：若 nav.type === 'back_forward'（前进/后退缓存），responseStart 可能为 0，此时跳过 TTFB 计算。
兼容性兜底与安全降级
不是所有环境都支持 getEntriesByType，尤其 IE11 或老旧 WebView。需按优先级逐层 fallback：
- 首选
performance.navigationStart（注意不是timing.navigationStart） - 次选
performance.timing && performance.timing.navigationStart（仅用于极老 Chrome/Firefox） - 最后 fallback 到
Date.now()（适用于 JS 在页面刚打开时就执行的极端情况）
不建议依赖 window.onload 触发统计——此时资源早已加载完毕，错过 TTFB、JS 执行阻塞等关键瓶颈点。
上报与数据有效性保障
采集到的数据必须及时、低干扰地上报：
- 用
navigator.sendBeacon()发送，确保页面卸载前也能发出请求 - 跨域资源（如 CDN 图片、外部 JS）需服务端响应头包含
Timing-Allow-Origin: *，否则duration和responseStart全为 0 - 前端请求需显式添加
crossorigin属性，例如<script src="a.js" crossorigin> - 大页面易丢数据？提前调用
performance.setResourceTimingBufferSize(500)扩容缓冲区
不复杂但容易忽略的是：监控代码必须放在 <head> 内联 <script> 中尽早执行，否则会漏掉导航早期时间点。
