应使用performance.getEntriesByType("navigation")[0]获取当前页面导航时间线，因其精度高、字段全、语义清晰且现代浏览器全面支持；需在DOMContentLoaded或load事件中调用，校验entry.name === location.href，并兜底处理空数组。
直接用 performance.getEntriesByType("navigation")[0] 获取当前页面导航的完整时间线，这是现代前端性能监控的事实标准。它比已废弃的 performance.timing 更精准、字段更全、语义更清晰，且所有时间戳均为高精度浮点数（单位毫秒，实际精度可达微秒级）。
怎么安全拿到有效的导航数据
不能等页面完全加载完再取，也不能无条件取数组第一项——必须兼顾时机和上下文：
- 调用时机：放在
DOMContentLoaded或load事件回调中，但最好在<head>内尽早执行脚本，避免错过数据 - 校验来源：检查
entry.name === location.href，排除 iframe 或预加载产生的干扰条目 - 兜底处理：数组可能为空（如 Service Worker 拦截、iframe 导航、非标准跳转），建议写成
const nav = performance.getEntriesByType("navigation")[0] || {} - 兼容性：Chrome 60+、Firefox 58+、Edge 79+、Safari 15.4+ 均支持；旧浏览器可降级回
performance.timing，但不推荐长期依赖
核心阶段耗时怎么算才准
每个阶段都由一对时间戳定义，相减即得耗时，但要注意“零值陷阱”——很多字段为 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 更贴近真实体验
导航类型与用户行为强关联
Level 2 把原来数字编码的 performance.navigation.type 升级为语义化字符串，直接对应用户操作：
Html To Pdf
下载
使用 Puppeteer + Chrome 将 HTML 渲染为中文 PDF，自动处理图表等待、Tab 展开、动画、测高、白边消除、防分页，适用于看板、报表、网页和交互图表转 PDF。
立即学习“前端免费学习笔记（深入）”；
-
"navigate"：点击链接、输入地址、表单提交、location.href跳转等常规导航 -
"reload"：F5 刷新、location.reload()、meta refresh 触发 -
"back_forward"：浏览器前进/后退按钮触发，通常伴随缓存复用，各阶段耗时明显更低
结合类型与具体耗时，能区分“用户反复刷新是因为卡顿”还是“只是习惯性点刷新”，支撑更精细的归因分析。
常见误读和排查要点
很多性能问题不是指标异常，而是理解偏差：
-
redirectStart === 0不代表没重定向，可能是跨域重定向导致字段被清零（W3C 规范限制） -
unloadEventStart和unloadEventEnd在 SPA 中常为 0，因为前页未真正卸载 - iframe 子页面的导航记录独立存在，主页面 timing 不包含其 DNS/TCP 等数据
- Service Worker 拦截后，部分字段（如
domainLookupStart）可能为 0 或不准确，需配合 Network 面板交叉验证 - 聚合分析时，单条数据没意义；要按地域、设备、DNS 服务器 IP、HTTP 协议版本等维度分组，才能定位是全局问题还是局部现象
