LinkedIn經過在視頻播放過程當中收集的大量數據，對多種視頻指標進行實驗以提升視頻性能，改善用戶體驗。本文來自LinkedIn工程博客，LiveVideoStack對文章進行了翻譯。web
文 / Evan Farina瀏覽器
翻譯 / 元寶微信
原文網絡
https://engineering.linkedin.com/blog/2019/01/how-linkedin-uses-data-to-improve-video-performanceide
在LinkedIn，咱們使用數據來改善會員在使用咱們網站時的體驗。在視頻團隊中，咱們看重的是可以洞察咱們的視頻須要多長時間加載、爲何某些視頻比其餘視頻更受關注、以及咱們的成員如何與網絡、iOS和Android上的視頻進行交互的指標。簡而言之，經過在LinkedIn上播放視頻時收集的各類數據點，能夠極大地提升視頻性能。工具
技術用詞性能
這篇文章將提到如下術語，爲了方便您，定義以下：學習
iframe：一個能夠在內部呈現外部網頁內容的元素。這在視頻中很是有用，由於它容許咱們直接在咱們的網站內呈現來自第三方（例如Youtube、Vimeo）域的視頻。測試
視口：屏幕上可見的網站部分。flex
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工程博客團隊在編輯這篇文章時提供的幫助。向紐約的視頻團隊致敬，他們不懈地致力於提升視頻性能和總體視頻體驗。
精品文章推薦
技術乾貨：
本文分享自微信公衆號 - LiveVideoStack（livevideostack）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。