在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）