Navigation Timing 和 Resource Timing 能分析哪些性能问题？

简化版

Navigation Timing 用来分析页面导航加载各阶段耗时，如 DNS、TCP、TLS、请求、响应、DOM 解析；Resource Timing 用来分析单个资源加载耗时。它们能帮助定位慢在网络连接、服务端响应、资源下载还是前端解析执行。

详细版

常见指标：

DNS 查询耗时。
TCP/TLS 连接耗时。
TTFB 服务端首字节时间。
HTML 下载时间。
DOMContentLoaded 和 load 时间。
JS、CSS、图片等资源耗时。

使用方式：

performance.getEntriesByType('navigation') 获取页面导航。
performance.getEntriesByType('resource') 获取资源。
上报关键字段到监控系统。
结合接口 traceId 和用户环境分析。

注意：Timing API 是诊断工具，不是单独优化方案。

完整版教学

一、性能优化先要知道慢在哪

用户说“页面慢”很模糊。慢可能发生在 DNS、建连、TLS、服务端处理、HTML 下载、JS 阻塞、图片加载、渲染等任何阶段。Navigation Timing 和 Resource Timing 的价值就是把加载过程拆成可量化阶段。

没有这些数据，优化容易变成猜谜：有人压缩 JS，有人加缓存，但真正问题可能是接口 TTFB 过高或第三方字体阻塞。

导航开始 → DNS → TCP/TLS → 请求 → TTFB → 响应下载 → DOM 解析 → load

Navigation Timing 记录一次页面导航的关键时间点。现代浏览器用 PerformanceNavigationTiming entry 表示。可以从中计算 DNS、连接、请求响应、DOM 事件等耗时。

const nav = performance.getEntriesByType('navigation')[0]
const dns = nav.domainLookupEnd - nav.domainLookupStart
const tcp = nav.connectEnd - nav.connectStart
const ttfb = nav.responseStart - nav.requestStart
const download = nav.responseEnd - nav.responseStart

这些字段能告诉你 HTML 主文档慢在哪里。比如 DNS 200ms 说明域名解析慢，TTFB 1500ms 更可能是服务端或网络链路问题。

三、Resource Timing 看资源瀑布

Resource Timing 记录 JS、CSS、图片、字体、接口等资源加载信息。它能找出大资源、慢 CDN、重复下载、阻塞首屏的字体或图片。配合 Network 面板和 RUM 上报，可以分析真实用户环境。

问题	Timing 表现	可能优化
DNS 慢	domainLookup 耗时高	dns-prefetch/preconnect
服务端慢	TTFB 高	后端优化/缓存
资源太大	response 下载久	压缩/分包
连接慢	connect 耗时高	CDN/连接复用

Resource Timing 默认对跨域资源可能有字段限制，服务端需要设置 Timing-Allow-Origin 才能暴露完整数据。

四、用数字拆解比单看 load 更有用

load 时间只能表示所有传统资源加载完成，不能说明用户何时看到内容，也不能说明慢在哪。真实优化要拆阶段。

数字例子：页面 load 4000ms，其中 TTFB 1800ms、JS 下载 800ms、图片 1000ms。此时只压缩 CSS 可能收益很小；应优先处理 TTFB、JS 分包和图片策略。相反，如果 TTFB 100ms，但 JS 执行长任务 1500ms，Timing 还要结合 Long Tasks 和性能面板继续查 CPU。

五、采集要结合真实用户环境

实验室 Lighthouse 很有用，但真实用户设备、网络、地区、浏览器差异很大。RUM 采集 Timing 数据能看到线上真实分布，例如 P50、P90、P95。不要只看平均值，平均值会被极端值干扰。

例如 1000 个用户中，900 人 1 秒打开，100 人 10 秒打开，平均是 1.9 秒，看起来还行；但 P90/P95 会暴露尾部体验很差。性能监控更应关注分位数。

P50：一半用户低于这个耗时
P90：90% 用户低于这个耗时
P95：尾部慢用户体验

六、Timing 数据要注意边界

Timing API 不等于完整性能真相。它能看网络加载阶段，但 JS 执行、渲染阻塞、交互延迟还需要 Long Tasks、Paint Timing、Event Timing、PerformanceObserver 等配合。跨域资源没有 TAO 头时，详细字段也可能不可见。

因此面试回答要说“用 Timing 定位加载链路，再结合其他指标定位渲染和交互”。这比把它当万能性能 API 更准确。

记忆钩子：Navigation Timing 看主路，Resource Timing 看每辆车；慢在哪一段，数据会先告诉你。

七、常见误区与追问

误区：load 时间就是用户体验。 load 不等于首屏、可交互或流畅度，还要看 LCP、INP、Long Tasks 等。
误区：Timing API 能解释所有卡顿。 它偏加载链路，CPU 执行和渲染问题要结合其他 API。
误区：跨域资源一定能拿到完整 timing。 需要资源服务端设置 Timing-Allow-Origin。
追问：TTFB 高说明什么？ 可能是服务端处理慢、网络链路慢、缓存未命中或后端排队。
追问：如何定位大图片拖慢首屏？ 用 Resource Timing 找图片下载耗时、大小和开始时间，再看是否影响 LCP。
追问：为什么看 P95 不只看平均值？ 平均值掩盖尾部慢用户，P95 更能反映差体验。

八、加强记忆

Timing API 用“拆链路、看资源、看分位、知边界”来记。Navigation Timing 拆主文档，Resource Timing 拆资源瀑布，RUM 上报看真实用户分布；加载问题靠它定位，CPU 和交互问题还要配合 Long Tasks、Paint 和 Event Timing。

简化版

详细版