Performance API 的 timing 对象用于记录页面加载过程中各个关键时间点，帮助开发者分析页面性能。以下是 timing 对象中各时间节点的含义：1. navigationStart含义：浏览器开始导航（即开始加载当前页面）的时间戳。作用：作为所有其他时间点的起点。2. unloadEventStart / unloadEventEnd含义：前一个页面的 unload 事件开始和结

Performance API 的 `timing` 对象虽曾用于衡量页面加载各阶段耗时，但已被现代浏览器正式弃用——Chrome 120+、Firefox 115+ 和 Safari 17.4+ 均标记其为 deprecated，字段在跨域重定向、Service Worker、HTTP/3 等场景下常返回不可靠的 0 值，且语义模糊、精度低、易被误解（如 `navigationStart` 并非用户点击时刻，SPA 中更完全失效）；开发者应立即迁移到标准、高精度、语义清晰的 `performance.getEntriesByType('navigation')` 获取 `PerformanceNavigationTiming` 实例，结合 `performance.timeOrigin` 计算真实耗时，并优先依赖 `domContentLoadedEventEnd`、`first-contentful-paint` 等关键用户体验指标及服务端注入的 `serverTiming` 数据，告别对已淘汰 `performance.timing` 的错误依赖和误导性差值计算。

performance.timing 已被弃用，别再直接读取它

Chrome 120+、Firefox 115+ 和 Safari 17.4+ 都已标记 performance.timing 为废弃（deprecated），控制台会输出警告；它返回的 PerformanceTiming 对象也不再新增字段，且部分字段在跨域重定向、Service Worker、HTTP/3 等场景下值为 0 或不可靠。

真正该用的是 performance.getEntriesByType('navigation') —— 它返回标准的 PerformanceNavigationTiming 实例，所有时间戳都基于 performance.timeOrigin，精度更高、语义更清晰、兼容性更好。

• 旧写法：performance.timing.loadEventEnd - performance.timing.navigationStart
• 新写法：performance.getEntriesByType('navigation')[0]?.loadEventEnd || 0

navigationStart 到 loadEventEnd 这段链路里哪些节点最常出问题

navigationStart 是整个页面加载流程的锚点，但它的实际含义容易被误解：它不是“用户点击链接那一刻”，而是“前一个页面卸载完成”或“无前页时等同于 fetchStart”。这意味着：

• 如果上一页有长耗时的 beforeunload 处理，navigationStart 会被拖后，导致后续所有计算值偏大
• SPA 跳转（如 React Router）不会触发 navigationStart 更新，此时它仍沿用初始加载值，完全失效
• loadEventEnd 在现代框架中意义变弱——很多资源异步加载、不阻塞 load 事件，它可能早在首屏渲染前就结束了

真正值得盯的节点是：domContentLoadedEventEnd（DOM 就绪）、first-contentful-paint（需用 performance.getEntriesByType('paint') 获取）、以及 nextPaint（实验性，暂不建议依赖）。

domainLookupStart / connectStart 等字段为 0 的真实原因

这些字段不是“没记录”，而是按规范返回 0 表示“未发生对应阶段”或“不可测量”。常见情况包括：

• domainLookupStart === 0：DNS 查询被跳过（例如复用长连接、命中本地 hosts、或资源来自 Service Worker 缓存）
• connectStart === 0：没走网络连接（如从内存缓存读取 HTML，或 Service Worker 直接响应）
• secureConnectionStart === 0：当前非 HTTPS 页面，或使用了 HTTP/3（其握手机制不映射到该字段）
• redirectStart 和 redirectEnd 同为 0：要么没重定向，要么重定向跨域（同源限制导致浏览器主动清零）

所以看到一堆 0，不要急着怀疑代码，先检查网络面板里的 Initiator 列和协议类型（HTTP/1.1 vs HTTP/2 vs HTTP/3），再判断是否真有瓶颈。

用 timing 差值算性能指标时最容易踩的坑

直接拿两个时间戳相减看似简单，但结果可能毫无业务意义。比如：

• responseEnd - requestStart ≠ “后端响应时间”：它包含网络传输、TLS 握手、TCP 队头阻塞等，且若响应被缓存，requestStart 可能等于 responseStart，差值接近 0，但这不代表后端快
• domInteractive - domLoading ≠ “HTML 解析耗时”：中间夹杂了同步脚本执行、CSS 阻塞解析、document.write 等不可控因素
• 所有差值都受时钟偏差影响：若用户设备时间不准，performance.timeOrigin 偏离真实值，所有绝对时间戳都会漂移

生产环境做监控时，优先采集 PerformanceNavigationTiming 中的 serverTiming 字段（需服务端注入），或用 Resource Timing 单独测关键接口，比硬扣 timing 差值靠谱得多。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。