如何优化 HTML 中的第三方 iframe 和脚本嵌入？

结论先行：第三方 iframe 和脚本的优化只有三条主线——**把它挪出关键渲染路径、把它的执行推迟到用户真正需要时、把它的权限和字节量压到最低**。做到这三点，LCP 通常能改善 20%–40%，TBT（总阻塞时间，衡量主线程被长任务卡住的时长）能降一半以上，因为第三方 JS 往往是长任务的第一大来源。

第三方脚本怎么加载才不阻塞渲染？

结论：async 和 defer 是底线，动态注入 + 空闲回调是进阶，能用 Web Worker 就跑在 Worker 里。

先分清两个属性：<script async> 下载完立刻执行，执行时会暂停 HTML 解析；<script defer> 下载完成后等到 DOM 解析结束、DOMContentLoaded 之前按顺序执行。统计类、客服挂件类脚本一律加 defer 或 async，绝不要保留无属性的同步 <script src="https://third-party.com/x.js">，那是直接的渲染阻塞源。

更彻底的做法是延迟到用户有交互倾向时再加载：

const load = () => {
  const s = document.createElement('script');
  s.src = 'https://third-party.com/chat.js';
  s.async = true;
  document.head.appendChild(s);
};
addEventListener('scroll', load, { once: true, passive: true });
// 或 requestIdleCallback(load, { timeout: 3000 })

对纯统计类脚本（GA、埋点），可以整段移到 Web Worker 里执行，Partytown 就是干这个的：把脚本改成 <script type="text/partytown" src="...">，主线程只剩一个转发层，长任务基本清零。

iframe 怎么优化？懒加载和「门面模式」哪个更值？

结论：视频、地图、社交插件的 iframe，优先用门面（facade）——先渲染一张静态图，用户点击才注入真正的 iframe，收益比单纯 loading="lazy" 大一个量级。

loading="lazy" 是最低成本的一步，Chrome 从 77 版起支持，对 iframe 的预加载距离约为视口外 8000px（图片在快速网络下只有 1250px），所以首屏之外的 iframe 基本上不会在加载期被请求：

<iframe src="https://www.youtube.com/embed/xxx" loading="lazy"
        width="560" height="315" title="视频" allowfullscreen></iframe>

但首屏内的 YouTube 嵌入会一口气拉进播放器 JS、样式和字体，量级在千 KB 以上。门面模式的做法是先放一张缩略图，把需要下载的资源压到几十 KB：

<button class="video-facade" aria-label="播放视频">
  <img src="/thumb.webp" width="560" height="315" alt="">
</button>
<script>
document.querySelector('.video-facade').addEventListener('click', () => {
  const f = document.createElement('iframe');
  f.src = 'https://www.youtube-nocookie.com/embed/xxx?autoplay=1';
  f.allow = 'autoplay; encrypted-media';
  f.title = '视频';
  document.querySelector('.video-facade').replaceWith(f);
}, { once: true });
</script>

顺带提醒两点：youtube-nocookie.com 域少发一类 cookie；iframe 加上 sandbox="allow-scripts allow-same-origin" 和 allow（Permissions Policy，限制摄像头、地理位置等能力）能同时降风险和降开销。

怎么量化第三方代码到底拖了多少后腿？

结论：用 Lighthouse 的「减少第三方代码的影响」审计和 DevTools Performance 面板的 Third-party 分组看具体字节数与阻塞时长，改动前后各测一次，别凭感觉。

具体操作：Chrome DevTools → Performance → 录制时勾选「Web Vitals」，在底部「Bottom-Up」把分组切到「Third-party」，能看到每个域名的 CPU 时间、脚本求值耗时和长任务数量。同一页面的 Lighthouse 报告会直接列出「第三方代码摘要」，包括主线程阻塞时间（ms）和传输字节数。

线上还想持续监控的话，用 PerformanceObserver 抓长任务：

new PerformanceObserver(list => {
  list.getEntries().forEach(e => {
    if (e.duration > 50) console.log('longtask', e.duration, e.attribution);
  });
}).observe({ entryTypes: ['longtask'] });

注意：longtask 只统计超过 50ms 的主线程任务，这正是 TBT 的计算口径。

加载之前还能先做什么？

结论：把连接建立提前、把能用自己域名托管的资源搬回来，这两步几乎零成本。

在 <head> 里对确实会用到的第三方域名加 <link rel="preconnect" href="https://third-party.com" crossorigin>，浏览器会提前完成 DNS 解析、TCP 握手和 TLS 协商；对不那么确定会用到的域名先只加 <link rel="dns-prefetch">，别滥加 preconnect，每个连接空闲 10 秒会被关闭，开太多反而抢带宽。

同时做三件事收紧边界：一是把字体、公共库这类稳定资源自托管，少一个 DNS 就少一次握手；二是对允许的第三方加 SRI 校验，<script src="..." integrity="sha384-..." crossorigin="anonymous">，内容被篡改会直接拒绝执行；三是用 CSP 的 script-src、frame-src 白名单，从策略层面禁止未经批准的嵌入——顺带把 <iframe> 的数量控制住，每多一个 iframe 都是独立的文档环境和内存开销。

总结一下：脚本先 defer 再考虑延迟加载、纯统计类丢进 Worker；iframe 首屏内的走门面模式、首屏外的交给 loading="lazy"；量化靠 DevTools Third-party 分组和 longtask 观测；加载前用 preconnect 抢时间、用 SRI 和 CSP 划边界。第三方资源不是不能要，但要让它在用户需要的那一刻才付出代价。