在优化第三方代码之前，请确保您的网站仍然需要这些脚本。
第三方脚本或“代码”可能是您网站上性能问题的根源，因此也是优化的目标。但是，在开始优化已添加的代码之前，请确保您没有优化根本不需要的代码。本文介绍了如何评估新代码的请求，以及如何管理和审核现有代码。
在讨论第三方代码时，对话通常很快转向性能问题，而忽略了这些代码“核心”作用的基础。它们提供广泛有用的功能，使网络更具活力、互动性和互联性。但是，第三方代码可能由组织内的不同团队添加，并且随着时间的推移经常被遗忘。人员变动、合同到期或结果产生，但团队从未再次联系以删除脚本。
在您开始从技术角度考虑第三方代码脚本的执行，或哪些代码可以延迟、延迟加载或预连接之前，从组织的角度来看，有机会管理哪些代码被添加到网站/页面。由于大量第三方代码而导致网站速度变慢的常见主题是，网站的这部分不属于单个人或团队，因此被忽视了。没有什么比优化您的网站，对暂存环境中的性能感到满意，但由于正在添加的代码而导致生产环境中的速度下降更令人沮丧的了。实施第三方代码的“审查流程”可以通过构建一个工作流程来防止这种情况，该工作流程为这些代码创建跨职能的问责制和责任。
您审查第三方代码的方式完全取决于组织、其结构和当前流程。它可以像有一个团队来管理并充当代码添加前的分析把关人一样简单。或者更高级和正式，例如通过向团队提供表格来提交代码请求。这可能会要求提供背景信息，说明为什么需要将其放在网站上、应该存在多长时间以及它将为业务带来什么好处。
代码治理流程
无论您选择如何在组织内审查代码，都应将以下阶段视为代码生命周期的一部分。
合规性
在将任何代码添加到页面之前，请检查法律团队是否已对其进行彻底审查，以确保其符合所有合规性要求。这可能包括检查代码是否符合欧盟通用数据保护条例 (GDPR) 和加州消费者隐私法案 (CCPA)。
这至关重要，如果对此步骤有任何疑问，则需要在从性能角度评估代码之前解决。
必需
第二步是质疑页面上是否需要特定的代码。考虑以下讨论要点
- 代码是否正在积极使用？如果不是，可以删除吗？
- 如果代码正在全网站加载，这是必要的吗？例如，如果我们正在分析 A/B 测试套件，而您目前仅在着陆页上进行测试，我们是否可以仅在此页面类型上放置代码？
- 我们可以为此添加更多逻辑吗，我们可以检测是否存在正在进行的 A/B 测试吗？如果是这样，允许添加代码，但如果不是，请确保它不存在。
所有权
拥有明确的个人或团队作为代码的所有者，有助于主动跟踪代码。通常这将是添加代码的任何人。通过在代码旁边设置受让人，这将确保将来可以进行审查和审核，以重新访问是否需要该代码。
目的
第四步开始通过确保人们了解为什么将代码添加到页面来创建跨职能的问责制和责任。重要的是，要对每个代码为网站带来什么以及为什么要使用它有一个跨职能的理解。例如，如果代码正在记录用户会话操作以允许个性化，那么所有团队都知道为什么应该存在此代码吗？
此外，是否进行过任何商业与性能权衡的讨论？如果某个代码因带来收入而被视为“必需”，是否已分析过因速度下降而可能造成的收入损失
审核
第五个、也是最后一个，可以说是最重要的步骤是确保定期审核代码。这应取决于网站的大小、网站上的代码数量及其周转时间（例如，每周、每月、每季度）。这应以与优化其他网站资产（JS、CSS、图像等）相同的方式处理，并定期主动检查。未能审核可能会导致“臃肿”的代码管理器，从而降低页面速度。在不降低页面上所需功能的情况下恢复到高性能可能是一项复杂的任务
审查流程应为您提供最终的代码列表，这些代码被归类为特定页面所需的代码。在此阶段，您可以深入研究技术优化方法。这也为在性能预算中定义此最终列表中的代码数量提供了机会，可以在Lighthouse CI中对其进行监控，并将其纳入特定于性能的目标设置中。例如
如果我们坚持在着陆页上使用少于 5 个代码以及我们自己的优化 JS，我们相信总阻塞时间 (TBT)可以在Core Web Vitals中达到“良好”水平。