第三方脚本拖慢页面主因是DNS查询、TCP连接或响应传输卡顿，而非代码执行慢；Resource Timing API通过domainLookupEnd-domainLookupStart、connectEnd-connectStart、responseEnd-requestStart三段耗时精准定位瓶颈，需用PerformanceObserver实时监听并结合URL特征识别第三方脚本，注意跨域资源Timing-Allow-Origin配置对数据可信度的影响。
第三方脚本拖慢页面，往往不是代码执行慢，而是卡在 DNS 查询、TCP 连接或响应传输阶段。Resource Timing API 提供的细粒度时间戳，能准确定位这些“隐形卡点”，比单纯看总耗时有效得多。
实时捕获资源加载全过程
别等页面 load 完再调用 performance.getEntriesByType("resource")——动态插入的脚本（比如 lazy-loaded SDK）可能根本没被记录。更可靠的方式是用 PerformanceObserver 实时监听：
- 监听
entryType === "resource"，确保每个脚本加载完成即被捕获 - 尤其适用于 SPA 场景，路由切换后新注入的脚本也能纳入监控
- 避免只做一次快照，防止遗漏异步加载资源
精准识别第三方脚本
不能只依赖 initiatorType === "script"，很多埋点 SDK 是 fetch + eval 动态执行的，不会出现在 script 类型里。应结合 URL 特征匹配：
- 按域名关键词过滤：如
r.name.includes("google-analytics.com")、r.name.includes("gtm.js") - 排除自家域名：
!r.name.includes(window.location.hostname) - 对聚合服务（Sentry/Bugsnag）可匹配路径：
r.name.includes("/bundle.") || r.name.includes("sentry")
重点分析三段关键耗时
总耗时（duration）只是表象，真正瓶颈藏在三个阶段：
-
DNS 查询：
domainLookupEnd - domainLookupStart。超过 50ms 建议加<link rel="preconnect"> -
TCP+TLS 握手：
connectEnd - connectStart。移动端常达 200–400ms，preconnect 同样有效 -
响应传输：
responseEnd - requestStart。若远大于首字节时间（responseStart - requestStart），说明 body 下载慢，需检查 CDN、压缩或资源体积
注意跨域与字段可信度
CDN 或 SaaS 脚本常为跨域资源，其网络阶段数据是否可信，取决于服务端是否配置了 Timing-Allow-Origin：
- 检查
domainLookupStart和connectEnd是否为 0：若为 0，大概率未配Timing-Allow-Origin: *，DNS 和连接阶段数据不可用 - 缓存状态也影响字段完整性：强缓存资源会跳过网络阶段，对应字段值为 0 或 NaN
- 重定向会引入额外延迟，关注
redirectStart/redirectEnd差值
