LinkedIn通过在视频播放过程中收集的大量数据，对多种视频指标进行实验以提高视频性能，改善用户体验。本文来自LinkedIn工程博客，LiveVideoStack对文章进行了翻译。
文 / Evan Farina
翻译 / 元宝
原文
https://engineering.linkedin.com/blog/2019/01/how-linkedin-uses-data-to-improve-video-performance
在LinkedIn，我们使用数据来改善会员在使用我们网站时的体验。在视频团队中，我们看重的是能够洞察我们的视频需要多长时间加载、为什么某些视频比其他视频更受关注、以及我们的成员如何与网络、iOS和Android上的视频进行交互的指标。简而言之，通过在LinkedIn上播放视频时收集的各种数据点，可以极大地提高视频性能。
技术用词
这篇文章将提到以下术语，为了方便您，定义如下：
- iframe：一个可以在内部呈现外部网页内容的元素。这在视频中非常有用，因为它允许我们直接在我们的网站内呈现来自第三方（例如Youtube、Vimeo）域的视频。
- 视口：屏幕上可见的网站部分。
- DOM：将网页表示为由许多内容节点组成的树。
在播放期间捕获数据
我们的系统捕获反应视频在播放过程中如何执行的大量数据。我们发现通过关注以下数据点，我们已经能够显着提高LinkedIn.com上的视频性能：
- 媒体初始化开始：当播放器开始初始化时。
对于通过iframe播放的视频（例如第三方视频），此指标会标记iframe首次在页面上呈现的时间。
对于直接在页面上呈现的HTML5或本机视频，此指标会标记视频播放器发出loadstart事件的时间。
- 媒体初始化结束：播放器初始化完成后。
此度量标准实际上标记了视频发出loadeddata事件的时间。
- 媒体缓冲开始：媒体在视频播放之前首先开始缓冲。
- 媒体缓冲结束：在视频开始播放之前，媒体停止缓冲。
- 开始时间（TTS）：播放器初始化和播放器准备播放视频之间的时间。
注意：这是视频在初始化和缓冲上花费的时间总和。
- 感知的开始时间（PTTS）：成员请求播放视频和视频实际开始播放之间的时间。
- 媒体初始化时间：媒体初始化开始和媒体初始化结束事件之间的时间。
- 媒体初始化率：一种数据点，用于确定进入视口并在退出视口之前成功加载视频的百分比。
如果这个比率下降，则会告诉我们，我们的视频可能需要很长时间才能加载。
稍后在本文中，我们将放大一些利用上述许多数据点的实验来改进我们最重要的指标之一，PTTS。
使用数据来让我们的会员受益
现在我们已经积累了大量富有洞察力的视频播放数据，我们如何使用它来改善我们会员的体验呢？我们用两种方法解决这个问题。
详细的实时指标报告
在LinkedIn，我们利用多种内部工具和服务，使我们能够实时存储数据并可视化这些数据的变化。其中一个特别有用的工具叫做InGraphs，它允许我们可视化在产品中收集的许多数据点。
除了InGraphs提供的图表之外，我们还提供服务，以便在任何核心指标低于预设阈值时通知相关团队。如果我们发现某个产品中的会员体验出现退化，这些工具可以使我们立即采取行动。
功能的持续A / B测试
我们不断尝试新功能，并对现有功能进行调整，其首要目标是为我们的会员提供最佳体验。我们将指标与InGraphs等报告工具结合使用，可以清晰地描绘出一个给定的实验如何影响整个网站的用户互动。
例如，想象一个虚构的实验，在这个实验中，我们测试了仅显示每个成员的Feed中前30个帖子的视频内容的效果。最初看起来似乎是成功的，因为我们的会员观看的视频数量增加了。但是，在仔细研究InGraphs之后，我们注意到我们的会员共享的帖子数量下降了。通过对这种相关性的理解和对这两种影响的考虑，实验将会因为对会员体验的负面影响而终止
确保我们的数据准确无误
数据的有用程度取决于它的准确性。如果我们不能相信我们存储的数据是准确的，那么就没有基础来测试我们创建的各种实验。除了上面提到的数据监控服务之外，我们还大量使用自动（单元，集成和验收）测试来确保给定功能正常工作。正如您所想象的，在开发新功能的过程中，以LinkedIn的规模手工测试所有现有功能是不可伸缩的。相反，测试用于单独运行的现有功能，并保证通过各种交互，功能能够按预期地执行。例如，我们可以编写一个测试，它断言单击视频的播放按钮会导致视频开始播放，并捕获有关视频加载性能的数据。因此，自动化测试使我们的工程师能够保证在创建功能后很长时间内，其功能发出的指标是准确的。除了自动化测试之外，LinkedIn工程师还有一些方便使用的工具（请参阅之前博客文章中提到的跟踪覆盖大规模的工程基础设施 https://engineering.linkedin.com/blog/2016/11/engineering-infrastructure-at-scale--test-tracking），以便于验证给定功能发出的指标。
使用数据获取视频性能
由于视频资源的自然大小，视频性能需要一种独特的方法：我们需要一种方法来下载足够的视频，以便它立即开始播放，同时还确保我们不会减慢在页面上呈现元素的速度。
案例研究：感知开始时间（PTTS）
在LinkedIn，我们测量感知加载时间，以了解我们的会员等待视频播放的时间。我们用来深入了解视频加载时间的主要指标是感知启动时间（PTTS）。PTTS测量浏览器下载视频所需的时间，以及视频在播放前缓冲的时间。
让我们看一下上面的图表，它提供了一些特定会员等待加载视频的经验。一旦视频进入视口，视频初始化需要2,700ms，然后在视频开始播放之前再进行3,300ms的视频缓冲。在这种情况下，PTTS大约是6,000毫秒。我们现在可以使用此指标以及其他的数百万个数据点，作为加速视频加载实验的基本指南。让我们看一下我们运行的几个实验。
急切加载DOM中的所有视频
在LinkedIn，我们已经尝试了预先加载视频的和延迟加载视频。预先加载视频是在视频进入DOM后立即开始下载视频。这与延迟加载不同，通过该加载，视频在进入视口之前不会下载。预先加载允许视频在进入视口之前在后台加载。这提供了很好的用户体验，因为视频一进入视口就会开始播放，几乎没有缓冲。乍一看，这个实验是成功的，因为它减少了PTTS，意味着视频开始播放的时间更短了。然而，当我们仔细研究指标时，我们发现了一些有趣的结果。虽然带宽较强的会员确实享受PTTS的减少，但带宽较弱的那些媒体初始化速率降低，媒体初始化时间增加。想象一下，例如，一名会员在乘坐地铁时在他或她的手机上滚动LinkedIn Feed。鉴于地铁的互联网连接较弱，会员在加载内容方面已经面临滞后，更不用说视频资产了。在急切加载的情况下，我们不仅在视口中下载内容，我们还尝试在幕后加载视频。正如您想象的那样，这会对成员相对较弱的连接施加过大的负载，从而可能导致没有任何Feed的帖子加载。这种现象解释了前面提到的媒体初始化率下降和媒体初始化时间增加，这也是我们下一次实验的动机。
排队视频加载
排队加载是一种加载策略，在这种策略中，视频被添加到加载队列中，并一次加载一个，而不是一次加载DOM中的所有视频（如预先加载的情况）。排队加载旨在结合预先加载（减少的PTTS）和延迟加载（对于网络带宽较少的成员更容易访问）的好处。它通过在视口外部加载视频来完成此操作，但只有在视口中的视频成功加载后才能这样做。对于排队加载，我们观察到PTTS略有增加，可能是因为视口外部加载的视频较少，但媒体初始化率增加，而网络连接较弱的成员的媒体初始化时间减少。
结论
由于视频资源的大尺寸以及对其快速加载而不会对网站其他部分的速度造成负面影响的期望，使得视频性能成为一个固有的难以解决的问题。为了进一步使问题复杂化，我们还必须在运行与性能相关的实验之前，考虑网络速度和浏览器功能方面的差异，以及成员使用站点的不同方式。通过正确使用数据，我们可以快速查明并迭代性能下降，同时确保在此过程中不会出现性能退化。
致谢
我要感谢Shane Afsar和Kris Teehan在撰写这篇文章时给予的帮助，以及Kevin O'Connell和LinkedIn工程博客团队在编辑这篇文章时提供的帮助。向纽约的视频团队致敬，他们不懈地致力于提高视频性能和整体视频体验。
