performance.getEntries：分析第三方SDK阻塞关键路径

第三方 SDK 拖慢首屏加载是常见问题，但当你打开开发者工具，面对 performance.getEntriesByType('resource') 返回的大量资源条目时，往往感觉无从下手。哪个才是真正阻塞关键渲染路径的“元凶”？这不只是一个筛选问题，更是一道需要交叉验证的技术难题。

关键在于不能只看表面数据。只有将 nextHopProtocol（下一跳协议）、initiatorType（发起者类型）与整个资源加载链路的时序关系结合起来，才能揪出那些伪装成普通资源的 SDK。

从 resource entries 中识别伪装成普通资源的 SDK

很多埋点、广告、A/B 测试类 SDK 不会使用传统的 标签，而是通过 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。
• 检查渲染阻塞的蛛丝马迹：虽然 Performance API 没有直接的 renderBlocking 字段，但可以通过时序逻辑推断。如果一个资源的 requestStart 发生在 domInteractive 之前，且 responseEnd 晚于 domContentLoadedEventStart，那么它很可能同步阻塞了关键渲染路径。

利用 performance.getEntriesByType('navigation') 暴露 SDK 的隐性开销

导航条目本身不记录具体 SDK，但 SDK 的加载与执行会影响整个页面的关键时间点，尤其是 domInteractive 和 domContentLoadedEventStart。当这两个值比同等环境下的竞品页面高出 200 毫秒以上时，应警惕是否有 SDK 在 DOM 构建期间执行了长任务。

• 建立对比基线：获取同一页面在不加载该 SDK 时的 domInteractive 值（例如通过禁用 SDK 后刷新页面）。如果差值超过 50 毫秒，就值得深入排查。
• 观察 nextHopProtocol 是否一致：若主站使用 HTTP/3，而某个 SDK 资源却走 HTTP/2，说明它没有复用主站连接，需要额外建立 TCP 和 TLS 连接。这种开销会体现在 connectStart 到 connectEnd 的间隔上。
• 留意 workerStart 信号：某些 SDK 内置了 Service Worker 注册逻辑。如果发现资源的 workerStart > 0 且紧挨着 fetchStart，说明它在加载的同时抢占主线程进行注册，这已不仅仅是加载耗时的问题。

避免 performance.getEntries() 的三个常见陷阱

调用 performance.getEntries() 本身没问题，但数据采集时机和过滤方式不当，很容易得出错误结论。

• 不要在 load 事件后才调用：部分 TV 浏览器或特定 Android WebView 在页面卸载前会清空性能缓冲区。最晚应在 domContentLoaded 事件后立即采集，更稳妥的做法是使用 PerformanceObserver 监听 resource 类型条目。
• 跨域资源可能缺少完整计时数据：如果 SDK 资源来自第三方域名且未设置 Timing-Allow-Origin: * 响应头，那么 connectStart、requestStart 等字段都会为 0。此时只能依赖 duration 和 startTime 进行粗略估算。
• getEntries() 不包含所有资源：它只返回已触发 complete 或 error 事件的资源。对于动态插入后被快速移除的 script 标签，或主动 abort 的 fetch 请求，该方法会遗漏。需要配合 addEventListener('error', ...) 等监听手段补全信息。

真正的难点不在于获取数据，而在于将一条 resource 条目与具体的 SDK 初始化逻辑对应起来。例如，一个名为 analytics.min.js 的资源，它的 responseEnd 在 1240 毫秒，但实际 eval 执行却拖到 1890 毫秒才完成。此时仅看资源加载时间已无意义，需要借助 PerformanceObserver 监听 longtask（长任务），通过分析执行堆栈反向追查触发耗时操作的代码。这才是性能分析的深水区。