延迟加载三方脚本且不弄坏其功能

审计每个外部脚本在关键路径上的开销，把分析与挂件挪到交互后加载，并验证事件照常到达。

目标

六个急加载的三方脚本在访客看到内容前先吃掉 340KB JavaScript，而其中大多数功能整个会话都没被用到。按“何时真正需要”分类加载——分析类空闲时、聊天类点击时、营销类首交互时——所有功能保持可用，页面却先渲染。配合队列重放保住数据，配 CSP 加 SRI 顺带更安全。

步骤要点

审计每个三方脚本：网络面板按体积排序加 Performance 长任务归属，形成每家体积与阻塞时间的成本表。
分三类处置：分析类用 requestIdleCallback 两秒超时在首绘后加载；聊天类做点击激活门面，零字节直到访客要求；任何三方脚本都不得出现在 class C 首绘必需里。
保数据契约：window.dataLayer 式队列在 SDK 到达前缓存事件，analytics:ready 事件触发时 splice(0) 全量重放，延迟不丢数据。
加固：CSP script-src 白名单只许指定厂商域，脚本标签加 SRI 完整性哈希，被投毒的 CDN 只会交付加载失败而不是执行任意代码。
双向验证：Performance 面板对比 LCP 与长任务清零；打开聊天门面确认挂件初始化；厂商调试视图确认队列事件全部到达；CSP 报告端点无被误拦的必需脚本。

排错提示

厂商脚本要求 document.write 或同步占位就没法直接延迟，把它装进门面点击或沙箱 iframe 让遗留行为阻塞不了宿主页，同时找厂商要现代构建；延迟期间的事件没到达是队列没重放，确认 SDK init 会派发 ready 事件、flush 用 splice(0) 且打日志记录冲洗时队列长度；营销方坚持要急加载做归因就改成首次交互（任意点击或滚动）再加载，归因窗口几乎不丢而初始路径干净，用数字谈成妥协。

适用边界

延迟的脚本终究会跑，低端设备的 CPU 开销只是推迟不是消失，三方字节总量仍要守住预算；门面模式轻微改变交互（点击才加载），文案与预期要和产品对齐后再上。

代码示例

audit (before):
  vendor-a analytics   92KB  blocks 610ms   never needs eager
  vendor-b chat       140KB  blocks 890ms   needed on click only
  vendor-c marketing  108KB  blocks 540ms   needed on interaction
  LCP 3.4s, 4 long tasks from vendor frames

after (idle + facade + queued events):
  initial third-party bytes: 0KB
  analytics: requestIdleCallback, 2s timeout
  chat: click facade -> 1.2s to interactive
  marketing: first scroll/click
  LCP 1.5s, zero long tasks
  GA4 DebugView: page_view + signup events arrived (replayed)