打造更出色的网络：更快的 YouTube

一个案例研究，介绍了 YouTube 网站团队为提升效果、提高核心 Web 指标通过率和提升关键业务指标而做出的更改。

Addy Osmani
Addy Osmani
X GitHub
Sriram Krishnan
Sriram Krishnan

Chrome 团队经常提到“构建更出色的网络”，但这到底是什么意思？Web 体验应快速、无障碍，并在用户最需要的时候使用设备功能。Dogfooding 是 Google 文化的一部分，因此 Chrome 团队与 YouTube 合作，推出了名为“构建更出色的网络”的新系列视频，分享了在此过程中学到的教训。本系列的第一部分将深入介绍 YouTube 如何打造更快速的网络体验

显示 Chrome 用户体验报告数据的 PageSpeed Insights。
移动版 YouTube 观看页面通过了Core Web Vitals 阈值。

在 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（实验室）得分较低，首次内容渲染 (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 月面向所有移动网站用户部署到生产环境，如上文 RUM 分析所示，FCP 和 LCP 明显得到了改善。
我们于 2021 年 7 月面向所有移动网站用户在生产环境中部署了黑色缩略图，如上文 RUM 分析所示，FCP 和 LCP 明显得到了改善。

虽然这些优化确实缩短了 LCP 时间，但该团队认为，从用户的角度来看，LCP 指标的当前定义并未完全捕获网页的“主要内容”何时加载完毕（这是 LCP 的目标）。

为了解决这些问题，YouTube 团队的成员与 Chrome 团队的成员合作，探索了改进 LCP 指标以满足其用例的方法。在考虑了几个选项的可行性和影响后，团队最终确定了一个提案，即将视频元素第一帧的绘制时间视为 LCP 候选项。

这项变更在 Chrome 中生效后，YouTube 团队将非常乐意继续针对 LCP 进行优化。更新后的指标版本意味着这些优化对真实用户体验的影响将更直接。

使用延迟加载进行模块化

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

不过，在实现延迟加载后，该团队发现了瀑布流效应，即延迟加载的组件及其依赖项会在非最佳时间加载。

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

跨组件状态管理

由于其播放器控件的影响，YouTube 遇到了性能问题，尤其是在旧款设备上。代码分析表明，允许用户控制播放速度和进度等功能的播放器已逐渐过度组件化。

可视化的 YouTube 播放器和控件
用户可以使用 YouTube 视频播放器控制播放速度、跟踪进度、跳过部分内容等。当用户点按特定控件时，必须将状态更改传达给其他控件，例如，用户点按进度条时，必须将该操作分享给播放头、字幕等控件。

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

“性能”时间轴上显示的 21.17 毫秒事件。
在 CPU 运行速度降低 4 倍的情况下运行 Chrome 开发者工具。

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

缩短了效果时间轴上显示的事件所需的时间。

这种代码现代化还带来了其他性能改进，例如缩短了旧设备上的观看加载时间、减少了播放中止次数，以及减少了非严重错误的数量。

效果和优化

由于 YouTube 在性能方面进行了投资，观看页面的加载速度大大加快，现在，76% 的 YouTube 移动网站网址都达到了 Core Web Vitals 指标阈值。在桌面设备上，观看页面的实验室 LCP 从大约 4.6 秒缩短到了 1.6 秒。与之前相比，网站的互动和呈现性能（尤其是 YouTube 视频播放器）在 JavaScript 执行方面所花的时间最多缩短了 75%。

去年，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 团队，感谢他们对本工作的贡献。