必须结合nexthopprotocol、initiatortype及时序关系定位伪装sdk：动态注入脚本initiatortype为script/fetch，需查域名而非仅.js后缀；重定向资源用responseend-fetchstart算真实耗时；阻塞关键路径需满足requeststartdomcontentloadedeventstart。
第三方 SDK 会真实拖慢首屏，但光看 performance.getEntriesByType('resource') 很难定位它到底卡在哪——必须结合 nextHopProtocol、initiatorType 和资源加载链路的时序关系来交叉验证。
怎么从 resource entries 里揪出“伪装成普通资源”的 SDK
很多 SDK（尤其是埋点、广告、A/B 测试类）不走 <script src></script>，而是用 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 且 <code>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，再用堆栈反查是谁触发了那段代码。
