如今，第三方资源（例如嵌入式内容和脚本）是在网络上大量使用。他们提供开箱即用的解决方案，可用于嵌入社交媒体、视频、数据分析、实时聊天、广告、A/B 测试、个性化功能等。第三方嵌入是现代网站的必要部分，可让网站所有者专注于其核心能力，同时将标准但关键的功能交给外部提供商处理。
当网页上的第一方和第三方协同工作时，网页就有可能提供出色的用户体验。然而，这需要工程团队和业务团队付出巨大的努力，并且常常被忽视，从而导致网页性能不佳，并对以用户为中心的指标（例如核心网页指标）产生负面影响。这对双方都是不利的，并且会让商家错失良机。我们可以在这方面做得更好吗？
我们对 Web 的未来愿景是：第三方脚本和资源能够提供预期的商业价值，同时尽可能减少在浏览器中使用第三方脚本和资源的网站对性能或用户体验的影响。这将让用户在理想情况下获得更快的页面加载速度。
在过去的一年里，我们考虑、讨论和试验了许多可能性，这些可能既有助于保护用户体验，又能保护用户体验免受第三方脚本的不利影响，同时又不会降低第三方脚本对网站所有者的商业价值。
通过这篇博文，我们希望分享有关我们部分实验的信息。我们希望这是一个有助于提升用户代理、商家和第三方提供商之间的透明度和透明度的流程的起点，为提高网络速度铺平道路。
深入了解第三方
第三方是指网站外部提供商提供的资源。它们并不在网站所有者的直接控制范围内，但会获得批准。第三方资源包括：
- 托管在与主要网站源不同的共享公共源上。
- 并非由个人网站所有者创作或受其影响。
- 被众多网站广泛使用。
从帮助创收（通过广告）到提供更好的营销机会（社交媒体嵌入），第三方可满足各种各样的业务目标。常见的第三方类别包括：
资料来源：第三方（按类别）。
| 类别 | 定义 |
|---|---|
| 广告 | 用于投放广告或衡量广告效果的脚本。 |
| 视频 | 用于实现视频播放器和流式传输功能的脚本。 |
| 托管式库 | 公开托管的开源库的组合。 |
| 内容 | 来自内容提供方或发布商专用联属营销跟踪的脚本。 |
| 客户成功 | 来自提供聊天和联系解决方案的客户服务/营销服务提供商的脚本。 |
| 托管 | 来自网站托管平台的脚本。 |
| 营销 | 营销工具中的脚本，可添加弹出式窗口、简报等。 |
| 社交媒体 | 启用社交功能的脚本。 |
| 跟踪代码管理器 | 可加载许多其他脚本并启动许多任务的脚本。 |
| 分析 | 用于衡量或跟踪用户及其操作的脚本。 |
| Cookie 意见征求平台 | 可让网站以知情且透明的方式征得用户同意（GDPR、ePR、CCPA）的脚本。 |
| 实用工具 | 属于开发者实用程序（API 客户端、网站监控、欺诈检测等）的脚本。 |
| 其他 | 通过共享来源传送的其他脚本，没有精确的类别或提供方说明。 |
借助这些第三方脚本和库，网络开发者可以利用久经考验的解决方案来实现标准功能，而无需重复劳动。因此，第三方可以缩短开发时间，并帮助企业更快地发布或升级其产品。因此，在桌面设备和移动设备上，有超过 94% 的网站使用第三方，也就不足为奇了。
第三方对广告效果有何影响？
理想情况下，第三方开发者应是其提供特定功能的主题专家。大多数主流第三方都已经经历了多次迭代，预计他们的代码会根据自己的业务目标进行优化，这可能包括也可能不包括使用它们的网页的性能。不过，我们知道即使是经过精心优化的第三方也会影响广告效果。以下是造成这种影响的主要原因：
大小和脚本执行成本：第三方通常会力求仅通过将
<script>或<iframe>元素放入网页中来提供重要的功能。然后，这些元素会提取非常大的脚本和资源，并且需要更长的时间来下载和执行。过多的 JavaScript 会使主线程长时间处于忙碌状态、阻止渲染并延迟用户互动。众所周知，一些顶级第三方在所分析的网站上，会阻塞超过 50% 的网站的主线程阻塞 42 毫秒至 1.6 秒。主线程阻塞会导致总阻塞时间 (TBT) 较高，而这是影响网站性能得分的指标之一。此外，这还会延迟对用户互动的响应，并降低用于衡量网站响应能力的 Interaction to Next Paint (INP) 指标。因此，脚本执行开销对性能有重大影响。数量：平均而言，网站在移动设备和网站上会使用大约 21 个不同的第三方。通常，第三方跟踪代码由跟踪代码管理工具添加，这些工具不由技术/开发团队直接控制。对于不需要的标签，其他团队可能会不经审核就添加，并且永远不会移除标签。这会严重影响用户体验、页面重量或 CPU 利用率。建立治理流程可以解决此类情况，并让开发者能够审核每个提供方的影响。如果开发者能够获得所有提供特定功能的第三方提供的现成数据，并说明其对性能的影响、优势和利弊对比，将会很有帮助。团队面临的另一个挑战是，对于许多网站，第三方跟踪代码只能在生产环境中运行，而不会在开发环境中运行，这使得开发者对代码测试更加困难。
网络：由于第三方托管在不同的源上，因此浏览器必须建立更多连接才能从它们下载内容。不同的连接无法根据优先级协调下载，从而导致网络争用。如果得不到适当的优化，这可能会进一步延迟网页加载。
依序运行：第三方可以阻塞主线程，并与带宽争夺更关键的资源。也就是说，在某些情况下，第三方是呈现网页所需的关键资源。当网站使用多个第三方时，必须确保第一方和第三方资源的最佳顺序。Web 开发者应了解可用于优化排序的不同选项。
因此，第三方可能会影响 Core Web Vitals 的任何或所有组件。大多数第三方会对 Largest Contentful Paint (LCP) 和 First Input Delay (FID) 产生负面影响。对于 10% 的移动网站，YouTube 嵌入代码会阻塞主线程 4.5 秒，50% 所研究的网站至少阻塞 1.6 秒。想象一下，如果用户在网速较慢时访问包含 20 个此类脚本的网页，会感到很沮丧。thirdpartyweb.today 中的以下图表显示了目前影响最大的第三方。
“在排名前 400 万的网站中，大约 2, 700 个源占全部脚本执行时间的 57% 左右，而前 50 个实体已经占到了大约 47%。”- 第三方网络
根据核心网页指标所衡量，网页在合理的时间范围内快速呈现且可互动，是实现良好用户体验的关键。良好的 UX 通常能为网站带来良好的业务，而对于使用的第三方而言，可能意味着业务的成功。通过共同努力减少第三方的影响，这对整个链中的各方来说都是双赢的。
我们了解，Google 提供了许多常用的第三方脚本，包括 Google 跟踪代码管理器、YouTube 嵌入式脚本和 reCAPTCHA 等。我们深知，我们的一些脚本可能会对核心网页指标产生轻微的性能影响，因此我们会致力于探索尽可能扩大这种影响的方法。
Chrome 如何提供帮助？
性能不佳的第三方资源一直是开发者面临的一项挑战，需要彻底改变底层生态系统动态。Chrome 希望通过这一领域取得以下成果：
寻找更好的方法来加载 Web 上的第三方资源，同时不影响用户体验或业务成果。
我们知道，如果不与合作伙伴、企业、第三方和开发者合作，我们便无法在这一方面取得长足的进步。我们希望打造一个开放式的领域，通过公开解说和规范来讨论各种可能性，并交流想法。开发者将有时间提供反馈，并测试其中许多提案的影响。
让使用第三方脚本的用户能够更好地归因他们在工具和实际运营方面的费用，提供清晰明了的使用路径，并在编写期间提供更完善的激励措施，确保这些脚本在默认使用下效果最佳。
我们希望增强所有层，例如用户代理、框架和第三方脚本，以降低第三方对性能的影响。此外，我们还打算提供足够的数据分析，帮助网站所有者针对嵌入的每个脚本采用最佳实践，包括更快捷的替代方案（如果适用）。
建议的方法
我们提出了一种三管齐下的方法来实现这些成果...
**让开发者通过 RUM 和 Chrome 开发者工具更深入地归因每个第三方的影响。**
RUM 是指通过网站性能监控 API 提供的真实用户指标数据（也称为“实测数据”）。Chrome 的开发者工具包括 Lighthouse、Chrome 开发者工具和 Chrome 用户体验报告。我们提议完善可用的 API 和工具，以便网站开发者了解他们在每个网页上使用的每一个第三方的影响。这些工具还将告知他们可采取哪些措施来减轻影响（例如，推迟它们或使用Facade），并探索其他潜在解决方案（其他第三方或 DIY），并做出取舍。对于 Web 性能监控 API，我们正在探索如何扩大跨源资源的覆盖范围，同时又不会危及用户的隐私和安全。
**为企业提供顺畅的途径，使其高效加载第三方资源。**
我们希望提出一些新标准，从而鼓励浏览器更智能地权衡第一方和第三方资源的加载方式，从而为用户带来更好的加载体验。稍后，我们将重点介绍其中一些方案，例如默认延迟加载第三方嵌入，或者对第三方资源应用不同的资源优先级，而这些资源对初始内容而言可能并不重要，用户最关心的则是。这些只是我们正在评估这一领域的一小部分想法，希望能与网络性能专家和广大社区成员合作，共同完成这项工作。
同样，我们也希望适时解决 JavaScript 框架和内容管理系统 (CMS) 中的此类问题。Aurora 和 WordPress 性能团队等项目向我们证明了内置默认设置的重要性，这些默认值能够解决已知的加载问题。默认值内置于框架中，CMS 可引导企业顺利发展。此外，这些标记对于用户代理（例如 Chrome）也很有用，可以作为提示，允许其应用启发法来优化网页加载和 CWV。此类提示可以帮助用户代理决定特定第三方在网页生命周期中的何时加载以及如何加载。（例如，Next.js 脚本组件就具有内置默认值，即在网页进入可交互状态后加载第三方脚本。）
**向第三方提供激励措施，通过提高透明度努力降低其对效果的影响。**
第三方开发者目前无法了解其脚本对大型网站的影响。我们计划解决这一问题，并为这些提供商提供工具，用于分析他们的影响，并将其与市场上提供相同价值的其他产品进行比较。我们还希望帮助他们利用这些数据来诊断造成影响的原因，以便他们能够在上游减轻影响。我们必须召集所有第三方（包括由 Google 授权的第三方）才能取得成功。
挑战
如此大规模的努力绝非易事。我们必须考虑的一些主要挑战包括：
- 第三方是一个涉及广告、分析、代码管理、实用程序以及其他许多问题，涉及众多问题。每个方面都需要考虑一系列独特的要求和权衡。例如：
- 决定优化广告加载时，需要在收入与用户体验之间进行权衡取舍。过早屏蔽有价值的内容，太晚了，用户会错过他们。
- Google Analytics（分析）脚本会增加页面权重，但可以为商家提供有价值的用户操作数据。
我们希望与各类第三方合作，了解相关的细微差别，解决权衡取舍问题，并制定适用于所有人的激励措施。我们认识到，为了使我们的策略有效，我们必须与各个领域的实体分别开展合作。其中包括我们的内部合作伙伴，例如 Google 跟踪代码管理器、Google Ads 和 YouTube。
我们希望为网站开发者和第三方开发者提供更深入的归因结果。这需要认真努力，确定哪些数据在衡量影响方面最为相关，准确、细致地进行归因，并提供正确的前进道路。归根结底，指定第三方与竞争对手的广告效果的计算结果应向所有人公开。
我们提议增强 Chrome 的功能，以便它能够应用各种优化措施，从而在优先加载第一方资源和第三方资源时取得适当的平衡。一项有价值的更改成为所有浏览器的标准，但需要时间。例如，从 2019 年起，
<img>和<iframe>元素的loading属性在 Chrome/Edge 中可用，但 2022 年仅在 Safari 中可用。在功能标准化之前，使用第三方资源的用户必须确保已针对其他浏览器进行优化。我们将在相关指南中强调这一点。为了执行该项目，我们必须与合作伙伴和开发者合作，这不仅要帮助我们了解具体要求，还要根据需要大规模测试实验性解决方案、提供反馈、迭代和即兴发挥。这些变化必须有计划地进行，为测试和评估留出合理的时间。
初始标准提案
我们已经执行了一些初始实验，以开发可启用以优化第三方加载流程的功能。我们对观察到的结果很满意，现在可以讨论其中的两项功能。
LazyEmbeds
以前，Chrome 会为精简模式用户延迟加载屏幕外的 <img> 和 <iframe> 元素。您可将此功能扩展到所有用户，以便将确定为第三方嵌入的 <iframe> 元素推迟到用户在其附近滚动时加载。这可以加快网页其他部分的加载速度、改进 Core Web Vitals、减少内存用量并节省流量。
此处演示了使用 LazyEmbeds 延迟加载网页上的 YouTube 视频。单次嵌入的 YouTube 视频通常会向网页增加 500-600KB 的 JavaScript。我们尝试使用 LazyEmbeds 优化包含 14 个这些视频嵌入的博文。其结果非常理想，在网页加载时间和节省流量方面都取得了理想效果。
| 之前 | 之后 | |
|---|---|---|
| 数据 | 15.4 MB | 6.1 MB |
| Total Blocking Time | 3.2 秒 | 1.6 秒 |
如需详细了解这项工作，请参阅我们的解释器和 blink-dev intent-to-experiment 线程和实验扩展程序。
有针对性的第三方节流
第三方脚本往往由多个团队添加，没有全面的监督流程。《The Telegraph》的工程团队表示，“每个人都希望在一个网页上添加‘该代码’代码，从而使组织能够获利”。这可能会持续增加管理对效果影响的负担。
有针对性的第三方脚本节流措施旨在限制非常具体类型的第三方，以减轻其影响。这样一来，浏览器便能够提前加载关键内容和关键第三方，而可以稍后安全加载的内容则会受到限制。
增强 RUM API
我们还在考虑改进 RUM API，以纳入与评估第三方表现相关的信息。增强功能包括：
<iframe>报告：我们正在开发能够利用 Performance Timeline API 进行跨帧报告的解决方案。这样，顶级网页的作者就可以检查网页上嵌入的合作第三方 iframe 的性能数据。长任务归因：RUM 中的 Long Tasks API 有助于网站所有者识别那些占用主线程长时间并延迟互动的耗时较长任务。
进一步更新
我们仍在尝试许多这样的想法，并希望随着我们一起推进更改的发布，发布 GitHub 说明文档和规范草案。希望与我们合作或提供反馈的第三方和网站所有者可以通过这些方式参与讨论。第三方还可以开始专注于针对 Core Web Vitals 和 INP 指标进行优化，以确保不会将糟糕的核心网页指标/INP 数据归因于此类指标。目前，主动查找更新的用户可以参阅 blink-dev 论坛上的帖子。
我们期待着进一步探索此问题领域，并与社区成员交流经验。
特别感谢 Leena Sohoni-Kasture、Jeremy Wagner、Gilberto Cocchi、Kenji Baheux、Kouhei Ueno、Kentaro Hara、Alex N. Jose、Melissa Mitchell、Yoav Weiss、Shunya Shishido 和 Minoru Chikamune，非常感谢他们的反馈和贡献。