浏览器能否优化第三方资源的加载?

如今,第三方资源(例如嵌入内容和脚本)在网络上被广泛使用。它们提供开箱即用的解决方案,可嵌入社交媒体、视频、分析、实时聊天、广告、A/B 测试、个性化等内容。第三方嵌入是现代网站的必要组成部分,可让网站所有者专注于自己的核心竞争力,同时将标准但关键的功能交由外部提供商。

当网页上的第一方和第三方代码协同工作时,网页就有可能提供出色的用户体验。不过,这需要工程团队和业务团队付出大量努力,并且经常被忽视,导致网页性能不佳,并对以用户为中心的指标(例如核心网页指标)产生负面影响。这对双方都有害,并会导致企业错失商机。我们能否在这一点上做得更好?

我们对 Web 的未来有自己的愿景:第三方脚本和资源能够提供预期的业务价值,同时尽可能减少对在浏览器中使用这些脚本和资源的网站的性能或用户体验的影响。这样一来,用户就可以获得更快的网页加载速度。

在过去一年中,我们考虑、讨论和实验了许多可能的方法,这些方法有望在不降低第三方脚本对网站所有者而言的业务价值的情况下,保护用户体验免受第三方脚本的不利影响。

我们希望通过这篇博文分享一些实验的相关信息。我们希望这只是一个开端,它将鼓励用户代理、企业和第三方提供商之间实现透明化和可见性,为实现更快的网络铺平道路。

深入了解第三方

第三方是指由网站外部提供商提供的资源。这些广告不是由网站所有者直接控制的,而是在获得其批准后展示。第三方资源包括:

  • 托管在与主要网站源不同的共享公共源上。
  • 不是由单个网站所有者撰写或受其影响。
  • 被各种网站广泛使用。

第三方可帮助您实现各种各样的业务目标,从帮助创收(通过广告)到提供更好的营销机会(社交媒体嵌入),不一而足。常见的第三方类别包括:

来源:按类别划分的第三方

类别 定义
广告 用于投放广告或衡量广告效果的脚本。
视频 用于启用视频播放器和流式传输功能的脚本。
托管库 混合使用公开托管的开源库。
内容 内容提供方脚本或发布商专用联属营销跟踪脚本。
客户成功案例 提供聊天和联系解决方案的客户支持/营销服务提供商提供的脚本。
托管 来自网站托管平台的脚本。
营销 用于添加弹出式窗口、简报等的营销工具脚本。
社交 用于启用社交功能的脚本。
跟踪代码管理器 用于加载许多其他脚本和启动许多任务的脚本。
分析 用于衡量或跟踪用户及其操作的脚本。
Cookie 意见征求平台 允许网站以知情且透明的方式征求用户同意(GDPR、ePR、CCPA)的脚本。
实用工具 作为开发者实用程序的脚本(API 客户端、网站监控、欺诈检测等)。
其他 通过共享来源提交的各种脚本,没有确切的类别或归因。

借助这些第三方脚本和库,Web 开发者可以利用经过验证的解决方案来实现标准功能,而无需重新发明轮子。因此,第三方可以缩短开发时间,帮助企业更快地发布或升级产品。因此,桌面版和移动版网站中超过 94% 的网站都使用第三方。

第三方对性能有何影响?

理想情况下,第三方开发者是他们提供的特定功能的主题专家。大多数热门第三方代码都经过了多次迭代,预计其代码会针对自己的业务目标进行优化,这些目标可能包括或不包括使用这些代码的网页的性能。不过,我们确实知道,即使是最优化的第三方代码也会影响性能。造成这种影响的主要原因如下:

  1. 大小和脚本执行开销:第三方通常希望仅通过在您的网页中插入 <script><iframe> 元素,即可提供重要的功能。然后,这些元素会提取大小较大且下载和执行时间较长的脚本和资源。JavaScript 过多会使主线程保持较长时间的繁忙状态,阻塞渲染并延迟用户互动。我们发现,在所分析的网站中,超过 50% 的网站的主线程被一些热门第三方阻塞了 42 毫秒到 1.6 秒。主线程处于阻塞状态会导致 Total Blocking Time (TBT) 较高,而该指标是影响网站性能得分的一个指标。此外,它还会延迟对用户互动的响应,并降低用于衡量网站响应速度的 Interaction to Next Paint (INP) 指标。因此,脚本执行费用对性能有很大影响。

  2. 数量:平均而言,网站在移动网站和网站上使用大约 21 个不同的第三方。第三方代码通常由跟踪代码管理工具添加,这些工具不受技术/开发团队的直接控制。其他团队可能会添加不需要的标记,而无需经过审核流程,并且这些标记永远不会被移除。这些问题可能会严重影响用户体验、网页大小或 CPU 使用率。建立治理流程可以解决此类情况,并允许开发者审核每个提供商的影响。如果开发者能够为提供特定功能的所有第三方提供相关数据,并说明这些功能对性能的影响、优势和权衡,将有助于进行比较。团队面临的另一个挑战是,对于许多网站,其第三方代码仅在生产环境中运行,而不会在开发环境中运行,这使得开发者更难以对其进行测试。

  3. 网络:由于第三方托管在不同的来源上,因此浏览器必须建立更多连接才能从中下载内容。不同的连接无法根据优先级协调下载,从而导致网络争用。如果未考虑适当的优化,这可能会进一步延迟网页加载。

  4. 排序:第三方可能会阻塞主线程,并与带宽争夺更重要的资源。不过,在某些情况下,第三方是呈现网页所需的关键资源。当网站使用多个第三方时,就必须对第一方和第三方资源进行最佳排序。网站开发者应了解可用于优化排序的不同选项

