打造更好的网络环境 - 第 1 部分：速度更快的 YouTube 网络

案例研究，探讨 YouTube Web 团队为提升性能、提高 Core Web Vitals 通过率和提升关键业务指标而做出的改变。

Addy Osmani
Addy Osmani
X GitHub
Sriram Krishnan
Sriram Krishnan

Chrome 团队经常会谈论“构建更好的网络”，但这是什么意思呢？网络体验应该快速、易于访问，并在用户最需要的时候使用设备功能。Dogfood 测试是 Google 文化的一部分，因此 Chrome 团队与 YouTube 携手合作，在名为“构建更好的网络”的新系列中分享在此过程中积累的经验。本系列的第一部分将深入探讨 YouTube 如何打造更快的网络体验。

PageSpeed Insights 会显示 YouTube 移动网站的 Chrome 用户体验报告数据，这些数据已通过核心网页指标测试。
移动版 YouTube 观看页面超过了核心网页指标阈值。

构建速度更快的 Web

在 YouTube，性能与视频和其他内容（例如推荐内容和评论）在网页上的加载速度有关。此外，表现的衡量指标还包括 YouTube 对用户互动（例如搜索、播放器控制、点赞和分享等）的响应速度。

巴西、印度和印度尼西亚等发展中市场对于 YouTube 移动网站非常重要。由于这些地区的许多用户的设备速度较慢且网络带宽有限，因此确保提供快速流畅的体验是一项关键目标。

为了向所有用户提供包容性的体验，YouTube 着手通过延迟加载和代码现代化改造来改进性能指标，例如核心网页指标。

改进 Core Web Vitals

为了找出有待改进的方面，YouTube 团队使用 Chrome 用户体验报告 (CrUX) 来了解真实用户在移动设备上的视频观看和搜索结果页的现场体验。他们意识到，Core Web Vitals 指标有很大的改进空间，在某些情况下，其 Largest Contentful Paint (LCP) 指标只有 4-6 秒的时间。这明显高于他们的 2.5 秒目标。

FCP 和 LCP 图表显示了 YouTube 观看页面通过率以及 YouTube 来源。

为了找出有待改进的方面，他们借助 Lighthouse 审核 YouTube 观看页面，发现 Lighthouse (lab) 得分较低，First Contentful Paint (FCP) 为 3.5 秒，LCP 为 8.5 秒。

移动版 YouTube 的 Lighthouse 报告。
作为黄金标准，Chrome 将 FCP 的目标时间为 1.8 秒，LCP 的目标时间为 2.5 秒。FCP 和 LCP 分别在 3.5 秒和 8.5 秒时以黄色和红色显示。

为了优化 FCP 和 LCP，YouTube 团队深入开展了多项实验，并发现了两大重大发现。

  1. 第一个发现是，通过将视频播放器的 HTML 代码移到使视频播放器具有互动性的脚本之上，他们可以提高性能。实验室测试表明，这可以同时将 FCP 和 LCP 从 4.4 秒缩短到 1.1 秒。

  2. 第二个发现是，LCP 仅考虑 <video> 个元素的海报图片，而非视频流本身的帧。以往，YouTube 的优化时间是尽可能缩短视频开始播放的时间，因此为了提高 LCP，该团队还开始优化海报图片分发速度。他们尝试了几种海报图片变体，并从用户测试中选出了得分最高的图片。得益于这项工作，FCP 和 LCP 均表现出显著的改进，现场 LCP 从 4.6 秒缩短到 2.0 秒。

移动网站的观看页面 LCP 实验，其中显示了对照组、实验组 A（图片缩略图）和实验组 B（黑色缩略图）
在实验室中，我们观察到，此变更生效后 FCP 和 LCP 从 4.4 秒缩短到了 1.1 秒。实验 A：在视频一开始播放的网页上使用实际的视频缩略图效果较好，但对于观看页面等自动播放的视频网页，在用户研究中效果较差。这一举措还导致活跃用户数下降。实验 B：在用户研究中，使用纯黑色海报图片显示的效果最佳。用户发现，从纯黑色过渡到视频第一帧，不会对自动播放视频造成干扰。
黑色缩略图是在 2021 年 7 月面向所有移动网络用户在生产环境中部署的，显示了 FCP 和 LCP 的显著改进（如上述 RUM 分析所示）。
2021 年 7 月，为所有移动网站用户在生产环境中部署黑色缩略图，表明 FCP 和 LCP 明显改善（如上述 RUM 分析所示）。

