营销网站上的第三方脚本，哪些该留哪些该删？

你的营销网站上累积了多少第三方脚本？一个网站可能从GA4分析、一个Cookie横幅和一个聊天插件起步。

一两年后，清单可能完全变了样。

有标签管理器、热力图、会话录制、A/B测试、广告像素、CRM集成、聊天机器人、预约工具、同意管理平台、嵌入视频、社交组件、产品分析，以及其他工具。

每一个当初都有存在的理由。

问题在于，浏览器不关心你为什么要加它。

它必须在一个真实访客的设备上下载、解析并执行这些代码。有些第三方脚本会消耗CPU、抢占网络资源、拖慢其他任务，或者给主线程增加工作量。Chrome的性能指南明确把第三方代码列为页面加载和JavaScript开销的重要来源。

这就产生了一个与营销团队是否喜欢某个工具几乎无关的问题。

问题是，这个工具是否仍然配得上它在网站上的位置。

留还是删，判断标准是什么

一个第三方脚本值得保留，通常要同时满足几个条件：有清晰的业务目的、有明确的负责人、能提供有用的数据或功能，并且它的成本对它所运行的页面来说是划算的。

反过来，出现下面任何一种情况，就该考虑移除：没人能解释它为什么存在；它收集的数据没人用；另一个工具已经在做同样的事；它的性能和维护成本超过了它带来的价值。

评估每个脚本时，可以逐条问自己：

• 这个脚本是做什么的？
• 它提供的东西，到底谁在用？
• 它是否影响线索、转化、分析、客户体验，或其他可衡量的业务结果？
• 是否已有另一个工具覆盖了同样的工作？
• 它需要在每个页面上都加载吗？
• 它在性能、隐私、维护和可靠性上的成本是多少？
• 谁对它负责？

如果这些问题答不上来，这个脚本就值得被审计一遍。

为什么太多第三方脚本会成为问题

第三方代码在现代营销网站上很常见。分析平台、广告工具、聊天系统、同意管理、测试平台、嵌入内容等服务，往往依赖从外部域名加载的JavaScript。

这本身并不自动意味着它们不好。

一个把重要转化数据发送到分析平台的脚本，可能值回它的成本；一个同意管理平台，可能是网站处理追踪所必需的；一个预约组件，可能直接支撑销售流程。

问题始于清单在无人审查的情况下不断增长。

营销人员为某次活动加了一个新工具，开发人员装上它的代码片段；半年后另一个团队加了热力图工具；一次改版引入了第二套分析实现；代理商又加了自己的追踪脚本。活动结束了，脚本留了下来。

表面上什么都没坏。

网站还能加载，表单还能用，分析面板里还有数字。

但与此同时，每次有人访问网站，浏览器都在做更多的工作。

Chrome的Lighthouse文档指出，第三方脚本会显著影响页面性能，包括在浏览器主线程上执行的工作量。

这在营销网站上尤其明显，因为第三方脚本清单往往是通过一个个看似合理的小决定累积起来的，而不是某一次明显糟糕的技术选择。

结果就是脚本膨胀。

而当你单独看每一个工具时，这种膨胀很难被察觉。

如何找出网站上的每一个第三方脚本

在决定去留之前，你需要一份完整的清单。

这听起来简单，做起来才知道不容易。

一个脚本可能被直接加到页面上，可能通过Google Tag Manager注入，可能由WordPress插件加载，可能由Webflow集成引入，也可能由另一个第三方工具带进来。只看页面源代码，得到的画面可能并不完整。

要做一次完整的审计，我会从几个角度检查网站。

从浏览器开始

打开Chrome DevTools，进入Network面板。

在Network面板打开的情况下刷新页面，然后按以下条件筛选：

• JS
• Fetch/XHR
• Img
• Doc

JavaScript筛选是显而易见的起点，但别停在这里。一个第三方工具可能先加载JavaScript，再通过XHR或fetch发起额外请求。

看看这些请求来自哪些域名。

你可能会认出一些：

• www.googletagmanager.com
• www.google-analytics.com
• connect.facebook.net
• snap.licdn.com
• static.hotjar.com

也可能发现一些完全陌生的域名。

这些就值得查一查。

这个阶段的目标不是判断脚本好坏，而是先把清单建起来。

检查标签管理器

如果网站用了Google Tag Manager，打开容器逐个审查每个标签。

重点关注：

• 仍在生效的标签
• 名称含义不清的标签
• 旧的营销活动标签
• 重复的分析标签
• 在每个页面上都触发的标签
• 为临时活动创建的标签
• 由前员工或代理商拥有的标签

检查CMS和插件

如果网站运行在WordPress或其他带有集成和插件的CMS上，也要检查这些。

插件可能在无人手动添加脚本的情况下注入追踪代码。

这也是脚本审计应该包括那些负责添加代码的系统、而不仅仅是代码本身的原因之一。

你可能会发现同一个服务通过两条不同路径被加载。

例如：

• GA4直接配置在CMS中
• GTM中还存在另一套GA4实现
• 一个插件又添加了另一个追踪库
• 一个自定义脚本发送额外事件

结果可能同时造成重复数据和不必要的浏览器工作。

衡量第三方脚本的成本

有了清单之后，衡量实际影响。

这时Chrome DevTools和Lighthouse就派上用场了。Core Web Vitals也可以帮助你理解性能问题如何影响访客的实际体验。

Lighthouse有一个专门的第三方摘要，帮助识别第三方资源及其工作量。