在 LinkedIn，我們使用數(shù)據(jù)來改善會員在使用我們網(wǎng)站時的體驗。在視頻團隊中，我們看重的指標(biāo)是我們的視頻需要多長時間加載、為什么某些視頻比其他視頻更受關(guān)注、以及我們的會員是如何通過 web、iOS 和 Android 的視頻進行交互的。簡而言之，通過在 LinkedIn 上播放視頻時收集的各種數(shù)據(jù)點，可以極大地提高視頻性能。

技術(shù)術(shù)語

為了方便你理解，這篇文章將提到以下術(shù)語，定義如下：

Iframe：一種可以讓外部 web 頁面內(nèi)容呈現(xiàn)在內(nèi)部的元素。這在視頻中非常有用，因為它允許我們直接在我們的站點內(nèi)呈現(xiàn)來自第三方來源 (例如 Youtube、Vimeo) 的視頻。

Viewport：網(wǎng)站在屏幕上可見的部分。

DOM：將 web 頁面表示為由許多內(nèi)容節(jié)點組成的樹。

回放期間捕獲數(shù)據(jù)

我們的系統(tǒng)捕捉視頻回放過程中大量的性能數(shù)據(jù)。我們發(fā)現(xiàn)，通過關(guān)注以下數(shù)據(jù)點，我們能夠顯著提高 LinkedIn.com 上的視頻性能：

媒體初始化開始：當(dāng)播放器開始初始化時。

對于通過 iframe 播放的視頻，例如第三方視頻，這個參數(shù)標(biāo)記 iframe 首次在頁面上呈現(xiàn)的時間。

對于直接在頁面上呈現(xiàn)的 HTML5 或本機視頻，這個參數(shù)標(biāo)記視頻播放器發(fā)出loadstart事件的時間。

媒體初始化結(jié)束：當(dāng)播放器初始化完成時。

這個參數(shù)實際上是標(biāo)記視頻何時發(fā)出loadeddata事件。

媒體緩沖開始：在視頻開始播放之前，當(dāng)媒體開始緩沖時。

媒體緩沖結(jié)束：在視頻開始播放之前，媒體停止緩沖時。

開始時間 (TTS)：從播放器初始化到播放器準(zhǔn)備播放視頻的時間。

注意：這是視頻在初始化和緩沖上花費的時間之和。

感知開始時間 (PTTS)：會員請求播放視頻和視頻實際開始播放之間的時間。

媒體初始化時間：媒體初始化開始和媒體初始化結(jié)束事件之間的時間。

媒體初始化率：一個數(shù)據(jù)點，用于確定視頻在進入 viewport 并在退出 viewport 之前成功加載的百分比。

如果這個速率下降，就是告訴我們，可能需要很長時間來加載視頻。

在這篇文章的后面，我們將放大兩個實驗，利用上面的許多數(shù)據(jù)點來改進我們最重要的指標(biāo)之一，PTTS。

使用數(shù)據(jù)使我們的會員受益

現(xiàn)在我們已經(jīng)積累了大量有意義的視頻回放數(shù)據(jù)，我們?nèi)绾问褂盟鼇砀纳莆覀兊臅�員的體驗?我們用兩種方法來解決這個問題。

詳細(xì)、實時的參數(shù)報告

在 LinkedIn，我們利用多種內(nèi)部工具和服務(wù)來存儲數(shù)據(jù)，并實時可視化數(shù)據(jù)中的變化。其中一個特別有用的工具叫做InGraphs，它使我們能夠在可視化產(chǎn)品中收集許多數(shù)據(jù)點。

除了 InGraphs 提供的圖表之外，我們還有一些服務(wù)，在任何核心參數(shù)值低于預(yù)先設(shè)定的閾值時，都會通知相關(guān)團隊。如果發(fā)現(xiàn)我們的一個產(chǎn)品中的會員體驗下降，這些工具使我們能夠立即采取行動。

