答案是聚焦白屏时间、首字节时间（TTFB）、DOM可交互时间三个核心指标：白屏时间=responseStart−navigationStart，TTFB=responseStart−requestStart（requestStart不可用时用fetchStart），可交互时间=domInteractive−navigationStart；需校验字段有效性、过滤非当前页记录、按页面类型分层设基线，并建立RUM持续校准机制。
设定性能基准线不是堆砌一堆数字，而是选出几个真正反映用户感知、稳定可测、且能指导优化的关键指标。Navigation Timing API 提供了足够细的阶段数据，但直接全量上报或拿所有字段设阈值，反而会模糊重点、增加误报。
聚焦三个核心可感知节点
白屏时间、首字节时间（TTFB）、DOM 可交互时间，这三个指标覆盖了用户从点击到看到内容、再到能操作的完整路径，且在绝大多数页面中都能稳定获取：
-
白屏时间 =
responseStart - navigationStart，代表用户面对空白页的等待时长，建议基线设为 ≤1.2s（移动端）或 ≤0.8s（桌面端） -
TTFB =
responseStart - requestStart，后端响应效率的直接体现；若requestStart不可用（如 Safari），退而使用fetchStart替代，基线建议 ≤300ms -
可交互时间 =
domInteractive - navigationStart，表示 HTML 解析完成、JS 开始执行的时刻，是首屏脚本就绪的关键锚点，基线建议 ≤2.5s（含基础 JS 加载与执行）
避开常见陷阱：零值与跨域干扰
很多字段在未发生对应行为时返回 0，比如没有重定向，redirectStart 就是 0；跨域 iframe 的导航记录也会缺失关键字段。盲目相减会得出错误结论：
- 校验有效性：计算 DNS 耗时前，先确认
domainLookupStart > 0且不等于fetchStart；否则说明走的是缓存，不应计入延迟 - 过滤非当前页记录：必须检查
performance.getEntriesByType('navigation')[0].name === location.href，否则可能是 iframe 或预加载产生的脏数据 - 避免用已废弃的
performance.timing，它在 Safari 和部分旧版本中字段缺失或恒为 0
按场景分层设定基线
同一套数值不适用于所有页面。首页、列表页、详情页的资源结构和渲染逻辑差异大，基线应分类设定：
- 首页通常资源多、首屏复杂，TTFB 基线可略宽（≤400ms），但白屏时间更敏感（≤1.0s）
- 详情页依赖后端数据拼装，TTFB 是瓶颈，应更严格（≤250ms），而 DOM 可交互时间可适当放宽（≤3.0s）
- 静态落地页应追求极致，三项指标全部压到基线下限，例如白屏 ≤0.6s、TTFB ≤150ms
建立持续校准机制
基线不是设完就一劳永逸。每月用真实用户采样数据（RUM）回看达标率，若连续两周某项达标率低于 95%，就需重新评估基线是否合理，或确认是否存在新引入的性能劣化点：
- 只采集首屏核心资源加载完成后的数据，排除异常慢网、低端设备等离群样本（如 P95 以上耗时）
- 结合 Resource Timing 数据交叉验证，比如 TTFB 持续升高，再查对应接口的
responseEnd - responseStart是否同步增长，判断是网络还是后端问题 - SPA 场景下，单页内路由跳转不触发 navigation 类型条目，需配合 PerformanceObserver 监听
navigation类型 entry，或改用自定义 mark/measurement 补充
