如何运用 performance.getEntries 深入分析第三方 SDK 对关键路径的阻塞

必须结合nextHopProtocol、initiatorType及时序关系定位伪装SDK：动态注入脚本initiatorType为script/fetch，需查域名而非仅.js后缀；重定向资源用responseEnd-fetchStart算真实耗时；阻塞关键路径需满足requestStart<domInteractive且responseEnd>domContentLoadedEventStart。

第三方 SDK 会真实拖慢首屏，但光看 performance.getEntriesByType('resource') 很难定位它到底卡在哪——必须结合 nextHopProtocol、initiatorType 和资源加载链路的时序关系来交叉验证。

怎么从 resource entries 里揪出“伪装成普通资源”的 SDK

很多 SDK（尤其是埋点、广告、A/B 测试类）不走 <script src>，而是用 document.createElement('script') + appendChild 动态注入，initiatorType 会是 script 或 fetch，但名字常被混淆（比如叫 vendor-abc.js 或直接是 CDN 域名路径）。

• 别只筛 .js 后缀：有些 SDK 加载的是 JSON 配置或 wasm 模块，要同时查 initiatorType === 'fetch' 且 name 包含已知 SDK 域名（如 cdn.segment.com、analytics.google.com）
• 注意重定向干扰：如果 SDK 资源有跳转（redirectStart > 0），duration 会包含跳转耗时，实际阻塞时间得用 responseEnd - fetchStart 才准
• 检查 renderBlocking 线索：虽然 Performance API 没这个字段，但若某资源的 requestStart < domInteractive 且 responseEnd > domContentLoadedEventStart，基本就是同步阻塞关键路径

为什么 performance.getEntriesByType('navigation') 能暴露 SDK 的隐性开销

performance.getEntriesByType('navigation') 返回的 entry 本身不记录 SDK，但它的时间戳会被 SDK 拉偏——特别是 domInteractive 和 domContentLoadedEventStart。一旦这两个值比同环境竞品页高 200ms+，就要怀疑是否有 SDK 在 DOM 构建中途执行了长任务。

• 对比基线：取同一页面未加载 SDK 时的 domInteractive 值（可通过禁用 SDK 后刷新获取），差值超过 50ms 就值得深挖
• 看 nextHopProtocol 是否一致：如果 SDK 资源用了 HTTP/2 而主站是 HTTP/3，说明它可能绕过主站连接复用，额外建立 TCP+TLS 连接，这种开销会反映在 connectStart 到 connectEnd 的 gap 上
• 留意 workerStart：某些 SDK 内置 Service Worker 注册逻辑，workerStart > 0 且紧挨着 fetchStart，说明它在抢主线程做注册，不是纯加载问题

避开 performance.getEntries() 的三个典型陷阱

调用 performance.getEntries() 本身没问题，但数据采集时机和过滤方式不对，结果就全偏了。

• 别在 load 事件后才调：TV 浏览器、部分 Android WebView 会在卸载前清空 buffer，必须在 domContentLoaded 后立刻执行，或用 PerformanceObserver 监听 resource 类型
• 跨域资源默认没完整 timing：如果 SDK 资源来自第三方域名，且对方没配 Timing-Allow-Origin: * 响应头，connectStart、requestStart 等字段会是 0，此时只能依赖 duration 和 startTime 粗略估算
• getEntries() 不等于所有资源：它只返回已触发 complete/error 的资源；动态插入后又移除的 script、abort 的 fetch 不会出现，得配合 addEventListener('error', ...) 补漏

真正难的不是拿到数据，而是把一条 resource entry 和某段 SDK 的初始化逻辑对应起来——比如某个 analytics.min.js 的 responseEnd 是 1240ms，但它的 eval 执行却拖到 1890ms，这时候就得靠 PerformanceObserver 监听 longtask，再用堆栈反查是谁触发了那段代码。