因此,第三方可能会影响 Core Web Vitals 的任一或所有组成部分。大多数第三方都会对 Largest Contentful Paint (LCP)First Input Delay (FID) 产生负面影响。在所研究的移动网站中,有 10% 的网站的 YouTube 嵌入内容会阻塞主线程 4.5 秒,50% 的网站至少会阻塞 1.6 秒。假设用户在网络连接缓慢的情况下访问了一个包含 20 个此类脚本的页面,那么他们会感到非常沮丧。thirdpartyweb.today 中的以下可视化图表显示了目前对性能影响最大的第三方。

第三方网站可视化

“在前 400 万个网站中,大约 2700 个来源占据了所有脚本执行时间的约 57%,前 50 个实体就已占据了约 47%”。- third-party-web

根据核心网页指标衡量,网页能够快速呈现并在合理的时间范围内变为可交互状态,对于提供良好的用户体验至关重要。良好的用户体验通常会为网站带来良好的业务,这可能也意味着所使用的第三方会获得良好的业务。携手合作降低第三方的影响,对整个供应链中的所有人来说都是双赢。

我们承认,Google 会销售一些常用的第三方脚本,包括 Google 跟踪代码管理器、YouTube 嵌入代码和 reCAPTCHA 等。我们承认,我们的许多脚本对核心网页指标的性能影响可能较小,我们会致力于探索尽可能减少这种影响的方法。

Chrome 可以提供哪些帮助?

第三方资源的性能通常会给开发者带来挑战,需要对底层生态系统动态进行重大改变。Chrome 希望探索此领域,以实现以下目标:

  1. 找到更好的方式在网络上加载第三方资源,同时不会降低用户体验或业务成效。

    我们知道,如果不与合作伙伴、企业、第三方和开发者合作,我们将无法取得太大成效。我们希望通过公开的说明文档和规范,创建一个开放的平台,供大家讨论各种可能性并交流想法。开发者将有时间提供反馈,并测试这些提案的许多影响。

  2. 让第三方脚本的用户能够更好地归因工具和现场费用,清晰明确地使用脚本,并在编写脚本时获得更好的激励,从而确保脚本默认处于最佳状态。

    我们希望增强所有层(例如用户代理、框架和第三方脚本),以减少第三方对性能的影响。我们还打算提供充分的数据分析,帮助网站所有者针对嵌入的每个脚本采用最佳实践,包括在适用情况下使用更快的替代方案。

拟采用的方法

我们提出了三管齐下的做法来实现这些目标...

  1. **通过 RUM 和 Chrome 的开发者工具,让开发者更深入地了解每个第三方的影响。**

    RUM 是指通过Web 性能监控 API 提供的实时用户指标数据(也称为实测数据)。Chrome 的开发者工具包括 Lighthouse、Chrome 开发者工具和 Chrome 用户体验报告。我们提议增强可用的 API 和工具,以便网站开发者了解他们使用的每个第三方对每个网页的影响。这些工具还会告知开发者可以采取哪些措施来减少影响(例如推迟加载或使用外观),并探索其他潜在解决方案(其他第三方或自行解决)及其利弊。对于网站性能监控 API,我们正在探索在不侵犯用户隐私和安全的情况下,扩大其跨源资源覆盖范围的方法。

  2. **为企业提供一条明亮的道路,以便高效加载第三方资源。**

    我们希望提出新标准,鼓励浏览器在加载第一方资源和第三方资源的方式之间做出更智能的权衡,以便为用户提供更好的加载体验。稍后,我们将重点介绍其中的一些建议,例如默认延迟加载第三方嵌入内容,或对对用户可能最关心的初始内容不太重要的第三方资源应用不同的资源优先级。以上只是我们正在评估的众多想法中的一小部分,我们非常乐意与 Web 性能专家和更广泛的社区合作,共同打造这项工作。

    同样,我们也希望在 JavaScript 框架和内容管理系统 (CMS) 中解决此类问题(如果适用)。AuroraWordPress 性能团队等项目让我们了解到,内置的默认值对于解决已知加载问题的重要性。框架和 CMS 中内置的默认设置可引导企业沿着明亮的道路前进。这些指标对用户代理(例如 Chrome)也很有帮助,因为它们可以作为提示,让用户代理应用启发词语来优化网页加载和 CWV。此类提示可帮助用户代理确定应在页面生命周期中的何时以及如何加载特定第三方。(例如,Next.js 脚本组件具有内置的默认设置,可在页面变为交互状态后加载第三方脚本。)

  3. **通过提高透明度,激励第三方减少其对广告效果的影响。**

    第三方开发者目前缺乏必要的可见性,无法了解其脚本对整个网站的影响。我们计划解决此问题,并为这些提供商提供工具,以便他们分析其影响,并将其与市场上提供相同价值的其他产品进行比较。我们还希望帮助他们利用这些数据诊断影响产生的原因,以便在源头缓解影响。我们必须提及所有第三方(包括由 Google 创作的第三方)才能成功。

