直接用 performance.getentriesbytype("navigation")[0] 获取当前页面完整加载时间线是现代前端性能监控的事实标准，它比已废弃的 performance.timing 更精准、字段更全、语义更清晰，所有时间戳均为高精度浮点数（毫秒级，可达微秒级）。
直接用 performance.getEntriesByType("navigation")[0] 获取当前页面的完整加载时间线，这是现代前端性能监控的事实标准。它比已废弃的 performance.timing 更精准、字段更全、语义更清晰，所有时间戳都是高精度浮点数（单位毫秒，实际可达微秒级）。
怎么安全拿到有效的导航数据
不能无条件取数组第一项，也不能等页面完全加载完再读——必须兼顾调用时机和上下文校验：
-
调用时机：放在
DOMContentLoaded或load事件回调中；更稳妥的做法是在内尽早执行脚本，避免因延迟导致数据丢失 -
校验来源：检查
entry.name === location.href，排除 iframe 加载、预加载或 Service Worker 拦截产生的干扰条目 -
兜底处理：数组可能为空（如非标准跳转、iframe 导航），建议写成
const nav = performance.getEntriesByType("navigation")[0] || {}
核心阶段耗时怎么算才准
每个阶段由一对时间戳定义，相减即得耗时，但要注意“零值陷阱”——很多字段为 0 并非耗时为 0，而是该阶段未发生或被跳过：
-
DNS 查询：
domainLookupEnd - domainLookupStart；若两者均为 0，大概率是连接复用或本地缓存，不是解析快 -
TCP 连接：
connectEnd - connectStart；若等于 0，说明复用已有连接 -
SSL 握手：
connectEnd - secureConnectionStart；仅当secureConnectionStart > 0且不等于connectStart时才有效 -
TTFB（首字节时间）：优先用
responseStart - requestStart；若requestStart为 0（如 Safari），改用responseStart - fetchStart -
白屏时间：
domLoading - fetchStart，反映用户看到空白页到开始渲染的延迟 -
可交互时间：
domContentLoadedEventEnd - navigationStart，比onload更贴近真实体验
导航类型与用户行为强关联
Navigation Timing Level 2 把原来数字编码的 performance.navigation.type 升级为语义化字符串，直接对应用户操作：
- "navigate"：点击链接、输入地址、表单提交、脚本跳转等常规导航
-
"reload"：F5 刷新、
location.reload()、<meta http-equiv="refresh">触发 - "back_forward"：浏览器前进/后退按钮触发，通常伴随缓存复用，各阶段耗时明显更低
结合类型与具体耗时，能区分“用户反复刷新是因为卡顿”还是“只是习惯性点刷新”，支撑更精细的归因分析。
兼容性与降级策略
Chrome 60+、Firefox 58+、Edge 79+、Safari 15.4+ 均原生支持 navigation 类型 PerformanceEntry；TV 浏览器或老旧环境需注意：
- 优先尝试
performance.getEntriesByType("navigation")，失败则 fallback 到performance.timing - TV 端如 WebOS/Tizen 可能阉割部分 API，建议搭配
performance.getEntriesByType("paint")和document.readyState辅助判断 - 避免依赖
console.time()，其高精度计时器在 TV 浏览器中常被降频，应改用performance.now()
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
