<p>第三方脚本卡在 DNS 或 TLS 握手阶段需通过 PerformanceObserver 监听 resource 类型，重点分析 domainLookupEnd - domainLookupStart 和 connectEnd - connectStart 耗时；若 domainLookupStart 或 connectStart 为 0，说明缺失 Timing-Allow-Origin: *，需用 preconnect 补救；async 适合完全独立脚本，defer 适合需操作 DOM 且不依赖其他 async 脚本的组件；preconnect 必须置于 head 最顶部、协议与域名严格匹配并配合 crossorigin 属性；动态加载必须设 AbortSignal.timeout(3000) 并做 fallback 处理。</p>
第三方脚本卡在 DNS 或 TLS 握手阶段怎么查
不是脚本本身执行慢，而是它连不上——多数性能瓶颈发生在 domainLookupStart 到 connectEnd 这一段。浏览器没拿到 IP 就卡住，后续所有步骤都得等。
- 用
PerformanceObserver监听"resource"类型，比performance.getEntriesByType("resource")更可靠，尤其对 SPA 中动态插入的脚本 - 重点看字段：
domainLookupEnd - domainLookupStart（DNS 耗时）、connectEnd - connectStart（TCP+TLS 握手），超过 200ms 就该怀疑跨域预连缺失 - 若
domainLookupStart或connectStart是0，说明服务端没配Timing-Allow-Origin: *，这些字段不可信，得靠preconnect补救
async 和 defer 在第三方脚本里到底谁更稳
选错属性不会报错，但会直接导致功能失效或白屏——比如 analytics.js 用 defer 却依赖 window.dataLayer 初始化，而后者是 async 加载的，大概率 ReferenceError。
-
async：只适合完全独立、不读写 DOM、不依赖其他 JS 的脚本，例如umami.js、plausible.js；执行时机不可控，可能早于document.body存在 -
defer：适合需操作 DOM 的第三方 UI 组件（如客服浮窗），但必须确保它不依赖其他async脚本；多个defer脚本按顺序执行，这是唯一能保序的方式 -
async和defer对内联脚本（<script>console.log()</script>）无效，只对带src的外链生效
为什么加了 preconnect 还是慢
写了 <link rel="preconnect" href="https://www.googletagmanager.com"> 却没效果，大概率是位置或协议写错了。
- 必须放在
<head>最顶部，越早声明，浏览器越早发起预连接；放错位置（比如在 CSS 后面）会延迟触发 - href 必须和脚本实际域名完全一致，包括协议：用
https://，别漏掉s；HTTP 域名无法预连 HTTPS 资源 - 跨域资源若没配
crossorigin属性，即使加了preconnect，浏览器也会忽略——<script src="https://cdn.example.com/analytics.js" crossorigin></script>
动态加载第三方脚本时容易漏掉的超时控制
手动 document.createElement('script') 看似可控，但一旦第三方 CDN 挂了或网络超时，主线程就卡死，页面假死。
立即学习“前端免费学习笔记（深入）”；
- 必须设
AbortSignal.timeout(3000)，避免无限等待；现代浏览器支持，旧版可用setTimeout+script.onerror降级 - 加载失败后要有 fallback：比如记录错误、上报监控，而不是静默失败；用户点击「帮助」才加载客服 SDK，失败了至少得显示一个静态按钮
- 不要在
load回调里直接调初始化函数，先检查全局变量是否存在（如typeof gtag !== 'undefined'），防止脚本加载完成但执行异常
真实瓶颈往往藏在 DNS 和握手阶段，而不是代码执行；预连和超时控制不是“锦上添花”，而是防止第三方拖垮整个页面的底线措施。