持續(xù)的 A/B 特性測試

我們不斷地嘗試新功能，以及對現(xiàn)有功能進行調(diào)整，其首要目標(biāo)是為我們的會員提供最好的體驗。我們使用指標(biāo)——與 ingraphics 之類的報告工具一起使用——來清晰地描繪出一個給定的實驗是如何影響整個站點的用戶交互。

例如，想象一個虛構(gòu)的實驗，在這個實驗中，我們測試了在每個會員 feed 中只顯示前 30 個帖子的視頻內(nèi)容的效果。這個實驗一開始似乎是成功的，因為我們的會員觀看視頻的數(shù)量增加了。然而，在仔細(xì)研究 InGraphs 之后，我們注意到，會員分享的帖子數(shù)量有所下降。通過對這種相關(guān)性的理解和對這兩種影響的考慮，將會因為對會員體驗的負(fù)面影響而終止實驗。

確保我們的數(shù)據(jù)是準(zhǔn)確的

數(shù)據(jù)的有多大的用處取決于它的準(zhǔn)確性。如果我們不相信存儲的數(shù)據(jù)是準(zhǔn)確的，那么驗證我們創(chuàng)建的各種實驗的基礎(chǔ)就不存在了。除了上面提到的數(shù)據(jù)監(jiān)控服務(wù)之外，我們還大量使用自動化 (單元、集成和驗收) 測試來確保給定的特性能夠正確工作。正如你所想象的，在開發(fā)新功能的過程中，以 LinkedIn 的規(guī)模，用手工測試所有現(xiàn)有功能是不可擴展的。相反，測試需單獨運行現(xiàn)有的特性，并確保通過各種交互，這些特性能夠按照預(yù)期的方式執(zhí)行。例如，我們可以編寫一個測試，它預(yù)計單擊視頻的播放按鈕會導(dǎo)致視頻開始播放，并捕獲關(guān)于視頻加載性能的數(shù)據(jù)。因此，自動化測試使我們的工程師能夠確保他們的特性所發(fā)出的參數(shù)標(biāo)準(zhǔn)在特性創(chuàng)建之后很長一段時間內(nèi)都是準(zhǔn)確的。除了自動化測試之外，LinkedIn 的工程師還有一些方便使用的工具 (參見之前的一篇關(guān)于大規(guī)模工程基礎(chǔ)設(shè)施的博客文章中提到的跟蹤覆蓋)，以便于對給定特性發(fā)出的參數(shù)進行驗證。

將數(shù)據(jù)用于視頻性能

由于視頻庫天然規(guī)模比較大，視頻性能需要一個獨特的方法：我們需要一種方法來下載足夠的視頻，立刻開始播放，同時也確保我們不會減慢其他元素出現(xiàn)在頁面上。

案例研究: 感知啟動時間 (PTTS)

在領(lǐng)英 (LinkedIn)，我們測量用戶感知的加載時間，以了解用戶等待視頻播放的時間。我們用來了解視頻加載需要多長時間的主要度量指標(biāo)是感知啟動時間 (PTTS)。PTTS 測量瀏覽器下載視頻所花費的時間，以及視頻在播放前緩沖的時間。

 

 

讓我們看一下上面的圖表，它提供了一些關(guān)于特定會員等待視頻加載的經(jīng)驗。視頻進入 viewport 后，初始化視頻需要 2700 ms，視頻開始播放前需要 3300 ms 的視頻緩沖。這里的 PTTS 大約是 6000ms。我們現(xiàn)在可以使用這個參數(shù)和其他數(shù)百萬個數(shù)據(jù)點，作為加速視頻加載實驗的基本指導(dǎo)原則。讓我們來看看下面進行的幾個實驗。

快速加載 DOM 中的所有視頻

 

 

