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

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

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 等性能指标。

改进 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 团队,感谢他们对本工作的贡献。