2026 年 7 月我们给一个 SaaS 站清点第三方脚本，23 个域，占了主线程接近一半的时间。逐个查完，其中 9 个从上线到现在没有产生过任何转化，也没人说得清是谁加的。
先清点，别先优化
打开 DevTools 的 Network 面板，按域名分组，把第三方域列出来。再看每个脚本的体积、加载时机、执行耗时。
更省事的办法是用 Lighthouse 的第三方汇总，它会把每个域占用的主线程时间列出来，排序很清楚。
清点这一步最容易被跳过，但它是唯一能发现“没人知道这脚本干嘛”的步骤。
分三类处理
第一类，必须有。统计、客服、支付、登录。这些直接支撑业务，不能砍，但可以调加载方式。
第二类，有时用。A/B 测试、热图、会话录制。项目期间开，项目结束关掉，别一直挂着。
第三类，可以砍。营销像素、聊天插件、推荐组件、社交分享按钮。这类东西装的时候都觉得有用，一年后没人记得。
加载时机怎么调
统计脚本用 defer，别阻塞。
客服插件改成用户点击或者滚动到一定位置再加载，首屏完全不加载。
A/B 测试脚本尽量自托管，减少一次 DNS 和 TLS。
视频、地图、评论这类嵌入内容，用一个占位图代替，用户点击后再加载真实内容。
一个具体数字
客服插件是第三方脚本里最重的，常见体积 200 到 400KB，还要建立 WebSocket 连接。
我们给一个站把它改成延迟加载之后，主线程阻塞时间减少了 380 毫秒，首屏 LCP 提前了 200 多毫秒。
这个改动只花了半天，比重构业务代码划算得多。
治理要有规则
第一，新加任何第三方脚本要报备，写清用途、体积、加载方式。
第二，季度审计一次，把没产生价值的清掉。
第三，上线前设预算，第三方脚本总执行时间不超过 500 毫秒，超了要评审。
没有规则，脚本只会越来越多。三年后你会发现站上跑着四十个脚本，没人敢删。
一个常见的反对意见
“这个脚本是市场部要的”。这句话我们听过很多次。处理办法不是争论，是把主线程耗时和转化数据放在一起给对方看。
如果脚本确实在产生线索，留着；如果一年零转化，市场部自己也会同意关掉。
一个态度
第三方脚本治理是性能优化里性价比最高的一件事，因为它不需要改业务代码，只要做减法。
但它需要跨部门协调，因为每个脚本背后都有人负责。这也是它经常被搁置的原因。
我们的做法是先出一份清单，标出每个脚本的主线程耗时和最近一次带来的转化，让数据说话。清单摆出来，砍哪个不用我们开口。
元析智能
为软件公司做 SEO 和 GEO 优化