在領(lǐng)英 (LinkedIn)，我們既嘗試了貪婪加載視頻，也嘗試了惰性加載視頻。貪婪加載視頻是只要視頻一進入 DOM 就開始下載。這與惰性加載不同，惰性加載是指直到視頻進入 viewport 才下載視頻。貪婪加載允許視頻在進入 viewport 之前在后臺加載。這提供了很好的用戶體驗，因為視頻一進入 viewport 就開始播放，緩沖很少甚至沒有緩沖。乍一看，這個實驗是成功的，因為它減少了 PTTS，這意味著視頻似乎開始播放的時間更短。然而，當(dāng)我們仔細(xì)研究這些指標(biāo)時，我們發(fā)現(xiàn)了一些有趣的結(jié)果。帶寬較強的會員 PTTS 確實有所下降，而帶寬較弱的會員媒體初始化速率下降，而初始化時間增加。例如，想象一下，一名會員在乘坐地鐵時用手機瀏覽 LinkedIn feed�？紤]到地鐵網(wǎng)絡(luò)連接很不穩(wěn)定，該會員加載內(nèi)容可能都會有相當(dāng)?shù)难舆t，更不用說視頻庫了。在貪婪加載的情況下，我們不僅下載 viewport 中的內(nèi)容，還嘗試在后臺加載視頻。正如您可能想象的那樣，這會給網(wǎng)絡(luò)連接較慢的會員帶來過大的負(fù)載，可能導(dǎo)致 post 都不加載。這一現(xiàn)象解釋了前面提到的媒體初始化速率降低和媒體初始化時間增加的原因，也是我們下一步實驗的動機。

視頻排隊加載

 

 

排隊加載是一種加載策略，在這種策略中，視頻被添加到加載隊列中，并一次加載一個，而不是一次加載 DOM 中的所有視頻 (就像貪婪加載一樣)。排隊加載旨在結(jié)合貪婪加載 (減少 PTTS) 和惰性加載 (網(wǎng)絡(luò)帶寬更少的會員更容易訪問) 的優(yōu)點。它通過在 viewport 之外加載視頻來實現(xiàn)這一點，但是只有在 viewport 中的視頻成功加載之后才會這樣做。在隊列加載時，我們觀察到 PTTS 略有增加，這可能是因為在 viewport 之外加載的視頻更少，但是對于網(wǎng)絡(luò)連接較弱的會員，媒體初始化速率增加，媒體初始化時間減少。這使我們得出結(jié)論，隊列加載在為網(wǎng)絡(luò)連接較強的會員積極加載視頻和為網(wǎng)絡(luò)連接較弱的會員優(yōu)先加載 viewport 中的內(nèi)容之間產(chǎn)生了最佳權(quán)衡。

結(jié)論

視頻資產(chǎn)的巨大規(guī)模以及對其快速加載而不會對站點其他部分的速度產(chǎn)生負(fù)面影響的期望，使得大規(guī)模的視頻性能成為一個固有的難以解決的問題。為了使問題進一步復(fù)雜化，我們還必須在運行與性能相關(guān)的實驗之前，考慮網(wǎng)絡(luò)速度和瀏覽器功能方面的差異，以及會員使用站點的不同方式。通過正確地使用數(shù)據(jù)，我們可以快速地定位和迭代退化的性能，同時確保不會出現(xiàn)性能退化。

致謝

我要感謝Shane Afsar和Kris Teehan在撰寫這篇文章時給予的幫助，以及Kevin O’connell和 LinkedIn 工程博客團隊在編輯這篇文章時給予的幫助。為紐約的視頻團隊點贊，他們不知疲倦地致力于提高視頻性能和整體視頻體驗。

作者：Evan Farina  譯者：關(guān)賀宇

查看英文原文：How LinkedIn Uses Data to Improve Video Performance(https://engineering.linkedin.com/blog/2019/01/how-linkedin-uses-data-to-improve-video-performance)

標(biāo)簽： 媒體 網(wǎng)絡(luò)

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。