域名解析耗时异常的判断标准是：domainlookupend - domainlookupstart > 100ms需警惕，持续超300ms可确认问题；若该值为0或极小，通常因连接复用或缓存未触发dns查询，需结合redirectstart、connectstart等字段交叉验证，并按地域或dns服务器ip聚合分析以区分全局与局部问题。
直接看 performance.timing 里的 domainLookupStart 和 domainLookupEnd 这两个时间戳，就能定位域名解析是否慢、慢在哪一段。
怎么看解析耗时是否异常
用下面这行代码算出 DNS 解析耗时：
domainLookupEnd - domainLookupStart正常情况应在 0–50ms 内；超过 100ms 就值得警惕；持续高于 300ms 基本确认存在解析问题。
注意：如果页面走的是长连接、HTTP/2 复用或资源来自缓存，domainLookupStart 和 domainLookupEnd 都会回落到 fetchStart，此时值为 0 或极小——这不是解析快，而是压根没查 DNS。
结合前后节点交叉验证真实原因
单看 DNS 时间不够，要拉通上下游节点比对，排除干扰：
- redirectStart > 0 且 redirectEnd - redirectStart 很大：说明重定向链路中某次跳转触发了新的 DNS 查询，不是首屏主域名慢，而是跳转目标域名解析慢
- domainLookupStart ≈ fetchStart：大概率没走 DNS（复用连接/本地缓存），此时 DNS 时间无意义，别误判
- connectStart - domainLookupEnd > 200ms：DNS 已完成，但建连仍卡顿，问题可能在 TCP 握手或 SSL 协商，和 DNS 无关
- navigationStart 到 domainLookupStart 间隔大：当前页卸载或上一页 unload 事件执行太久，属于前序页面拖累，非 DNS 问题
区分是全局慢还是个别用户慢
仅靠单个用户 timing 数据无法下结论。需聚合上报分析：
- 按地域分组：某地区用户
domainLookupEnd - domainLookupStart普遍偏高 → 可能当地运营商 DNS 服务差 - 按 DNS 服务器 IP 分组（需配合 Resource Timing 或自定义采集）：特定 DNS IP 对应的解析延迟集中偏高 → 锁定问题 DNS 服务商
- 对比同域名不同子路径：只有带 query 参数的 URL 解析慢 → 可能被某些 DNS 中间件误识别为异常请求而限速
避开常见误读陷阱
这几个典型误区容易导致归因错误：
-
domainLookupStart === 0不代表没解析，可能是跨域页面或导航起始于新窗口，此时应参考navigationStart是否合理 - 页面含 iframe 且 iframe 域名不同：主文档 timing 不包含 iframe 的 DNS 时间，需用
performance.getEntriesByType('navigation')分别取各 frame 的记录 - Service Worker 拦截了导航请求：timing 中 DNS 相关字段可能被跳过或置零，需检查
performance.getEntriesByType('resource')中关键资源的domainLookupStart/End
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
