在LinkedIn，我们使用数据来改善会员在使用我们网站时的体验。在视频团队中，我们看重的指标是我们的视频需要多长时间加载、为什么某些视频比其他视频更受关注、以及我们的会员是如何通过web、iOS和Android的视频进行交互的。简而言之，通过在LinkedIn上播放视频时收集的各种数据点，可以极大地提高视频性能。
技术术语
为了方便你理解，这篇文章将提到以下术语，定义如下：
Iframe：一种可以让外部web页面内容呈现在内部的元素。这在视频中非常有用，因为它允许我们直接在我们的站点内呈现来自第三方来源(例如Youtube、Vimeo)的视频。
Viewport：网站在屏幕上可见的部分。
DOM：将web页面表示为由许多内容节点组成的树。
回放期间捕获数据
我们的系统捕捉视频回放过程中大量的性能数据。我们发现，通过关注以下数据点，我们能够显著提高LinkedIn.com上的视频性能：
- 媒体初始化开始：当播放器开始初始化时。
- 对于通过iframe播放的视频，例如第三方视频，这个参数标记iframe首次在页面上呈现的时间。
- 对于直接在页面上呈现的HTML5或本机视频，这个参数标记视频播放器发出loadstart事件的时间。
- 媒体初始化结束：当播放器初始化完成时。
- 这个参数实际上是标记视频何时发出loadeddata事件。
- 媒体缓冲开始：在视频开始播放之前，当媒体开始缓冲时。
- 媒体缓冲结束：在视频开始播放之前，媒体停止缓冲时。
- 开始时间(TTS)：从播放器初始化到播放器准备播放视频的时间。
- 注意：这是视频在初始化和缓冲上花费的时间之和。
- 感知开始时间(PTTS)：会员请求播放视频和视频实际开始播放之间的时间。
- 媒体初始化时间：媒体初始化开始和媒体初始化结束事件之间的时间。
- 媒体初始化率：一个数据点，用于确定视频在进入viewport并在退出viewport之前成功加载的百分比。
- 如果这个速率下降，就是告诉我们，可能需要很长时间来加载视频。
在这篇文章的后面，我们将放大两个实验，利用上面的许多数据点来改进我们最重要的指标之一，PTTS。
使用数据使我们的会员受益
现在我们已经积累了大量有意义的视频回放数据，我们如何使用它来改善我们的会员的体验？我们用两种方法来解决这个问题。
详细、实时的参数报告
在LinkedIn，我们利用多种内部工具和服务来存储数据，并实时可视化数据中的变化。其中一个特别有用的工具叫做InGraphs，它使我们能够在可视化产品中收集许多数据点。
除了InGraphs提供的图表之外，我们还有一些服务，在任何核心参数值低于预先设定的阈值时，都会通知相关团队。如果发现我们的一个产品中的会员体验下降，这些工具使我们能够立即采取行动。
持续的A/B特性测试
我们不断地尝试新功能，以及对现有功能进行调整，其首要目标是为我们的会员提供最好的体验。我们使用指标——与ingraphics之类的报告工具一起使用——来清晰地描绘出一个给定的实验是如何影响整个站点的用户交互。
例如，想象一个虚构的实验，在这个实验中，我们测试了在每个会员feed中只显示前30个帖子的视频内容的效果。这个实验一开始似乎是成功的，因为我们的会员观看视频的数量增加了。然而，在仔细研究InGraphs之后，我们注意到，会员分享的帖子数量有所下降。通过对这种相关性的理解和对这两种影响的考虑，将会因为对会员体验的负面影响而终止实验。
确保我们的数据是准确的
数据的有多大的用处取决于它的准确性。如果我们不相信存储的数据是准确的，那么验证我们创建的各种实验的基础就不存在了。除了上面提到的数据监控服务之外，我们还大量使用自动化(单元、集成和验收)测试来确保给定的特性能够正确工作。正如你所想象的，在开发新功能的过程中，以LinkedIn的规模，用手工测试所有现有功能是不可扩展的。相反，测试需单独运行现有的特性，并确保通过各种交互，这些特性能够按照预期的方式执行。例如，我们可以编写一个测试，它预计单击视频的播放按钮会导致视频开始播放，并捕获关于视频加载性能的数据。因此，自动化测试使我们的工程师能够确保他们的特性所发出的参数标准在特性创建之后很长一段时间内都是准确的。除了自动化测试之外，LinkedIn的工程师还有一些方便使用的工具(参见之前的一篇关于大规模工程基础设施的博客文章中提到的跟踪覆盖)，以便于对给定特性发出的参数进行验证。
将数据用于视频性能
由于视频库天然规模比较大，视频性能需要一个独特的方法：我们需要一种方法来下载足够的视频，立刻开始播放，同时也确保我们不会减慢其他元素出现在页面上。
案例研究:感知启动时间(PTTS)
在领英(LinkedIn)，我们测量用户感知的加载时间，以了解用户等待视频播放的时间。我们用来了解视频加载需要多长时间的主要度量指标是感知启动时间(PTTS)。PTTS测量浏览器下载视频所花费的时间，以及视频在播放前缓冲的时间。
让我们看一下上面的图表，它提供了一些关于特定会员等待视频加载的经验。视频进入viewport后，初始化视频需要2700 ms，视频开始播放前需要3300 ms的视频缓冲。这里的PTTS大约是6000ms。我们现在可以使用这个参数和其他数百万个数据点，作为加速视频加载实验的基本指导原则。让我们来看看下面进行的几个实验。
快速加载DOM中的所有视频
在领英(LinkedIn)，我们既尝试了贪婪加载视频，也尝试了惰性加载视频。贪婪加载视频是只要视频一进入DOM就开始下载。这与惰性加载不同，惰性加载是指直到视频进入viewport才下载视频。贪婪加载允许视频在进入viewport之前在后台加载。这提供了很好的用户体验，因为视频一进入viewport就开始播放，缓冲很少甚至没有缓冲。乍一看，这个实验是成功的，因为它减少了PTTS，这意味着视频似乎开始播放的时间更短。然而，当我们仔细研究这些指标时，我们发现了一些有趣的结果。带宽较强的会员PTTS确实有所下降，而带宽较弱的会员媒体初始化速率下降，而初始化时间增加。例如，想象一下，一名会员在乘坐地铁时用手机浏览LinkedIn feed。考虑到地铁网络连接很不稳定，该会员加载内容可能都会有相当的延迟，更不用说视频库了。在贪婪加载的情况下，我们不仅下载viewport中的内容，还尝试在后台加载视频。正如您可能想象的那样，这会给网络连接较慢的会员带来过大的负载，可能导致post都不加载。这一现象解释了前面提到的媒体初始化速率降低和媒体初始化时间增加的原因，也是我们下一步实验的动机。
视频排队加载
排队加载是一种加载策略，在这种策略中，视频被添加到加载队列中，并一次加载一个，而不是一次加载DOM中的所有视频(就像贪婪加载一样)。排队加载旨在结合贪婪加载(减少PTTS)和惰性加载(网络带宽更少的会员更容易访问)的优点。它通过在viewport之外加载视频来实现这一点，但是只有在viewport中的视频成功加载之后才会这样做。在队列加载时，我们观察到PTTS略有增加，这可能是因为在viewport之外加载的视频更少，但是对于网络连接较弱的会员，媒体初始化速率增加，媒体初始化时间减少。这使我们得出结论，队列加载在为网络连接较强的会员积极加载视频和为网络连接较弱的会员优先加载viewport中的内容之间产生了最佳权衡。
结论
视频资产的巨大规模以及对其快速加载而不会对站点其他部分的速度产生负面影响的期望，使得大规模的视频性能成为一个固有的难以解决的问题。为了使问题进一步复杂化，我们还必须在运行与性能相关的实验之前，考虑网络速度和浏览器功能方面的差异，以及会员使用站点的不同方式。通过正确地使用数据，我们可以快速地定位和迭代退化的性能，同时确保不会出现性能退化。
致谢
我要感谢Shane Afsar和Kris Teehan在撰写这篇文章时给予的帮助，以及Kevin O’connell和LinkedIn工程博客团队在编辑这篇文章时给予的帮助。为纽约的视频团队点赞，他们不知疲倦地致力于提高视频性能和整体视频体验。
查看英文原文：How LinkedIn Uses Data to Improve Video Performance（https://engineering.linkedin.com/blog/2019/01/how-linkedin-uses-data-to-improve-video-performance）