虽然这些优化确实提高了 LCP，但该团队认为，从用户的角度来看，当页面“主要内容”加载时（LCP 的目标就是加载）时，LCP 指标的当前定义并没有完全捕获。

为了解决这些问题，YouTube 团队的成员与 Chrome 团队的成员展开了合作，共同探讨如何改进 LCP 指标，从而解决他们的使用情形。在考虑了几种方案的可行性和影响后，相关团队提出了一项建议，即考虑将视频元素第一帧的绘制时间作为 LCP 候选版本。

一旦此项变更在 Chrome 中生效，YouTube 团队便会很高兴地继续开展针对 LCP 优化的工作。更新后的指标意味着这些优化将会对实际用户体验产生更直接的影响。

采用延迟加载的模块化方法

YouTube 页面包含许多急切加载的模块。为了优化 50 多个组件的渲染方式，该团队构建了一个组件到 JS 模块映射，以告知客户端要加载哪些模块。通过将组件标记为“延迟”，JS 模块将稍后加载，从而缩短网页的初始加载时间，并减少发送到客户端的未使用的 JavaScript 数量。

不过，在实现延迟加载后，该团队注意到一种瀑布效应，延迟加载的组件及其依赖项会在不太理想的时间进行加载。

为了解决此问题，该团队确定了视图中所需的最小组件集，并在单个网络请求中批量处理这些组件。这些结果提高了网页速度、缩短了 JavaScript 解析时间，并最终缩短了初始呈现时间。

跨组件状态管理

YouTube 因播放器控件而出现性能问题，尤其是在旧款设备上。代码分析表明，允许用户控制播放速度和进度等功能的播放器已随着时间的推移过度组件化。

直观呈现了 YouTube 播放器和控件
YouTube 视频播放器可让用户控制播放速度、跟踪进度、跳过某些部分等。当用户点按特定控件时，必须将状态变化传达给其他控件，例如，必须将用户对进度条的点按操作共享给进度条指针、字幕等控件。

每个进度条触摸移动事件都会触发两次额外的样式重新计算，并且在实验室中的性能测试运行期间用时了 21.17 毫秒。随着时间推移不断添加新的控件，分散式控制的模式常常会导致循环依赖项和内存泄漏，从而对观看页面的性能产生负面影响。

“性能”时间轴上显示的 21.17 毫秒事件。
Chrome 开发者工具的 CPU 运行速度减慢 4 倍。

为了解决因分散控制而导致的问题，该团队更新了玩家界面以同步所有更新，实质上是将播放器重构为一个会将数据传递给其子级的顶级组件。这样可以确保任何状态更改都只有一个界面更新（渲染）周期，从而消除了链式更新。新的玩家进度条触摸移动事件在 JavaScript 执行期间不会重新计算样式，现在只需要旧播放器的 25% 的时间。

缩短了性能时间轴上显示的事件的时间。

这种代码现代化改造还带来了额外的性能改进，例如缩短了旧设备上的观看时长、减少被放弃的播放次数以及减少了非严重错误的数量。

总结

得益于 YouTube 在性能方面的投入，观看页面加载速度显著提升，目前 76% 的 YouTube 移动网站网址达到了实际的核心网页指标阈值。在桌面设备上，观看页面的实验室 LCP 从约 4.6 秒缩短到了 1.6 秒。与以前相比，网站的互动和呈现性能（尤其是在 YouTube 视频播放器上）花在 JavaScript 上所花的时间减少了多达 75%。

过去一年来，YouTube 网页版的表现有所提升，业务指标（包括观看时长和日活跃用户数）也有所提升。基于这些工作的成功，我们计划在未来继续探索更多优化方法。

在本系列的第 2 部分“构建无障碍网络”中，您将了解 YouTube 如何使他们的网站更便于使用屏幕阅读器的用户访问。

特别感谢 Gilberto Cocchi、Lauren Usui、Benji Bear、Bo Aye、Bogdan Balas、Kenny Tran、Matthew Smith、Phil Harnish、Leena Sahoni、Jeremy Wagner、Philip Walton、Harleen Batra 以及 YouTube 和 Chrome 团队对这项工作所做的贡献。