挑战

如此庞大的努力并非没有挑战。我们需要考虑的一些关键挑战包括:

  • 第三方是一个涉及广告、分析、代码管理、实用程序等诸多方面的跨领域问题。每个领域都需要考虑一组独特的要求和权衡。例如:
    • 是否优化广告加载取决于收入和用户体验之间的权衡。如果展示过早,会遮挡有价值的内容;如果展示过晚,用户会错过这些内容。
    • Google Analytics 脚本会增加页面大小,但可为企业提供有关用户操作的宝贵数据。

我们希望与各种类型的第三方合作,把握相关细微之处,解决权衡问题,并制定对所有人都有益的激励措施。我们深知,必须分别与每个地区的实体合作,才能使我们的策略发挥效用。这包括 Google 跟踪代码管理器、Google Ads 和 YouTube 等内部合作伙伴。

  1. 我们希望为网站开发者和第三方开发者提供更深入的归因。这需要我们认真努力,找出衡量影响最相关的数据,准确而精细地归因,并提供正确的后续行动路线。最终,计算给定第三方相较于竞争对手的表现应该对所有人公开透明。

  2. 我们提议增强 Chrome,使其能够应用优化措施,以便在优先加载第一方资源与第三方资源之间取得适当平衡。一项有价值的更改会成为所有浏览器的标准,但需要时间。例如,<img><iframe> 元素的 loading 属性自 2019 年起已在 Chrome/Edge 中提供,但直到 2022 年才在 Safari 中提供。在某项功能标准化之前,第三方资源的用户必须确保其也针对其他浏览器进行了优化。我们会在相关指南中突出显示这一点,以便您参考。

  3. 为了顺利执行此项目,我们必须与合作伙伴和开发者互动,不仅要帮助我们了解具体要求,还要大规模测试实验性解决方案、提供反馈,并根据需要进行迭代和改进。更改必须经过规划,并留出合理的时间来进行测试和评估。

初始标准提案

我们已进行了一些初步实验,以开发可用于优化第三方加载流程的功能。我们对所取得的成效感到满意,目前可以讨论其中的两项功能。

LazyEmbeds

以前,Chrome 会为精简模式用户延迟加载屏幕外 <img><iframe> 元素。此功能可扩展到所有用户,以延迟加载被确定为第三方嵌入的 <iframe> 元素,直到用户滚动到这些元素附近。这可以加快网页其他部分的加载速度、改进核心网页指标、减少内存用量并节省数据。

下面的演示展示了如何使用 LazyEmbed 在网页上延迟加载 YouTube 视频。单个 YouTube 视频嵌入通常会向网页添加 500-600KB 的 JavaScript。我们尝试使用 LazyEmbeds 优化了一篇包含 14 个此类嵌入视频的博文。在网页加载时间和数据节省方面,结果非常乐观。

之前 之后
数据 15.4 MB 6.1 MB
总屏蔽时间 3.2 秒 1.6 秒

如需详细了解这项工作,请参阅我们的说明文档以及 blink-dev intent-to-experiment 线程实验扩展

有针对性的第三方节流

第三方脚本通常由各个团队添加,而没有完整的监督流程。The Telegraph 的工程团队表示,“每个人都希望在能为组织创收的网页上添加‘那个代码’”。这可能会不断增加管理性能影响的工作量。

有针对性的第三方脚本节流功能旨在节流非常特定类型的第三方,以减少其影响。这样,浏览器就可以尽早加载关键内容和重要的第三方,而可以稍后加载的内容则会受到节流。

增强了 RUM API

我们还在考虑改进 RUM API,以添加与评估第三方效果相关的信息。改进包括:

  1. <iframe> 报告:我们正在开发可利用 Performance Timeline API 进行跨帧报告的解决方案。这样,顶级网页的作者就可以检查嵌入在该网页上的合作第三方 iframe 的效果数据。

  2. 长任务归因:RUM 中的 Long Tasks API 可帮助网站所有者识别长时间占用主线程并延迟互动的长任务。

后续动态

我们仍在尝试许多此类想法,并希望在后续过程中发布 GitHub 说明文档和规范草稿,以便进行更改。希望与我们合作或提供反馈的第三方和网站所有者可以通过这些渠道参与讨论。第三方也可以开始着重针对 Core Web Vitals 和 INP 指标进行优化,以确保 Core Web Vitals/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 为此提供了反馈和贡献。