第三方脚本的成本不出现在账单里，它出现在两个地方：首屏阶段被抢走的带宽，和交互阶段被占住的主线程。这不是"某个组件写得烂"的问题，而是接入方式的问题——同一段脚本，位置不同、触发时机不同、要不要先用一个静态图替身，结果完全不同。先量清楚账单，再谈删哪一条。
成本落在哪两个地方
web.dev 讲标签与标签管理器最佳实践的那一页把这件事说得很直白：带宽可能花在下载标签管理器的脚本以及它发出的后续请求上，CPU 时间可能花在解析和执行这些脚本上。同一页还给了两条判断依据：首屏加载期间 LCP 容易受到带宽争抢的影响，INP 容易受到主线程 CPU 争抢的影响，并且明确提到标签管理器规模与较差的 INP 得分之间存在相关。
所以一条聊天窗脚本的影响路径通常是：它先占掉一段首屏带宽，再在用户点它的时候占用主线程——同时踩中 LCP 和 INP 两项。它不像图片那样只影响一项，处理时要按"两个指标都算账"来评估。
第一步：把清单拉出来
优化之前先做盘点，顺序不能反。web.dev 提过一条容易被跳过的现实原因：给每个标签标上负责人，因为"怕删坏了"而不敢动手，是这类清理长期做不下去的最常见阻碍。
- 列出页面上所有第三方请求的域名，按来源归类：统计、客服聊天、视频与地图、社交挂件、支付与登录。
- 每一条标注三件事：它在首屏吗、它执行 JS 吗、它由谁负责。
- 用工具的第三方代码审计项看每家的体积和主线程阻塞时长；官方文档提到那个审计会列出页面用到的第三方及其体积与阻塞时间。
- 把"业务上到底有多少人用"也标上——这是后面决定删还是延迟的依据。
四种控制手段，按代价从低到高
web.dev 讲第三方嵌入最佳实践的那一页给了四类做法，可以直接当处理顺序用。
- 调顺序：页面执行脚本时 DOM 构建会暂停，所以第一方内容先走。把第三方脚本标签放在关键一方标签之后，并加上异步或延后加载属性。
- 延后加载：官方给的量级参考是：很多常见嵌入的 JS 超过 100 KB，个别能到 2 MB；而给一个视口外的播放器 iframe 加上浏览器自带的延后加载，初始页面大约能省下 500 KB。这类内容本来就在首屏之下，等用户滚到附近再取是白捡的收益。
- 用静态替身：多数访客并不会真的去操作地图或聊天窗。先放一张长得像它的静态图或一个按钮，等访客悬停或点击时再连接第三方源、再替换成真实组件；实在不行就只给一个跳转链接。视频播放器是这条最典型的场景。
- 直接移除：前三项都不适用时，把嵌入换成指向第三方页面的链接，是最省事的收尾。
顺带解决布局稳定性：给所有 iframe 写死宽高，或给容器写死最小高度，让迟到的组件有地方落。这条同时压住 CLS。
什么情况下不要动它
四种情况先别碰。一是它承担着转化职能而你还没有替代路径——在线客服下线、询盘表单移除这类改动要先想清楚谁来接。二是它属于合规或结算必需（支付、登录、统计口径），动它要连带改流程。三是替换成静态替身会明显损害可用性（比如需要连续操作的功能），那就不该替身。三是触发条件本来就很窄的标签，比如只在特定页面、特定按钮点击后才触发，本来就不占首屏，收益小于改动风险。那篇最佳实践里的原话是：优化触发条件的关键就是别让它在不必要的时候触发，同时选一个在业务需要与性能代价之间平衡的触发点——把"全部页面全量触发"改成"这些页面才触发"，往往比任何代码优化都划算。
怎么验证控制住了
先做一次前后对照：同一页面、同一设备档位、同一时段各跑一次，比三样东西——首屏的第三方请求总字节数、主线程被第三方占用的时长、以及 CLS 有没有同步下降。真实数据那侧按 URL 分组看状态，确认移动与桌面两端都没有被牺牲。
还要做一次功能核对，这类改动最容易在这里翻车：逐个点开被延后或被替身替换的组件，确认点下去真的能加载出真实内容，客服窗口能正常唤起，播放器能正常播放。控制性能不能以功能失灵为代价。
顺带一句边界：这些手段影响的是 LCP、INP、CLS 三项核心网页指标，web.dev 的口径说明里它们按第 75 百分位衡量、移动与桌面分开、LCP 2.5 秒、INP 200 毫秒、CLS 0.1；这是建议性的体验目标，官方没有公布与搜索排名的换算关系，别当成排名开关。站内两篇旧文可以当背景读：为 SEO 关闭 WordPress REST API 前要先查依赖说明"关掉之前先核对还有谁在用"是同一条纪律，加速先选插件还是调服务器则解释了缓存、CDN 与动态页面各自的分工。
